There is only one thing that makes "bad code" acceptable, and that is accountability. The article hints at it, the author clearly recognizes it, but it should b

There is only one thing that makes "bad code" acceptable, and that is accountability. The article hints at it, the author clearly recognizes it, but it should be emphasized more. Bad code without accountability, without a reason why the quality has been compromised, and no one to take responsibility for both the choice and the consequences of that choice, is a just crap that doesn't deserve respect. Most bad code doesn't have the excuse that it works (it usually doesn't, at least not for long), or that shipping it was an overriding priority. Most bad code is just plain laziness or incompetence. Very few of us fall under the heading of Spolsky's mythical duct tape programmers. Most of us merely competent developers can only do one of two things: write decent code that works well, or bad code that doesn't. And the fact that we are actually able to do the former already puts us in the top 20% of people that get paid to code. As long the majority of programmers either produce bad code or spend most of their time trying to clean up that crap (or rather, just keep it running), I don't see why people feel the need to keep writing apologies for the very few cases in which "bad" code was the best possible option.