Technical Debt and Breaking Down "Tribal Speak"


In this great podcast from .Net Rocks! the discussion on how to handle technical debt takes an interesting turn towards the discrepancy in communication between different stakeholders on a software project. Most posts on our blog, as well as most other posts out there on technical debt, access the developer mindset. This means that when we talk about technical debt we are thinking about it from a perspective that does not necessarily help convince those managers that are focused on meeting their performance goals and have a hard time picturing the benefit of allowing a developer team to spend 20% of their time cleaning up old code.

To many managers this paying back of technical debt is a hindrance to meeting company goals because they are not understanding what is behind the term technical debt. What these managers need to understand is that reducing technical debt is a big picture goal. However, much of the weight on communicating this big picture importance of technical debt rests on the shoulders of developers - and as mentioned in this podcast, developers are not widely known for their "command of soft skills" (aka speaking persuasively to business stakeholders). Perhaps then the best way to get across the importance of technical debt reduction would be to approach it from the mindset of a business stakeholder concerned with meeting his/her performance goals?

DevOps can fit nicely into a scenario like this, as technical debt's ramifications can begin to show themselves on the operations end and therefore make its costs visible to managers. This way you don't have to persuasive when talking about technical debt, but simply show the numbers. The issue that managers mostly have with paying down technical debt is that they don't see that it is not just an expense, but that it has a return on investment.

Ultimately, communication is the main inhibitor when trying to manage technical debt. It helps to think about what technical debt really means. Inherently, the assumption is that it is a purely technical term. But technical debt is not something that comes to fruition due to a lack of skill but due to a lack of time. Time is a concept that isn't specific from team to team and therefore be used to create awareness on the issue of technical debt.

The other issue that comes about when you actually want to back and refactor code and you aren't even sure of how much debt you have accumulated. If you don't know how much debt you have how are you supposed to demonstrate the value in paying it back? If you don't address this black box complexity, debt simply continues to grow and it becomes more difficult to add code or fix small problems. Fixing this decline in velocity becomes paramount and defining the reasons for the decline in velocity is central to fixing the problem. Here is where the technical debt metaphor comes into play.

There may be developers out there who enjoy debugging complex code and finding these developers to join your team maybe the solution. However, these types of developers are few and far between. So the true solution is improving communication on technical debt between domain experts, user interface people, and developers. Improving these dormant lines of communication means developing a shared language between all stakeholders in a project.

This means breaking down "tribal speak" (developer language vs. test language vs. domain language). How do you go about doing this? Working through business cases together by going into details and questions from all perspectives can be effective. Also iterating discussions throughout the lifetime of an application is necessary; you can't just sit down once and expect everyone to come out of a meeting understanding every aspect of a project perfectly. Therefore, when meeting with all stakeholders a common glossary, to ensure that everyone agrees on what terms really mean, is imperative.

Developers are the most most adept at dealing with the ambiguities that come about from certain terms in a project because they are the ones that most often work between teams and work directly in fixing the glitches that arise in code. Just as in natural, colloquial language, software language has ambiguities.


Ex. "Cut trees down and then cut them up."


The assumption that arises when talking about technical debt is that you or someone else has done something wrong. But it is again important to communicate that technical debt doesn't necessarily have anything to do with skill level. So instrumenting and measuring technical debt (you can use tools like CAST AIP) can begin to demonstrate the cost of technical debt and help to trace out the differences between accidental and essential technical debt. Once you can measure technical debt and its cost, you can begin to see where unrealistic deadlines are causing unnecessary technical debt and what baseline of technical debt you are willing to accept in a product.

Just make sure that throughout this whole process communication does not break down and devolve into "tribal speak".

To listen to the full original podcast, visit here.

Filed in: Technical Debt
Get the Pulse Newsletter  Sign up for the latest Software Intelligence news Subscribe Now <>
Open source is part of almost every software capability we use today. At the  very least libraries, frameworks or databases that get used in mission critical  IT systems. In some cases entire systems being build on top of open source  foundations. Since we have been benchmarking IT software for years, we thought  we would set our sights on some of the most commonly used open source software  (OSS) projects. Software Intelligence Report <> Papers
In our 29-criteria evaluation of the static application security testing (SAST)  market, we identified the 10 most significant vendors — CAST, CA Veracode,  Checkmarx, IBM, Micro Focus, Parasoft, Rogue Wave Software, SiteLock,  SonarSource, and Synopsys — and researched, analyzed, and scored them. This  report shows how each measures up and helps security professionals make the  right choice. Forrester Wave: Static Application Security Testing, Q4 2017  Analyst Paper
This study by CAST reveals potential reasons for poor software quality that  puts businesses at risk, including clashes with management and little  understanding of system architecture. What Motivates Today’s Top Performing  Developers Survey
Load more reviews
Thank you for the review! Your review must be approved first
New code

You've already submitted a review for this item