The second day of RailsConf Europe 2008 started with David Heinemeier Hansson’s keynote on legacy software and was by far the most interesting and enlightening of the talks that I attended yesterday. DHH was mainly talking about legacy but I think the main message he was trying to get through was that a programmer should never stop learning, and I totally agree with that. I really regret I haven’t written about this before because now it will look like another DHH fanboy desperately trying to get to the me-too camp. Nonetheless, a couple of my own thoughts first and then on with the show.
What do you feel when you look at the code you wrote 3 years ago? 6 months ago? A month ago? Do you feel the need to throw up? Do you think to yourself: “What a mess! Who wrote it?” If yes, there’s no need to be ashamed. You should be proud of yourself, because that reaction shows that you have grown up, that you have learned, that you now see there are problems with your code you haven’t seen 6 months ago. This means that the code you write now is much better. And, hopefully, 6 months from now you will look at the code you wrote today and have the same reaction of disgust.
A really funny thing happened to me not too long ago. While I was browsing the codebase of one of our projects, I noticed a truly awful piece of code. A nightmare from hell. A couple of lines screaming REFACTOR ME NOW (which I did immediately) at the top of their lungs. After refactoring I wrote an email to our team showing the original code, explaining what was wrong with it and asking to never do it again. I made it clear that I wasn’t blaming anyone, I only wanted to educate them. After sending the email I decided to run
svn blame to see who did that. I kept telling myself I only did it so I can maybe help or educate the poor guy, but the real cause of anxiety probably was “who is such a stupid loser?” So I ran
svn blame and you know who was it? Me. 4 months ago.
OK, back to RailsConf keynote. DHH started with asking: what is legacy software? Then came several definitions: Legacy is not a specific technology (DHH quotes italicized), which means you write legacy software in any technology, including Ruby on Rails. Legacy is a function of you (your perception, tastes, knowledge) over time, so the same code may be legacy to some people but perfectly good for other. In short legacy is “an old stuff we don’t like”.
DHH showed next a hand-sketched diagram of how a feeling of legacy rises in him in every project he works on and I think most of us can relate. When you start a new project, you feel you write best code ever but as time passes you evolve to this sucks feeling and then to I can’t take it any more. Eventually you think the best option would be to rewrite it from scratch. Is the code at fault? Does it really rot just by itself? No. The code doesn’t really change, your perception changes. Which is good, because Legacy shows you that you have grown.
If you want to develop your skills and feel happy about yourself at the same time, you must acknowledge and embrace that What you write today will become legacy. It’s even worse when you’re starting to learn some new technology, because When you’re green, everything turns legacy over night. You learn so much every day that it kind of obsoletes what you wrote yesterday. This may be a problem to some people but There’s no other way. What to do when it bothers you? Just try to get over it and remember: you will not be a noob for ever.
DHH switched then to an editor and showed us some old code he wrote for Basecamp. He talked about what was wrong with that and what would he do now to refactor it. A big chapeaux-bas for courage and honesty. Then he came back to the presentation and talked a little bit what to do when you happen to work with a project you feel is a legacy. He mentioned that Broken Window Syndrome from Pragmatic Programmer may be a little devious here, because you may not be able to “fix” all the problems with legacy software at once. Instead you should try to fix and refactor problems one by one, while developing new features etc.
One of the opinions that I sometimes semi-jokingly quote is that “every software project constantly gravitates towards a point where complete rewrite is necessary”. And yet, as DHH quotes Joel Spolsky, “the single worst strategic mistake a software company can make: rewrite the code from scratch.” I agree with both statements. So, what to do? Embrace!