I was working on a legacy project with a friend and I sorely bemoaned the messiness of the code.
Later, the friend sent me this link and warmly recommended I keep the balance in life.
If you cant be bother to read the article, the short of it is that we developers should have more respect for legacy code that works.
I acknowledge the underlying truth presented in the article, but I don’t think it gives the whole picture.
Just because you can make catastrophic mistakes while disrespectfully accusing code of being a mess, that doesn’t mean that the code isn’t a mess.
Just because the code is rock solid because it has accumulated valuable fixes over the years doesn’t mean to see that the guy who wrote the fix shouldn’t have been
fired reprimanded for writing it the way he did.
And … just because there is some really messy code out there that works too, it doesn’t mean to say that the only way to get code to work is to make it messy.
I think this article (and Bob Martin’s book on Clean Code) offer a better balance between working code and clean code.
This article also mocks the notion of a “Grand Redesign in the Sky”, but it also proposes ways to avoid such traps altogether.
Moreover, in his book Martin also talks about the practicalities of cleaning up legacy code reliably, because, as we all know, most of the work done by programmers is work on legacy code.
That's no excuse not to write beautiful, clean code.