Ted Theodoropoulos: How to Successfully Manage Technical Debt

By On September 13, 2012 At 10:31 am

Ted Theodoropoulos on Technical Debt

Welcome to the OnTechnicalDebt Expert Interview Series. This interview focuses on how Technical Debt can be taken on safely and managed successfully – ultimately bridging the gap between technology and business by allowing organizations to prioritize debt remediation efforts based on ROI.

Download MP3 Download Transcript

 

Ted Theodoropoulos on Technical DebtThis month we interviewed Ted Theodoropoulos – current president of Acrowire, a technology consulting group.  He has extensive knowledge working on Technical Debt in software projects. Ted has been pushing the boundaries of the Technical Debt metaphor since his detailed blog post series in 2010.

Carolyn Seaman on Technical DebtHe is interviewed by Carolyn Seaman – Associate Professor of Information Systems at UMBC in Baltimore. She is also a Research Fellow at the Fraunhofer Center for Experimental Software Engineering in College Park, MD.  She has been conducting research on software maintenance and metrics for 20 years and is the leader for Technical Debt research studies at UMBC.

1. Defining Technical Debt in Today’s Industry

Carolyn: We all know what Technical Debt is – the term that Ward Cunningham coined back in 1992. Since then the metaphor has become quite popular, even among researchers. But the definition has evolved, and we have noticed a lot of disagreements about what Technical Debt really is, particularly about what it does or doesn’t include. Ted, what is your opinion on how the term has been picked up by the industry?

Ted: My opinion is consistent with how you categorize the evolution of Technical Debt. The term has become quite fragmented and I think there is a fair amount of disagreement as to what’s included and what isn’t, even among the major thought leaders in the industry:

  • Bob Martin and his assessment of “cruft”, which is slang term for sloppy code, which he does not feel rises to the level of Technical Debt.
  • Ward Cunningham’s definition, which does not include cruft, and does not include deferred functionality.
  • Gartner’s definition of IT debt, which is closely linked to Technical Debt and includes infrastructure related items
  • Chris Sterling’s book on Software Debt creates somewhat of a hierarchy, where Software Debt becomes a superset of Technical Debt. Of course, Ward refers to it as Technical Debt.

So, there is a lot of fragmentation which has led to some obscure classifications and terminology. There are things out there in the blogging sphere, such as peering debt, platform experience debt, configuration management debt… I’m not sure what that is! But overall I feel that there has been a disproportionate focus on items related to intrinsic quality. This has been supported by a lot of folks, such as Jim Highsmith, who solely focus on building the system right. In my opinion this neglects the interdependent nature of software quality.

I am of the opinion that software quality needs to be managed holistically. And there needs to be an equal focus on building the right system and building the system right. And I just don’t think we are there in terms of defining Technical Debt today.

Carolyn: What is your working definition of technical debt?

Ted: I tend to take a broad view. For me, Technical Debt is any gap within the technology infrastructure that has a material impact on the required level of quality, which includes infrastructure items. To define software quality, I would use an industry accepted standard such as the ISO 9001. I think this definition is more consistent with a stakeholder perspective. As a stakeholder, I want to know what in my technical environment I am paying interest on… I think if we define the term that is consistent with a stakeholder perspective, we have a much better chance of the metaphor gaining traction more broadly. But until we look at the issue from this management point, we are going to continue to have these conversations among software development professionals. I think we need a broader definition and that is why I am an advocate for this type of definition.

Carolyn: In last month’s interview, Steve McConnell came to the conclusion that we have not yet reached a perfect taxonomy or classification of Technical Debt. What do you think – is it useful to categorize Technical Debt? Do you carry around a categorization in your head?

Ted: I would go much further than Steve McConnell in his assessment. I have not seen a credible taxonomy at all – Steve McConnell has proposed one, which is a great start, but we need to first reach an agreement on what Technical Debt is. Martin Fowler has done some work creating a matrix that gives perspective on different types of Technical Debt. The value proposition here is huge and I do think it’s nearly impossible to define technical debt in such broad terms like I am proposing without taxonomy. But until some sort of consensus on a conceptual model is agreed upon amongst the thought leaders, Technical Debt taxonomy would be a bit pre-mature.

At the ICSE conference last year, in 2011, I proposed forming a steering committee at the folks of the SEI. Everyone at the conference liked the idea but it never got off the ground. Once we get the consensus on the definition and framework, we can then go around defining some sort of taxonomy. Until that happens, I am not sure that that is where we need to focus.

2. Strategically Taking On Technical Debt

Carolyn: Let’s turn our attention to what Technical Debt looks like on the ground and how it manifests itself in real projects. A lot of the time we see software professionals trying to avoid technical debt at all costs. Do you think that organizations should look towards eliminating all Technical Debt in any particular product, or can Technical Debt ultimately be something healthy?

