Why legacy code can be fun

Working as a software engineer it’s almost inevitable to avoid legacy code. To me, it was always exciting starting at a company and opening the very first project/solution. Looking back, it was more exiting opening the solution than the idea of working in a new environment.

Back in the old days (feels like I’m retiring) when it came down to legacy code, I rolled up my sleeves and applied my refactoring skills. It’s almost 15 years ago and it feels like yesterday. Anyways, with positive attitude and my mind focused on the challenge, nothing could go wrong. My coffee hot and ready to give me the right boost in solving the list of urgent issues. After opening the first solution, it felt like I’d participated the ice bucket challenge. The source code contained a lot of files. The folder structure was a mess and I asked my self, how on earth can someone work like this. I was scarred to break things and the most scary part was that I had to understand the brainwave of the previous engineers. By the time I’d fixed one issue and was recovering from the ice bucket shock, I was wondering whether other parts of the application were still intact. Usually, at this point I started talking to God. Oh please God, please let me release these issues without any collateral damages.

Legacy and Refactoring

As software engineer I want to the right thing when opening a solution and finding that there is no structure at all, or even worst a combination of some structure with no structure. The right thing for me has always been either refactor or redesign the freaking peace of software. Of course, the project lead wasn’t always happy with me.

I like to share with you (the short version of) my list of legacy code/constructions that I’ve seen so far: missing layers, SQL statements in views, no structured threading (who cares, its free though, let’s create more and more threads!), no structured locking (moments like “how on earth can this peace of code work!”), craziest XML parsing methods (the one that makes you cry), methods/functions that do a lot, old comments (I hate comments above loops like “looping through the elements”. Are you kidding me!), messed up OO design (what is what and who is who).

At that time there were few unit testing frameworks available (mostly for Java) and unfortunately the bigger companies I worked for, were not using any of those frameworks. What I usually did was to create some test files to test the public functions of the classes that I wanted to refactor. Along the refactoring way, I’ve seen some crazy and funny constructions that I really like to share with you.

Craziest Feature

The most craziest construction I ever saw was a hardcore engineer (the ones you can find in caves) had written a feature that was basically a malware. He created a thread and injected this thread into another running executable where he flushed some buffers. What he basically did was, he stayed in his cave and created the malware feature instead of asking the API team to provide him a proper API interface. Basically, he solved the problem and unfortunately only on the short term.

Funniest Copy & Paste Failure

I had to review a small peace of source code. I sat next to my colleague and couldn’t follow him on his solution. I was like, you should consider refactoring this piece of code. He instantly replied, no I have copied this from StackOverflow and it seems the right solution. However, the construction didn't make any sense and still had crazy loopings.

As curious I am, we opened the StackOverflow page and noticed that the source code was indeed on StackOverflow. However, not as the solution but as the problem. In other words, my colleague copied the problem instead of the solution.

Legal Notice

For the record, I’ve created legacy code too, no doubt. Of source, I have implemented some crazy and funny software constructions. It might be the case that other engineers are having headaches of the source code that I had written.

Unit Testing and Feature Testing (TDD, BDD)

"Program testing can be used to show the presence of bugs, but never to show their absence! Edsger Dijkstra, [1972]"

Nowadays, it is common to apply unit or feature testing in the early stages of the projects. You can choose your own style/strategy for automated testing or you can apply Test Driven Development or Behavior Driven Development. Whatever you choose, it’s better than having no automated test strategy at all. Combining your test strategy with Continuous Integration and Continuous Deployment will help you smoothen your release process.

Luckily, with thanks to the whole Agile craziness, managers are more aware of the automated testing benefits. In other words, selling automated testing to your superiors is now much easier than 15 years ago. So sell it!

What is your experience with legacy code? Did you had funny legacy moments? Add it as comment to this post.