One of the common things we find in Enterprise organisations looking to move to a DevOps model is high levels of technical debt.
To be more accurate, they are caught in the “vicious cycle of technical debt” to the point that trying to ship anything in a rapid, agile way is nearly impossible. It’s the Greek Debt Crisis level of technical debt.
In many cases layers and layers of process and management have been added into the software development lifecycle in order to try and fix the symptoms of the problem (low quality releases, bugs in production, unstable environments, poor performance etc) but they are just Band-Aids on the underlying issues.
So how do we get out of this death spiral before the organisation can’t compete anymore and a disruptive innovator comes along and eats their lunch?
Well, one trend we see is people looking to DevOps automation to try to create the breathing room they need to break out of this vicious cycle and try to create a virtuous circle instead.
If we can automate some of the routine, error-prone and time-intensive tasks we can leverage that productivity gain and invest that time we’ve freed up into re-paying technical debt.
As we pay back technical debt we get a higher quality, more stable and more agile application, we can then re-invest in more automation to start the next cycle of improvement.
We know that this works because we’ve seen it and done it with clients BUT it comes with a caveat (or two).
Firstly, you need to get commitment from the Product Owner etc that the productivity gains will be spent on paying down technical debt and not on an endless cycle of feature bloat (that was probably one of the causes of the problem in the first place).
I’m not going to wave a magic wand and say that this is easy – it’s not – but if you can find the right analogy (“Technical debt is like walking through quicksand” or “Technical debt is like trying to run a marathon with an 80lb backpack on” or “Technical debt is what start-ups don’t have…”) then you might have a chance.
Secondly, DevOps is more than just A for Automation – it’s Culture-Automation-Lean-Metrics-Sharing (CALMS) – so ideally you’d doing more than just “automate some stuff” and begin to start looking at being “product-centric”, coaching your product owner to understand operational requirements and moving away from the Finance-driven project-centric model.
I’d love to hear some stories from our blog readers about how you’ve paid down technical debt, what your “tech debt repayment model” looks like so please leave some comments or links to your own blog thoughts in the comments below
-TheOpsMgr
Reblogged this on MTE Advisors.
Here’s a story of a simple way my team figured out to prioritize tech debt and get the product owners to commit to momentarily slowing down to fix it so that we could speed up in the long term.
https://www.box.com/blog/three-letters-saved-my-tech-debt/
Nice Ben, I like the approach for both assessing the impact and the effort-based cost/benefit analysis. You should try and talk about this at a DevOpsDays, I am sure people would be interested.
Nice Ben, I like the approach for both assessing the impact and the effort-based cost/benefit analysis. You should try and talk about this at a DevOpsDays, I am sure people would be interested.