Ted: There is a clear answer to that question: Technical Debt is unavoidable and management should be the goal, not elimination. Like financial debt, Technical Debt is a form of financing and it should be leveraged. If an organization has a disproportionately low amount of Technical Debt relative to industry peers, they are probably being too conservative. On the flipside, disproportionately high amounts of Technical Debt compared to industry peers could indicate possibly too much risk. But if you think about technical resources as free cash flow (people, infrastructure, funding), then you can manage the right balance between technical debt and technical equity, almost like a financial balance sheet. Companies that have highly volatile free cash flows with the availability of technical resources going up and down based on cyclical factors, then I think that a company must assume lower debt and finance with technical equity. On the other hand if companies are experiencing and releasing minimum viable products, then it is a must that they finance those initiatives with technical debt. So I think that technical debt is healthy and management should be the goal, not elimination.

Carolyn: What type of questions should decision makers be asking themselves when they are trying to decide if it is appropriate to take on technical debt?

Ted: That is a great question and the right kind of question to be asking, because taking on Technical Debt is a business decision, not a technical one.

In instances where time to market is critical and there is some uncertainty with respect to demand, then financing initiatives with technical debt should be considered. There is a big movement in Silicon Valley with lead-start methodologies which require heavy debt financing: the least that you can do to get the product out the door to get validated learning and real feedback from real customers. This necessitates the use of financing your products with technical debt. And there is a very sound reason behind pushing forward with minimum viable products and assuming debt, because the interest probability is very low. Technical Debt has 3 main components: the principal, the interest, and interest probability. The interest probability is the likelihood that the interest is going to be needed to be paid-back. If you are in experimental mode, you probably have a relative low interest probability, so the prospect of financing with debt becomes more attractive. I think that to finance with technical debt and to do it safely, you need to manage and track it centrally. My exposure with technical debt comes from both as an entrepreneur, a technical person, and in the corporate world. When I was in risk management & corporate audit for one of the biggest banks in the world, we actually had a central system (a registration database) which wasn’t called Technical Debt (although that’s essentially what it was…) which stored technical risk related items, and impediments to productivity. That central registration database was a key management tool.

So I think that in order to use technical debt safely, we need to understand the implications of if the risks materialize, what the potential outcomes are, and what usage patterns could potentially be problematic given the technical debt present in an application or in a piece of infrastructure. Having a well thought out mitigation plan is essential: if you understand what the implications are and you are monitoring for conditions for which those implications could arise, then I think that’s the best case scenario  and Technical Debt here becomes a much more controlled and safe option in your portfolio.

3. Visualizing Technical Debt

Carolyn: Let’s dig into the management of Technical Debt a little bit more. One of the challenges organizations often face when it comes to Technical Debt is visualizing it. In your experience, have you seen any ways that people have been able to visualize either where the Technical Debt is in their system, or how much there is, and what types of debt there are?

Ted: I was on the program committee for this year’s ISCE conference for Technical Debt and reviewed several papers that proposed interesting methodologies. I know that there are some great tools out there that allow you to get some visualization capabilities.

The short answer to this question is: there are automated tools that exist in order for you to visualize your Technical Debt, but they are very new and I think these tools do need to mature in the coming years. That being said, they are a great starting point and should definitely be leveraged. Leveraging automated tools is critical in technical debt management because it is such a pervasive and widespread problem that in a big organization it is far too big to manage manually. So having good application lifecycle management processes that are automated (such as good test coverage, leveraging continuous integration, implementing continuous surveillance for risk factors, establishing KPIs) is essential. In my risk management days, we had a concept called Key Risk Indicators, which are composite metrics which can be monitored continuously through automated mechanisms. There are some great tools out there that can scan a source code repository and find indicators of poor code quality, inadequate code coverage, severe level agreement failures, poor data quality, etc. But in terms of getting a true visualization of Technical Debt in your system, this is something that is still relatively new and is still evolving in my opinion.

4. Measuring Technical Debt

Carolyn: What about measurement? Is it useful to quantify Technical Debt?

Ted: There are tools that will give you the dollar and cents amount of Technical Debt in your code base. Again, I take a broader view on what technical debt is and for me, Technical Debt is not only about the code base but also the supporting infrastructure of an application as well as its feature set. But there are certainly tools out there that can quantify Technical Debt.

