We, developers, work with legacy code. There are only two types of code: legacy or dead. Before your code dies it becomes legacy unless it was born dead. Legacy code must be dealt with and legacy code is never perfect. Was it perfect when it was created? Perhaps it was. A piece of code can erode because of change of the environment. This environment can be other code, integration interfaces, developer experience. The code that looked okay one day may seem to be disgusting next day or a year later. The code that one team created may just not seem okay to another team. There may be something "real" issue that the industry generally agrees today as bad practice like having 5000 lines god objects, or some discussable things like having many return statements in an otherwise readable and neatly written method. One group may agree to use a variable retval and have one return statement, other schools do not care so long as long other readability issues are not present.

There is one thing that all schools agree: whenever you fix some code in a legacy application you should not leave a bigger mess behind you than the mess was when you arrived. What is more: you are encouraged to clean the code up. If there is a bug in a method you fix write a unit test for the fix. If there were no unit tests for the method or class then create. If the method is a mess refactor it (but before that you create unit tests). If the method uses some other methods do not be shy to modify the other method so that their cooperation is cleaner. Do not be shy to modify the argument list, method signature. And if you do that you are also obligated to clean up the mess there as well.

You see the analogy implied in the title. Sometimes when the drive is not that strong I just turn around without hesitation and hope that the next place I will find will be less abominable. I am talking about code. But sometimes I just can not do that. After all, I am a programmer, that is my job: create good quality code from what is available. If the source is a requirement definition we have to deal with those. If we have use case definitions or vague user stories we go agile and do the best. If the source is a mess, we clean up.

That is the life of a coder.

Comments imported from Wordpress

gaborthere 2015-06-03 19:43:48

Quite true. I am always having a little bad feeling how quickly our code erodes - not only erodes, it gets rotten! I feel that nowadays because of the sudden change of the business needs and the emergence of better technologies, our code gets legacy quite fast.

Sometimes I am wondering though, what is the reason for this? Basic business calculations don’t change, we do calculate percentages exactly the same way as hundred years ago.

Do business requirements change? Of course they do, but I was alive in the dark ages of dBase III and Clipper, when applying those changes were made in a few hours. Oh, and that was well before inventing the meaning of "agile", and "unit testing" was going out for serious drinking. So, the "fundamental complexity" in our work does not change that fast.

Does technology change? Errr, this is a definitive yes. Just have a peek at the rate how HTML5 and CSS3 started to rule the world of web, and how quickly we got Java7 and Java8 after a many years of deep sleep of Java. I believe things are even more tricky on other ends: C# came up from nothing, and taken over Java in quite many aspects recently. Oh, and let’s not mention the paradigm shifts, MVC, SOA, DDD, CQRS, and what not…​ pulling data out of the database with ORMs, and so on, and so fort. I feel that we have a way too many "accidental complexities" in our world.

I tend to feel that we start using technologies immediately, because they known to be "modern". But I propose to start using techologies if a new technology makes our work easier.

Write less code. Write more powerful code. This way it is hopefully easier to tame the rotten parts!

Stefan Reich 2015-08-02 13:23:19

I think I have solutions for that "legacy code" thing. It’s

-storing as source code -having an engine that works on source code to keep it up to date

Well that’s basically it. Both is being realized as we speak in the JavaX project. :)

Comments

Please leave your comments using Disqus, or just press one of the happy faces. If for any reason you do not want to leave a comment here, you can still create a Github ticket.