For some reason, currently unclear to me, I’ve just been lying in the bath thinking about code defect densities.
It started with me thinking about the partner collaboration where my code review showed up something like 600 bugs in 2000 lines of code, thats not counting the generic ‘memory allocation can fail and cause a crash in all sorts of places’ style bugs (these are embedded systems, after all, and if you’re making the assumption of having memory management you have to make the assumption it will also fail to allocate memory sometimes – the other conventional option, which they claimed they were following, but they clearly weren’t, is to pre-allocate everything you need and deal with it yourself). This included an IPC boundary they’d inserted with the assumption that the processes on both sides of the boundary had the same memory space, not a valid assumption for the target operating system, however it would work in the emulator because that relied upon Windows (lack of) memory protection.
But then I remembered, with some horror, the highest defect density I’ve ever encountered in ‘production’ code. The density was amplified by the evil of copy and paste, a single function being rendered useless by bugs is, perhaps, forgivable, to have a whole file made of around 8 copies of the broken function with different names is another story.
When I asked ‘what is this code supposed to do?’ I was told that it was obvious. It was, if I had believed the function names. But I couldn’t make any of them behave how I had expected from the documentation (such as it was). These were all ‘hand crafted’ optimised accelerator functions for graphical manipulation, so they dealt with merging two bitmaps into a third (details lost in the mists of my memory) based on an alpha channel. How difficult can it be? Each line of each function contained the following (plus some more I’ve forgotten):
– Brackets in the wrong place so the boolean function was taking precedence
– Alpha channel documented as being 0-100%, actually was on a range of 255-0 (the wrong way round)
– Colours leaked over from blue to green to red if you weren’t careful
– Bad memory reference
Both of these examples had never been run on target hardware, because if they had they would have failed, there was no way they would ever work in an environment with any kind of memory protection.
Still, there is some consolation in the fact that neither of these projects are now maintained.
1 comment