“Technical debt with DevOps? I thought DevOps was the solution to technical debt?”
The statement above is both true and false. It’s important to understand what characteristics behind DevOps that doesn’t automatically make it the magic solution to technical debt. You also need to understand how DevOps actually can create its own type of technical debt.
Technical debt with DevOps
Technical debt is, as you probably already know, code which doesn’t quite live up to the standard regarding design, runtime or other qualitative measures. This type of code is not a problem in itself, but can create unneccessarily tough situations down the road. We usually compare technical debt to the more known financial debt, as a tool that sometimes is useful but can also create trouble if you take it too far. This means that if you neglect the technical debt you generate, you increase the risk of bugs that take up a lot of time to fix. You might also face problems with project deadlines, time requirements and rising costs.
DevOps, together with continuous integration and continuous delivery, is often claimed to be a turn-key solution to technical debt. This is in part true, since manual release management and testing often enables more technical debt – solutions such as uniquely setup test machines, hand-crafted settings, ignoring error messages and quick-fixes for bugs often lead to problems later on. With DevOps, you aim to automate as much of this as possible. By doing so, development are forced to face these issues early on in order to ensure smooth automation.
However, there are cases when you can’t avoid technical debt with DevOps. These are cases where the debt isn’t in contact with the various elements of DevOps. For example, when a piece of bad code won’t get in contact with QA, deployment or operations you risk running it through the pipeline without noticing it.
The hard truth
The fact is that there is no methodology in the world that can completely eliminate technical debt. If it’s more cost efficient for a company to ship a product of lower quality, they will do so regardless of their development methodology. With that said, it does matter when it comes to managing and processing the debt. Further, it’s important to remember that if the cost of processing the debt outweighs the cost of keeping it, the code will most likely remain as it is.
To repeat, you are not immune to technical debt with DevOps. Using a fast-response focus and continuous delivery, the risk of quick emergency fixes to problems remains. For organizations adapting DevOps, there will almost certainly remain technical debt since before the transition. This debt could become extra difficult to manage if it’s already deeply integrated in the product.
So why DevOps?
In conclusion, there certainly exists technical debt with DevOps. So why use it at all? The real power of DevOps in regards to technical debt is its underlying flexibility and dynamics. When using short and quick iterations and the philosophy that everything both can and should be changed and improved, you open up possibilities for fast debt processing. This means that sooner or later the existing debt will be taken care of. It all uses the same dynamic processes that DevOps use throughout the entire development cycle.
Have you faced technical debt with DevOps? Tell us you story in the comments below!