Measuring principal is a fairly straight forward process. I put together a blog post at blog.acrowire.com that is dedicated to the measurement of technical debt. Gary Short also put together a simple formulate approach for calculating the principal. Calculating Technical Debt principal is fairly quantitative. But calculating interest is a bit more subjective, as it is a combination of calculating productivity cost and increased risk exposure. In addition, you also need to understand the rate at which interest compounds, i.e. workarounds which are created on top of workarounds. Interest is a more qualitative exercise but there are tools that allow you to get an estimate which is a good starting point. But nothing more than that – just a starting point.

Carolyn: Have you seen any organizations, yours or others, that explicitly quantify Technical Debt in some way or another, and use those estimates in their planning process?

Ted: When I was working with a large financial institution, they would aggregate regulatory, internal and 3rd party audit exams. These were for technical systems and would aggregate the results in order to understand if the was audit satisfactory, unsatisfactory, needs improvement, etc. And we would calculate a score called an audit index. The number that was being calculated was not in dollars or cents, it was an index, but it essentially let us know if we were trending in the right direction or not.

So to answer your question: no I haven’t seen a technical debt balance sheet. But I think folks are experimenting with that I’ve heard. But I just have not seen it in action.

Carolyn: In your opinion, this is something that could be useful – to go to the point of tracking Technical Debt separately in a balance sheet?

Ted: I see value in it but there are challenges. The metaphor has been around for 20 years and things started to really heat up in the summer of 2010 when Gartner said that there was 500 billion dollars of Technical Debt globally and it was going to grow to 1.5 trillion by 2015. Calculating technical debt in not an exact science; it all depends on how you calculate it.

When I was talking about calculating interest of Technical Debt, I was explaining how it is a qualitative analysis: what does it cost to implement a feature today and what would it cost to implement that same feature if that system was designed appropriately? This is completely subjective. So that is the only thing that concerns me about getting too granular about the dollars and cents of Technical Debt. I think that if people use it as a guide it can be of significant value. I think it’s a mixed bag.

5. Communicating Technical Debt

Carolyn: Technical Debt resides at an interesting interface between technical and non-technical. But what that also means is that in order to manage Technical Debt you have to communicate it well between non-technical folks and technical folks. Do you have any best practices in communicating the importance of Technical Debt between these two groups of people?

Ted: That is the beauty of Technical Debt: it bridges the gap between business and technical stakeholders. We talked about a balance sheet approach – I mentioned some scenarios that I have seen in practice – and I think that on a case by case basis, the metaphor gives us the visibility to help prioritize with business stakeholders and it helps prioritize Technical Debt remediation efforts.

Business people always want to build new stuff. If a system is working but is difficult for the technical team to maintain, it is not become a priority for the business people. But when you come to the table with a prioritized list of initiatives and there is a return of investment associated with each one of them, then we have a different story. Technical Debt gives you the ability to essentially calculate an ROI for a Technical Debt remediation effort. Items such as refactoring codebase, implementing missing features, re plat-forming, upgrading technology, etc. will be off the radar of the business people. But, if you attach an ROI, it gets business people’s attention. It also helps understand the value of repayment and not just accumulate Technical Debt and forget about it. But once they’ve had to wait for the new flashy CRM feature because a Technical Debt refactoring initiative leap frogged it, then the conversation becomes more productive on how to prioritize the back log. As I said, business users always want new stuff and that is never going to change. As a business user you always ask: how can I get my job done more efficiently? Coming towards someone that is being sized on that criterion, you have to attach an ROI to the initiative, which technical debt allows you to do, and the conversation becomes a lot more productive. It has tremendous value.

6. Technical Debt vs. Agile

Carolyn: Is there an inherent conflict in a team spending time tracking Technical Debt and paying it back, and also staying agile? Do those two things need to be balanced?

Ted: Actually I not know how you stay Agile without solid technical debt management practices. By definition, agile is about being responsive to the market and to the business… and Technical Debt gets in the way of that. So, Technical Debt and agility are conflicting forces. I am not sure how an organization would stay agile if they did not have good technical debt management practices. They can be incorporated into the agile process themselves and existing agile processes already support good technical debt practice (continual integration, documentation, engagement with the product owner, early feedback, and good code coverage). Using agile practices properly automatically mitigates technical debt. Where technical debt can actually add value to the agile process is where those Technical Debt items are tracked and measured and an ROI is calculated. Here the ScrumMaster forces the conversation towards: “we need a refactoring sprint and to put it in the product backlog”. Technical Debt and staying agile: you can’t have one and the other! Agile practices complement a solid Technical Debt management strategy.

Paying Down the Interest on Your Applications:
A Guide to Measuring and Managing Technical Debt

Technical Debt helps us think about software quality in business terms. This FREE whitepaper includes a formula to benchmark your Technical Debt against industry data, or adjust the parameters to best fit your organization’s own maintenance and structural quality objectives, experiences, and costs.

Your Information will be kept private and secure.