"[I]sn't DevOps the cure to technical debt?", Michael Churchman rhetorically asks in his article, "Technical Debt and its Impact on DevOps". He's right to do so: newcomers to DevOps and many of its zealots sincerely believe that DevOps solves such problems.
Churchman knows better. In fact, as he illustrates, "... DevOps may produce its own, characteristic forms of technical debt." DevOps encourages practitioners to operate at higher levels of abstraction. At the same time as smart DevOps practices systematically improve and simplify application code, they introduce opportunities to take shortcuts in workflow and operations that'll eventually need to be fixed--technical debts of integration, testing, deployment, delivery, and other configurable elements.
Churchman's main point is to be alert to these hazards, and to make the most of DevOps' dynamism: not only should we think about such slogans as Continuous Integration or Continuous Delivery, but also continuous debt repayment. I agree. Just as more traditional application development has more subtle measures of quality than "it works/it doesn't work", DevOps practitioners need to review workflows continuously for potential improvements.
Another aspect of this more mature perspective on technical debt is that it's not all bad. Churchman touches on this, and I made the same point in "Blessings of technical debt ..." (among other pieces): debt is a trade-off in time. Some debts represent investments worth incurring, because they allow us to come to market or take care of our customers quicker. A big part of our professional responsibility is to judge trade-offs, and technical debt is far, far more often about a difficult choice, than just a simple-minded error or frailty.
One of my biggest headaches this season is process monitors that haven't kept up with business realities, and for which no one seems to be responsible. What technical debts arise in your DevOps work? Let us know in the comments below.'
