As more and more enterprises drive into the DevOps space, this is less of an issue, but you still hear stories that make one cringe. The idea of DevOps (and, by extension, agile) is to get products to market faster and spend less time managing/fixing. Some take the idea to be freedom to choose—and it is to some extent, as long as an organization remembers that it can be (and often is) an increasing management nightmare to pile on product after product. DevOps already demands a fair number of new products to manage, so standardizing those products is imperative to the long-term success of DevOps in the organization.
Technically, each team could choose its own toolchain, programming languages and data stores in a vacuum, ignoring the rest of the organization. But that is a terrible direction to take in almost every scenario. Yes, we have a lot more choices for languages and environments, and most of DevOps is still in development stages, so there are a ton of products to choose from. But because you can have them all in production doesn’t mean you should. I still see some pundits saying, “Let the developer choose the language.” That’s fine, as long as part of “choose the language” is “with our current architecture as the default.” Five languages or three CI/CD tools or several ARA tools is overhead—overhead to maintain, to keep skills current in and to troubleshoot. And it is overhead that isn’t going away without a project to replace it.
I’ve written about this before, and yeah, this is the agile/DevOps technical debt. It happens more than you’d think, and yes the product gets to market fast, but if the life expectancy of the product in question is more than a year, you’re going to be maintaining it quite a bit. People who point to microservices or serverless and say, “Each could be in a different language!” have never worked in a long-term maintenance setting, I would guess. It’s hard enough to eliminate redundancies that had to happen in the normal course of business/application growth; making it worse by creating redundancies based on developer whim is just a bad idea.
That could be my experience talking. I’ve lived through the “No, we can’t do that because the backend is written in (insert obscure toolset), and it won’t integrate with (insert technology du jour)” conversations. Both as a developer and as a manager. It creates future problems that didn’t have to be.
Dalibor Siroky hinted at this problem in point number three of his “Five Biggest Ways to Fail at DevOps” article, but I thought it needed a bit of an expansion. Again.
Keep kicking it, bring in new tools that add value, but don’t just build redundant chains because Developer Don is most comfortable with the programming language emoji.
