When developing, you should really try to subdivide the work into tiny steps for motivation and simplicity. An other big benefit of the small-step programming is that you can always keep the system in a more-less releasable state – if you want to.
Before we will look at why developing with open bugs in the back is bad, lets look at the core benefit of always keeping your applications releasable. Should your software house ever need cash(for example), if your products are readily releasalke, releasing a new version is a matter of a quick Q&A test and a marketing campaign. Should you ever want to add a feature quickly, there is no need to clean up in advance.
But now on to keeping bugs in the back. If you break up your program into many tiny subtasks, you can easily test each one of them immediately after completition. This helps you to keep the program in a releasable state, as said above.
The second(and bigger) benefit is recency. If you have just finished coding a routine, the code still is in your mind(most of the time, that is). When the code is still in your mind, you will probably have an idea about where the program is burning when you see the bug and can thus fix it very fast.
The last and biggest benefit is lack of “recursive bugs”. If one bit of code is buggy, it probably affects other parts of the program inversely, making thise harder to debug than neccecary…
Overall, I have benefitted greatly from introducing this technique. My programs are better, and programming is much more fun. As with every process, your mileage may vary – but I think that you will benefit greatly!
What do you think?
Related posts:
Content, RSS
Twitter