Software development is a lot like baking cakes and you always get to eat the cake too! That's really great, except for the fact that you're also building your kitchen at the same time and all the instructions are missing, wrong, incomplete or in some strange language you can't even begin to comprehend. Did I mention that you probably aren't that great of a cook to begin with?
Even if all the cakes you bake with your makeshift kitchen aren't that great or even outright disgusting, it is paramount that you eat it. Eat it again and again, add new ingredients, try cooking it differently and whatever else you might do in this analogy that would relate to an iterative software development cycle.
Working with your own software is the easiest way to detect flaws, especially in terms of usability and flexibility. If you aren't having a grand time using your own thing, you are doing something very wrong and should get to fixing that immediately. I've talked about a methodology to enforce this before and called it ‘Interface First’. I'm trying my best to follow this, as it has many benefits: It gets some kind of result out very quickly and assures that you get what you need and want.
Most of all though thinking about your interface first helps you to figure out what you even want in the first place, since even that is often much less clear than your own mind might make you want to believe. Furthermore as mentioned it assures that you can focus on making the end result of your project something that you can like, which will assure a good outcome upon completion.
But even going away from the interface first methodology, it's vital to constantly use your own software. Doing so assures that the main parts of your software work and keep on working and it will make you realise flaws in whatever interface it is you expose as you both learn more about the internal and external requirements as you go on. That testing your code is important is probably obvious to anyone, but what was not so obvious to me is that there is a very bad tendency to avoid tests.
I'm honestly not sure where this aversion stems from, but I often catch myself trying to design the beck-end of a system first, or trying to avoid fixing some known problems, or even avoiding to test some functionality. This is rather dangerous for the integrity of the project of course. I don't know if there's a simple way to avoid this effect either, aside from occasionally overcoming my inner devil and get the ‘nasty’ work over with. I suppose the impression that doing these things are bad is because I'm afraid of discovering bugs and having to fix them, but at the same time it's always a big pleasure to see that things just work and still play nicely even after a lot of changes having been made. As I mentioned before, there's always rather big upsides to any of these tasks I. It seems ridiculous considering the long and short term benefits that even the slight chance of discovering a bug or problem would shy me away that much.
I guess I'm just a spoiled kid and would rather be baking things all the time than occasionally finding out that what I'm baking is actually terrible, even if usually it's merely mediocre.
In semi-related news: Radiance is coming along and it shouldn't be all too long now before I have the new beta life with the reworked Plaster and a new blog too!
Written by shinmera