“Code Quality is very low on the list of things that matter.”– Jeff Atwood (Hanselminutes #135)
“You have nothing to do in Software engineering if you didn’t ever code.”– Markus Völter (SE Radio #112)
What is code/software quality?
There are a lot of things, e.g. amount of bugs, documentation or implementation of requirements (more information: wikipedia.org).
You know quality cost time but also can save time (readability).
How to improve quality?
A great base builds Joel’s Test. Covering fast iterative development steps, source control, bug databases and testers. Moreover there’s a mantra which is useful “before writing new code fix the (known) bugs“. It’s easier to fix bugs on the code you’re written two minutes ago than on a code you’re written two years ago.
A good spec helps you not to lost the overview. You can early focus on security and availability. Together with the other points you can guarantee a better quality of your products.
Not all bugs should be fixed
“But how do you distinguish between bugs that users are likely to encounter, and bugs that users will probably never see?”– codinghorror.com
If will mention some very serious bugs you must fix. You should also fix most bugs. There are some that aren’t worth fixing. A example is a bug which only appears on the third Sunday in a year which is a prime number and causes a little message box saying “Error 0: No Error”. It’s exaggerated of course.
- Severity: When this bug happens, how bad is the impact?
- Frequency: How often does this bug happen?
- Cost: How much effort would be required to fix this bug?
- Risk: What is the risk of fixing this bug?
Also related: My life as a Code Economist
What’s certainly worth fixing?
Zune’s leap year bug (2008)
What happened? All Zune players stopped working.
twitter’s login algorithm (2009)
What happened? Twitter’s main account was hacked because they haven’t implemented a barrier against aggressive password trying.
Bufferoverflow in Unix finger daemon (1988)
What happened? A function wasn’t well programmed so it was possible to get access to every computer using Unix finger daemon.
Year 200 problem (1995+)
What happened? The year wasn’t displayed correctly.
Shrink wrap, internal, embedded, games
The importance of bug’s nonexistence varies between these genres. Embedded systems require bugless code mainly because it is embedded and you can’t upgrade the software so easily. Shrink wrap should work fine most times. If it crashes once a month it’s acceptable. Internal systems and games are even less demanding.
Release – Fix – Release – Fix – Release
This is a recommendation by Guy Kawaski (Art of the Start).
It’s a double-edged sword. You, as an entrepreneur, get fast feedback from real customers. Your customers may scared off because your product is buggy as hell.
If you work as long as there are no known bugs you may will never release your product. It’s a balancing act. Do not release too early and not too late.