The tip of the day: If you want your days to fly by, without noticing, without getting anything constructive done, go and buy yourself a current generation game console. I mean, sheesh. I bought a PS3 last Saturday, and all free time I've scrounged together has been spent on playing various games.
I finally got the annoying bug from my previous post fixed (unsurprisingly, this was actually before I bought the console). It turned out to be much less of a hassle than I thought, and the multitag code more elegant than I remembered. Maybe I should look at my old code more often, huh? But the bug was a huge weight off my shoulders. I can only guess why I took the bug so heavily. Perhaps I'm too set on working through tickets until I get to the first release. And I had a revelation.
Treating bugs as setbacks, mishaps or deviations from the normal programme is the wrong approach. Ever heard of the claim about there being one error in every thousand lines of code. After searching the vastness of reliable sources (read: googled about for a few minutes), I've noticed that this estimate seems to be a bit cautious. Some sources talk about 20-50 bugs per KLOC when doing your average coding, down to just below one bug per KLOC if doing stuff properly (formal methods and such) or even zero bugs in 500KLOC if you're NASA. But, take the very respective 1 bug/KLOC rule-of-thumb - LightFrame would have by that measurement alone around 7 bugs (which must be a dramatic underestimation). So, getting towards my point, it's pretty much inevitable, unless you are going to great lengths to counteract this, to have bugs in your code.
So why is it a blow to the head when a major (or even minor) bug surfaces? It should be treated as a speical kind of feature. A feature that just needs a little more tweaking. After all, everyone should take into account a testing period for any larger programming task. It shouldn't be regarded as a setback. It should be regarded as a chance to make your software that much better and take lesson of the bug, try to remember what went wrong for the next time when you're programming something similar. This isn't even all that big of a detour or "waste of time" when using the Zero Defects methodology.
Time for a shower and then some ticket-reaming!
Tuesday, June 17, 2008
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment