Hi PPM practitioners! The concept of technical debt came up recently with a customer and it provoked quite a discussion. So, I thought I’d share a few insights about this fondly (or not-so-fondly) used term.
What is Technical Debt?
Let me start by saying that I don’t profess to be an expert in code design, although I have warm memories from days of compiling PL/1 and Cobol code to get the Assembly machine language to look for code inefficiencies. Anyway, the term “technical debt” has been credited to Ward Cunningham, one of the authors of the Agile Manifesto; he used it as an analogy to describe refactoring they did on a financial application. As he said, “Some problems with code are like financial debt. It’s OK to borrow against the future, as long as you pay it off.” See www.agilealliance.org/introduction-to-the-technical-debt-concept/. Great analogy!
Organizations have continued to broaden the use of technical debt as a metaphor for anything from temporary code, outdated code and dirty code to design flaws. No wonder my suggestion that my client had incurred technical debt with their use of CA PPM provoked such a negative response. I think Cunningham’s intent was close to my meaning: In the context of CA PPM, I use the term to mean that making customizations to the as-shipped product that deviate from CA recommended and supported practice will eventually incur operational support costs. Such customizations may require future remediation or refactoring after an upgrade or to become compliant if the customer moves to a CA software-as-a-service (SaaS) architecture. An example of this would be performing direct database updates using a gel process or via data manipulation/definition statements. Technical debt does not necessarily imply poor technical design—rather that one should consider that remediation will likely be needed sooner or later.
When Does CA PPM Technical Debt Make Sense?
The answer is ultimately up to each customer. From my experience, it’s always best to minimize customizations, but customers running CA PPM on premise will occasionally employ customizations to support a business requirement. In those scenarios, the customer has carefully weighed the pros and cons of supportability / maintainability and has determined that the value gained from meeting the desired business outcome exceeds operational costs of remediation due to an upgrade, feature redesign, or future decision to move to SaaS. Refer to CA’s customization policy for guidelines.
Readers interested in more detail around CA PPM can check out DocOps. I encourage you to participate in the best-in-class site, where you have access to your peers, events and support. You can also reach out to CA Services for information about CA PPM and individualized business outcome references and analysis. Feel free to post in the comments section of this blog or contact me directly via email and Twitter @kdobsonppm.