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:
- 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.
- 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.
- 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.
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...
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.
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...
"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...
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,...