In my work I see bugs all the time. In fact, it's all I generally deal with. You see, software is always being written, re-written, optimised, improved with new features and being tweaked. Fundamentally, because humans are not perfect (and neither is the hardware too!) then bugs appear in their code.
If software just stood still and no changes were made, people will still would be finding and fixing bugs for a long time to come. With software changing so frequently, it's a small wonder bugs keep on appearing.
Then there is the added fun of more users getting their hands on software and hence more opportunities for bugs to be found. Software gets used in ways that the original authors did not expect. Sometimes weird (buggy) hardware issues need working around, which get reported as software bugs and need fixing either in software, firmware or hardware.
There are lots of sophisticated tools now to analyse code and determine if there are bugs such as buffer overruns or dead code paths. Tools can be used to measure the code complexity - this normally indicates one needs to do code restructuring to reduce the risk of obscure bugs lurking in the complex non-trivial code paths.
That's why I keenly believe in reviewing code, testing code and making sure it is well documented. Keeping the documentation up to date is paramount, and it's a never ending and weighty task (also known as boring!).
So if you are writing code, my challenge is as follows:
1. Are you more interested in adding new features than making sure the code works as bug-free as it can?
2. Are you regression testing your code, or just slapping it out and waiting for others to find the bugs?
3. Are you keeping your code well documented and keeping the documentation up to date?
Please don't mis-understand me, I don't want to sound critical. I'm not against progress, I'm just aware that sometimes new fancy "features" have higher priority than fixing old issues. Quality matters. Without it, users eventually give up and walk away, and that's a shame.
Documentation _always_ comes last, unless you're writing an API or engine for others to use...
ReplyDelete(On all projects I've been involved with, at least)
@Legooolas, documentation also comes in form of comments in code, which should be written at time of coding, rather than an after thought. Also writing documentation when the coding is finished means it's never really done properly since projects never seem to finish :-)
ReplyDelete