Avoiding the inevitable curse of technical debt
The greatest thing about our industry is that it never stops. Developers are constantly looking to build applications and methods that improve what we do and how we do it. The premise of "is there a better way to do this" builds constant elevation in everything we do. However, this doesn't come without problems. Once you let developers "play with new toys" it's inevitable that these new toys start to infiltrate into what you do and before you know it a new tool has become part of the stack, and the curse of technical debt has started.
In my experience this problem rears its head in two distinct ways.
The first one is where a tool has been used to do one specific thing and is almost instantly forgotten about. However, it doesn't really go anywhere. It's still where the developer left it, just sitting there in the stack. Over time it becomes a hindrance, a nuisance and quite frankly something that often leads to cursing.
The second case is when a developer makes the decision to use a set of tools and build them out before they've really established the development and the process. This instantly starts the process of creating even more technical debt with an end solution that blocks change.
So why do we let developers do it and can we control it? Somehow and at some point DevOps has become the excuse for allowing this to happen. The thing is DevOps is not about the tools, the tools just enable it.
DevOps is about understanding what matters to a business and how to adapt to those needs. How fast is the business changing? How fast does the business want to change? There's no right or wrong answer, after all no two companies are exactly the same and not every success story follows the same path. However, if you analyse business requirements and look at the life of the software you can easily determine whether technical debt is going to become an issue.
Ask yourself, how often do you redevelop and change things? Is it once a year, every 3 years, every 5 years or never? Which category would you fall into?
If you chose 5 years or never, then the obvious answer is to stop your developers from making the tech decisions. Stop them from introducing “single solution” tools and entrust that decision to the architects. Keep it planned and keep it documented.
If you fall into the 1 or 3-year category, should you really care if your developers use a tool for one purpose? Probably not. It is going to be changed or updated soon anyway.
The best way to determine if technical debt is going to become an issue, is to firstly determine which category of change you belong to and which one works best for your team. Finally, it's important to remember that technical debt has nothing to do with DevOps, because DevOps has nothing to do with tools. It's about culture and the process of the team.