Real life coding

Code does not have to be perfect

One thing that took me a while to figure out is that in business software, code doesn’t have to be perfect; bugs can be left in the system. I originally came from a science background and the sort of code I started out on had to be perfect; a simulation with a bug is worthless and a piece of medical software with a bug can be fatal. Business software is never going to be fatal so a minor bug or two is not a problem. Leaving known bugs in the system is an anathema to many programmers (the justified programmer stereotype being obsessive perfectionists). The problem is that as a developer you can become completely absorbed in the code you are writing and forget that this code is just one cog in the machine. One thing that you need to remember when writing business software:

writing business software is not about writing software, it’s about improving the business

So, does spending two days chasing down that annoying screen update issue help the business, or perhaps could the users put up with that for now? Every bug fix is a business case: is it cheaper to get the developers to re-write code for that data breakage that occurs once every blue moon, or to just manually fix the database when it happens? Working on code has a cost (your wages at the very least), and so that cost must be used to its best advantage. As frustrating as it might seem at times, leaving minor bugs in place is often the best business strategy.

Of course, the other side of the coin is that as these minor annoyances build up, the system moves more and more towards being viewed as ‘bad software’ by the people who actually use it, and so we have to end up walking the line between wasting resources fixing annoyances that don’t really bring business benefit and having the users think that we developers can’t do our jobs properly.