Technical Debt – The Anti-DevOps Culture

Developer Support

App Dev Manager Silviano Blea explores the idea of how “technical debt” can work against an organization’s ability to adapt and transform in their DevOps journey.


Technical Debt can be defined as as “the concept in software development that reflects the implied cost of additional rework caused by choosing an easy (limited) and faster solution now instead of a using a better approach that would take longer”. I will also define Technical Code Debt as the IT infrastructure and development artifacts (usually coding) that are created to solve a business problem in the short run instead of applying the best overall solution. It reflects the decisions made under time, technical and/or cultural constraints at a single point in time. This can also mean more Tribal knowledge – The Anti-DevOps Culture gets inserted into a project or environment over time without considering the overall design, architecture or implementation. The additional cost of refactoring or re-implementing a design grows over time just like interest in monetary debt.

Over time, the “debt” grows and requires organizations to eventually pay the debt in full and with compounded interest! Organization must ensure they have a handle on their current technical debt and any cultural habits that might contribute to it. They must ensure technical debt has been rooted out through adopting an awareness of it in their DevOps journey and culture. In my experience, overcoming a project’s technical debt (typically code) has always been vital in a successful DevOps transformation. This is one of the pillars in adopting a true DevOps mindset.

In the days prior to DevOps, keeping and carrying technical debt would almost always win the business case. DevOps has changed this philosophy and cultural mindset. With Agile and DevOps principles & practices, tools like Pull Request (PRs), Coding Peer Reviews, Continuous Integration (CI), Continuous Testing (CT), and Continuous Security (CS) and Continuous Deployment (CD), will allow integration and automation of refactored/re-designed code bases in a repeatable fashion. Since the Agile Manifesto is at the heart of a DevOps transformation, here are the key DevOps cultural points to adopt:

  1. Build it into the plans and sprints. Take the time to remove both small and large technical debt for the greater good of the team. Managers must actively promote and reward this behavior to drive out technical debt. The bigger the debt, the bigger the reward.
  2. Refactor often. If things are difficult or painful to modify in the code, consider re-design and/or re-implementation. This will likely need to be done several times to get an optimal solution. Managers must actively promote and reward this behavior to drive out technical debt.
  3. Take the long-term approach. The goal here is to measure impact rather than activity. It’s not about Source Lines of Code (SLOC) or team metrics (capacity, burndown, velocity), but rather the overall impact these changes can create in the long term. See this as an opportunity rather than mistakes. Managers must actively promote and reward this behavior to drive out technical debt.

For organizations to have a successful DevOps/DevSecOps journey, they must identify and remove the technical debt that impedes this progress. This requires a champion in management to make removing technical debt a priority and reward those that take initiative in removing it for the team. By taking a different approach to technical debt, running toward it rather than away from it, you will setup your organization for success in the DevOps journey and change your culture at the same time. Don’t let any accrued “debt” and “interest” in your DevOps journey derailed your digital and cultural transformation.

 

5 comments

Discussion is closed. Login to edit/delete existing comments.

  • Michael Taylor 0

    I have to disagree with your tech debt definition. It seems to imply that a shortcut or shortsightedness caused some subpar code to be written. While this may be cause for some TD it is by far not the most common. TD is any changes that are needed for technical reasons, not tied to business requirements. Things that fall under TD, and which do not in any way indicate somebody messed up, would include things like updating code to follow new practices or take advantage of new features that weren’t available originally. Async support is a great example. There is no visible business benefit, it is just TD. Another great example is when some company deprecates versions of their framework/library and expect you to update code. Again, you didn’t do anything wrong but have to update your code anyway. .NET Core is a great example but it applies to just about any third party dependency you have.

    Based upon your definition and somewhat implied in your discussion is that in a perfect world where everybody followed CI/CD there were never be any TD because all code would be forward thinking and no shortcuts would be made. Even if this perfect world existed we’d still have new features/optimizations made available and deprecation of dependencies that would mandate TD. There is no way around TD irrelevant of any process.

    What I was hoping for in this article was some solid suggestions on how to properly ensure TD is prioritized and worked on as part of an agile process. Other than a point about it needing to be prioritized, what I heard was “if you have TD you’ve done something wrong, fix your process”.

    • Patrizio BrunoMicrosoft employee 0

      It’s a misconception to believe that technical debt has anything to do with code/projects growing older. Technical debt in a project does not happen when the then cutting edge technology that has been used at its beginning, has over time become obsolete. Technical debt is the deliberate choice to postpone best practices in order to speed up the release. In an Agile project, you’re supposed to design an MVP for the first release, removing features, not best practices, and then iterate quickly to add the missing features in subsequent sprints. This way you don’t produce technical debt. If a new technology comes out and you need to update your software, that’s a matter for a new product/project, as requirements changed and the old product will share with the new product the name and possibly some of the interfaces, but it won’t be the same design/code.

    • Dirk Detering 0

      “TD is any changes that are needed for technical reasons, not tied to business requirements. Things that fall under TD, and which do not in any way indicate somebody messed up, would include things like updating code to follow new practices or take advantage of new features that weren’t available originally. ”

      Well, you are talking about technical tasks(!) vs business features, and the prioritisation of these. That alone does not make up TD.

      Technical Debt, as the term is related to monetary debt, has another aspect. Debt in this sense is taking the cheap solution/money/whatever now and accepting the higher effort/cost/whatever later.

      When the current code was written at a time where e.g. async did not exist, then it is no TD that it had been written without that feature.
      You simply had nothing gained in the short at that time.

      Writing new code now that avoids async from the start because code is delivered two weeks faster, but knowing that you will need it at some later time and the refactoring will cost four weeks, that is TD.

      Well, and indeed not refactoring the old code to use asnyc now as it would take two valuable weeks, while knowing that due to further development it will take four weeks or even more in two years when you cannot satisfy the client’s needs without it any more, that is TD too.

      In both cases it is the short time win and the accepted long time pay.
      If the decision to go that way is a necessary evil due to business pressure or simply “messing up” due to short sightedness, may be disputable.

    • cheong00 0

      I agree, and plus changes needed for bureaucratic reasons.

      Say, for my current project, I have to introduce a lot of useless UI items, and time consuming redirection between steps, to satisfy the UI guideline that someone already left the company made.

      I think whoever takeover that project after I leave will scratch his/her head when seeing these artifacts, and hopefully they’ll learn to ignore them quickly. (I’ve tried to limit the damage by only do simple things, hopefully doing no harms)

    • Silviano BleaMicrosoft employee 0

      Thanks for the feedback. I definitely plan on writing another blog post to address the different types of technical debt and suggestions on how to reduce/removing TD. The initial post was to bring attention to the fact that Technical Debt (the classical case) needs to be a high priority for a true DevOps Culture.

Feedback usabilla icon