Refactoring legacy applications

A clean slate is one of the most convenient things in the world. I am going to show you two sheets of paper, and you can tell me which one you’d want to draw on:

Figure 5.2 – A new application versus a legacy application, illustrated

If you chose the right one, congratulations – you are now a DevOps engineer! Don’t look too deeply into this particular drawing; it’s just some rubbish I put together.

You see, DevOps engineers rarely get to work with their code. Even developers getting to work with their code is getting rarer these days. In my experience, I have only worked with a clean slate on a project in any non-personal capacity once or twice. Many of you who are just starting may have only worked with either projects you coded yourself or little template projects you may have found. However, in a real-life scenario, that is quite rare.

Even if you work with a blank slate, unless you have built assembly code with your own customized operating system, there are still a lot of dependencies that your workload relies on (and if you are doing it this way, how bored are you?).

99% of what you work with is built with something somebody else worked on – sometimes, hundreds and thousands of somebodies with varying levels of skill, competencies, and opinions. You walk a path built by a multitude of architects (and sometimes with no roadmaps/documentation).

You see, initially, it’s simple – you start with the latest version of the code, you host it on localhost, and voila, you are the master of your world. But then, you realize that everyone did this and everyone is desperate to hold onto that sense of control, even in a professional environment, regardless of the consequences upon the quality of their work. That is how you end up with critical infrastructure that hasn’t been updated in 5 years, critical services that run on discontinued products, and a team that is unwilling and unable (not either, both) to change it for the better. That is how you end up with tech debt (technical slang for horrible planning skills).

To get out of technical debt, you have three options: optimize, refactor, or restart. What that means is you have three choices (not just in DevOps, but in life too): live with your mistakes, improve upon them, or start fresh. What you want to do (and what you can do) depends on both you and your circumstances. We will look at all three of these options so that you can figure out which one is best for your workload.