December 19, 2014
Software Build Quality - Why Are We Still Not Building It Right?It's nearly 2015. This is the future we're living in now, where we all live in bakofoil houses and drive round in hover cars and our robotic assistants are powered by the juice of lemons.
Disappointing though it is that some of the key predictions of 20th century science fiction still haven't come to pass - no holidays on the Moon, no super-intelligent talking computers, and no end to disease, poverty and war like in Star Trek - the thing that disappoints me most (and this is probably a sign that I need to get a life) is that the kinds of silly programming errors we had to put up with 30 years ago are the very same silly programming errors we commit today.
Argue all you like that the undesired behaviour the users are complaining about is really a "feature", but it's very hard to build a case for software that throws out unhandled exceptions, or software that stops responding, or software that unexpectedly exits while you're in the middle of doing something important in that respect.
We all know the root causes of these programming boo-boos: trying to invoke methods on null objects, trying to reference elements in arrays that aren't that long, loops that never finish looping, threads that get deadlocked, and so on.
There are no excuses, really, in this day and age for releasing code that has quite so many programming errors in as ours seems to.
Tools and techniques exist to find these kinds of problems quickly, and also to prevent them from occurring in the first place.
I'm not naïve enough to believe we can eliminate them completely; like the bubonic plague, we might be vigilant to the very rare outbreaks that very occasionally occur. But we can get 99.9% of the way there, for sure with what's available to us.
And the real tragedy is that it really wouldn't cost us much, if any, more to do it.
One of my key focuses through Codemanship in 2015 and beyond, therefore, is going to be Software Build Quality.
Sure, maybe we built the wrong thing, but that's no excuse for not building it right. We iterate to address the former, not the latter.
Expect me to give your team a hard time about it from January onwards. You have been warned.
Posted 3 days, 19 hours ago on December 19, 2014