Tonight we were discussing code quality issues. During this discussion one thing came up to my mind:
Everybody is calling old code “legacy”, and now legacy is used as a synonym for code of poor quality.
Why that?
My first guess is: If it was me who wrote the code, “legacy” sounds much nicer than saying “this code is crap”. “Crap” sounds harsh, brutal, nasty.
But there’s more to it. Many developers have to deal with existing code on a daily basis. Much code. Code that is running at customers’ sites. This code cannot be all crap. People use it, so it must be somehow valuable to them. We even earn money with selling it to new customers. – But it slowly kills us. It kills our ability to change it to modernize it.
Why bother?
Most of us are aware of the fact that today’s produced code will be tomorrow’s legacy. If we allow the use of the word “legacy” as a synonym for “crap” then we have a perfect excuse for producing crappy code. – We should care more of tomorrow’s legacy. We should be proud of yesterday’s work. Today, tomorrow, next year, in five years!
For example: We live in a legacy house, more than a hundred years old. And we are proud of it. We are proud of the people who have built it. Of course there are necessary refurbishments and modernizations, but performing them is usually possible with quite low effort. – I drive a car that is 20 years old. And I love it. – Both the house and the car are legacy, but not crap.
I have a Russian friend that possessed a 7 year old Lada. It was slightly legacy but complete crap. We once bought a brand new replacement part (a rear axle). It was cheap, but crap from the start. Of course the car was running most of the time, but we often had the feeling that we were lucky to reach our destination.
Examples
Let’s imagine a huge class hierarchy. Nowadays we know that in most cases huge hierarchies are not a good idea if you want to write maintainable code. Some years ago this knowledge was not so wide-spread. But the now so big hierarchy started small, believe it or not. So if you start building a hierarchy today you are potentially laying the foundation for tomorrow’s hell. And you should consider yourself a crap-maker, because you should know better than – let’s say – 10 years ago. The knowledge that deep hierarchies are problematic and should be avoided is now a “best practice” and has been around for at least five years. This means that if you are now dealing with a deep hierarchy that is less than five years old, you can frankly call that crap.
If you even think of extending this hierarchy with more depth, that is also crap. No excuses. If a structure you have to deal with already is too complicated, adding more is not a way of producing legacy, it is just a horrible practice and it always has been. As soon as you sense the code you are working on is getting too complex, stop. Refactor or refurbish it. It will never get easier in the future. The more you add, the more difficult it will be.
Remember
Think – don’t just code!
Pair Blog about OO-Programming 
Great article. I really like
“As soon as you sense the code you are working on is getting too complex, stop. Refactor or refurbish it. It will never get easier in the future. The more you add, the more difficult it will be.”
Its obvious – but seldom followed. I need to keep this in mind, when I work on my next “legacy” (or crap) project 🙂
Actually I also think that big nested hierarchies are bad, is at least known since 1995. I remember reading about wrong uses of inheritance in the “GoF Design Patterns”-book. So yea, its a good example for your point!
Very nice to read. Have to re… nearly everthing.