Technical Debt, a.k.a. “Not-quite-right-code” at Prezi
My Master’s thesis this summer was all about technical debt — researching its background, its prevalence at Prezi, and developing tooling to get a handle on the problem. In this short article, I would like to share with you some interesting insights I found analyzing some of our repositories.
The debt metaphor
Starting off, it’s important to understand what we mean by the debt metaphor. We use technical debt often since it effectively bridges the gap between different teams’ technical understanding. Everyone knows what financial debt is — a short-term “benefit” that will later need to be repaid.
Technical debt can be thought of the same way — engineers take a shortcut to develop a feature quicker, which saves time and provides leverage for the company (eg.: go-to-market faster). However, this code needs to be fixed over time, to avoid bankrupting a project. Bankruptcy means that a code is riddled with so much debt that it becomes unfeasible to maintain.
Researchers have also shown that technical debt ages badly (“The poor getting poorer”), which means that a project with a high amount of debt will degrade much quicker than one without [1].
Technical debt awareness at Prezi
You might ask: Okay, but how much technical debt do we have at Prezi? Since technical debt is a subjective term (it’s hard to measure what counts as debt in a codebase) it is important to understand how engineers see this in their everyday life. I conducted a small survey (30 participants) amongst Prezilians and we can see some interesting results. 78% of those who took part in the survey said they encounter technical debt in their work, which shows the prevalence of technical debt in everyday development.
Interestingly, while 61% of respondents say they are aware of the amount of debt in their projects, the overwhelming majority say their work is slowed down by this debt.
At the same time, most of the respondents say they make time to repair the technical debt they owe. This shows that while technical debt is encountered every day, that debt is also continuously repaid by engineers at Prezi. This continuous repayment of debt is done during SES (Strategic Engineering Space) which is Prezi’s framework to manage technical debt. In short, SES is a week-long event that follows a monthly cadence and allows engineers to spend their time on quality and the elimination of technical debt.
The most common type of debt encountered by Prezi engineers is Architectural. This type of debt refers to problems with a project’s architecture, such as broken modularity or incomplete interfaces. The debt affects requirements such as robustness or performance, but can usually be repaid with code refactoring. From a managerial perspective, architectural debt means that more developer time should be allocated to repay the debt. This debt is mostly invisible to the customer.
From a managerial perspective, it is good to see that engineers at Prezi are generally happy with in-house processes, rating it as the least commonly encountered technical debt.
Visualizing debt
As a visualization company, it’s only fitting that we try to get a handle on the technical debt problem with a visualization tool. Therefore, I developed a small application that can generate and visualize different types of historical code analyses of Prezi repositories.
What is historical code analysis? It’s a method described in the book “Your Code as a Crime Scene” by Adam Tornhill, which relies on the version control history of a given codebase to generate insights into its quality. You can check out the open-source code-maat tool, which is a great way to start analyses.
The main purpose of the app developed is to provide a simple interface that wraps code-maat to generate analyses and make sense of the results for any Prezi repository (or basically any git repository).
So, how does it work? The app is made up of two projects: a simple node “backend” that parses git history, runs the analyses, and generates an offline catalog of results in a JSON file. The results are served as static files, so there is no need to run a dedicated backend server to see the results.
The other project in the repository is a small React app that parses the catalog of analysis results and displays an overview with different visualizations and summaries. The goal is to give engineers an easy-to-understand overview of the main technical debts in a given repository. The result looks something like the following (anonymized):
The results can be used currently for the following analyses:
- Domain experts (top contributors) — Who knows the most about this codebase?
- Sentiment analysis (word-cloud based on commit messages) — What are the most often used terms regarding this repo (eg.: “fix”, “bug”, “feature”)
- Hotspot analysis (files and their change frequencies) — What files are touched the most often? Should these files be touched so many times?
- Code churn trend analysis — Is this repository unstable? Has the velocity changed when service ownership changed?
Evaluation
Let’s see a couple of real-world examples and see how the results can be interpreted for different Prezi services.
The first example is of a notoriously bad service. Let’s see the sentiment developers had with this service when adding commits to its repository:
It’s visible from this word cloud that engineers are most often fixing issues or updating dependencies here. Let’s compare this with an active and generally “happy” service:
This word cloud includes references to adding new features, as well as a steady removal of unused code as part of a big refactoration effort. The most often used word in this repository is “Add”.
In another interesting chart, we can see how the above mentioned refactor removed hotspots from this service’s code. This Django service was heavily refactored, going from hotspots like this:
To this:
As you can see, the hotspot of view_helpers.py has been split up and it’s gone from the list of hotspots - neat! The change frequency of the listed files is also more evenly distributed compared to what it looked like before.
As Prezi is using a micro-service architecture, it often happens that a service changes ownership, and a new team needs to learn the new stack. To help us visualize such transitions, the code churn analysis comes in handy:
As you can see from the graph, a team was removed from the owners and the velocity of development halved on this service. While this is not in itself a bad thing, it’s nice to see these changes visualized with context. This chart shows added and deleted lines of code, which is a good gauge of activity on this service.
If you draw a trend line over these, it’s possible to calculate if code churn is increasing, decreasing, or keeping a steady pace. This can be a good measure of code stability as well — reliable services usually have a stable pace of changes. The trend here is -0.27, which is counted as a “Normal” pace for this repository.
Further reading/watching (Prezi Video!)
I hope you enjoyed this quick summary of learnings. We plan to open-source the visualization tool, but in the meantime, you can view some analyses on your own with the code-maat library.
If you liked this article, feel free to read the full thesis available here.
If you want to watch a video about the thesis instead, this is me practicing for the final presentation: Prezi Video.
Big thank you to everyone who helped in the research/interviews/evaluation/presentation of this thesis!
[1] Ampatzoglou, A., Ampatzoglou, A., Chatzigeorgiou, A., and Avgeriou, P. The financial aspect of managing technical debt: A systematic literature review. 52–73.
