Building with bugs

I heard an argument at a techie press conference recently that put forward what I considered to be a good argument for releasing a software build with known bugs on board. The code guru in question reasoned that there was a point at which, even with bugs in place, the time it would take to re-engineer the solution did not warrant a feasible return on the initial investment in the project. So if the software worked (even at 75% effectiveness) then why not roll it out?

Fair enough right? I'm sure we can all think of a large software company or two that does this.

Well, take it one step further. Over coffee afterwards – or it could have beer, I don't remember. I heard another sagacious Java developer tell me about how she left some bugs in her code as a matter of comparatively little concern. This was in order to, as she put it, 'ensure a little job security'. As a contractor, she wanted to know that the customer would be coming back for more. So if the customer asks for something during the requirements gathering process that the programmers know will slow things down, open up security loopholes or just generally cause 'clunky' operation – then give it to them. That way they have to come back for more.

I don't think this is an overly cynical view of the industry. But I do think it's realistic. Don't you?