bq. In your response, for instance, you say “I prefer thinking before writing code.” Well, so do I, but the fact of the matter is some people don’t and some people make mistakes based on inexperience or ignorance even when they do prefer to think before they code.
— “Michael Feathers”:http://reddit.com/info/69sq5/comments/c039uce
A standard response in our office, whenever someone says “I get an error when ever I try to X” is “Well, don’t _do_ that!” It’s always said with a wry grin, though, because we know that this is just a joke, not an actual solution to the problem. You can’t just keep sidestepping the problem by avoiding the code that doesn’t work as expected. You can’t always start from scratch. At some point you have to draw the line, dig in, and make it work. No matter how old or messy the code involved. And this is why it’s a funny joke, not a serious philosophy.
Some people in the software industry don’t seem to get the joke.
In any given online discussion of software practices of sufficient length, there’s always a few whose pat response is, “Well, don’t _do_ that!”. And when you reply that it’s not your code, it’s in legacy code, or in a third-party library, they smugly retort that you shouldn’t use other people’s code if it isn’t up to your standards.
Meanwhile, back in the real world, there are deadlines to be met, and we don’t always have time to re-write our entire software ecosystem from the bare metal up. Lousy code exists, and we have to learn to coexist with it; to gradually improve it; and to do our best to prevent the same mistakes from being repeated.
Thankfully, others have gone before us. Michael Feathers wrote -a- “+the+ book on the subject”:http://www.amazon.com/Working-Effectively-Legacy-Robert-Martin/dp/0131177052/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1204774848&sr=8-1, and I can’t recommend it highly enough. In fact, I’m going to go read some more of it now.