Anatomy of a technical debt: for managers.

Firstly, I understand that most managers are familiar with the concept of 'technical debt'. However, it seems to me (and I believe many software developers would agree) that technical debt is not always given the priority it deserves by managers.

Managers often view the code and technical aspects of a project as a black box, simply asking whether it works or not and whether the client is complaining about it. These are the ways that, in my opinion, managers tend to approach the technical side of a software project. On the other hand, since they are managers, it's true that they are not required to perform technical tasks.

So, why should managers care about technical debt? Because technical debt can affect the project's cost, competitiveness, and profitability, and managing these aspects is already part of the manager's job. 

For this reason, I believe that managers should take care of technical debt and help to reduce it. This way, all team members can work to reduce technical debt according to their roles; 

 - architect/technical leader: constructing a good design
- developers: coding understandable code
 - managers: Creating a job framework that helps architects/technical leaders reduce technical debt.

To see this better, I will try to show it with a concrete example. I am sure that there will be better than this, but I will try my best.

Let's imagine that we are developing fire simulation software.

The very first version does the minimum: it simulates the spread of fire in a specific region, and the client can observe how the fire spreads across the cartographic map in our software.

Step 1: The users are happy as they can simulate fires and observe their evolution through the cartographic map.

Step 2: The client wants to see other types of maps, such as a digital model terrain, JPG images that represent the type of vegetation, and so on.

So, the technical leader realizes that this kind of functionality can conceal other issues and wants to visit the client and users to gain a better understanding of the new feature.

Smell 1: In the end, the technical leader is told that the feature is very simple - "it's just a matter of switching between maps". At this point, I believe that the technical lead and senior developers should visit the client and users to gain a better understanding of these new features. So managers should help facilitate communication between the development team and users. In this way, manager can help reduce tecnnical debt.

Step 2: The client wants this new feature as soon as possible, so the development team works to implement it quickly. They add a new variable, 'int m_iLayer,' to the base class CGisObject (CRaster, CPoint, CPolyline, ...). So, in this way, depending on which layer is selected in the application, the draw method will draw the CGisObjects that are equal to m_iLayer.

Technical debt 1: There may be a loss of performance in the application at this point, as the loop will iterate through all the GIS objects, even though some may not need to be drawn. And it will execute according with the numbers of layers the user is using.

For 1 to N actives Layers

begin
Foreach gisobject in ListObjects
   if ( gisobject.iLayer pertece a capas seleccionas por el usuario)
draw(gisobject)
end.
end

Step 3: Users who are using the new version have noticed that with a large amount of data points, polylines, etc., the performance is getting worse.

Now, users can switch between layers to observe fire evolution, but they realize that if they switch to another layer, they lose the previous information. So, they approach us with a new functionality.

"Transparency can be applied to layers". With this functionality, users will be able to see the evolution of the fire, the type of vegetation, and the digital terrain model at the same time, for example. So, in one view, they can analyze the influence of the terrain on the spread of fire, as well as the type of vegetation present.

Smell 2: at this point, if we choose to go fast and delivery this new feature with current design, it is going to be a mess in the future. We will be creating such a large technical debt that adding new features will become a nightmare, and it will be even more difficult for new developers to understand the code. Why? becouse a new concept of problem domain has came up, Layer, and we have not taken into account in our current design, and now, with this new feature of the transperency, we can not longer ignore the concept of Layer in the domain problem. We must do a refactoring.

What can we do? The technical leader should be honest with the manager and communicate that they need time to refactor the application to introduce the new concept of the problem domain, Layer. And the manager will have some options:

- Option A: Pushing the team to deliver the feature as fast as possible. The worst scenario. Most developers will recognize the management policy in place within the group, and they will start the 'death march'. So the manager will end up with software that has a huge technical debt, and new developers will struggle to maintain it, leading to the addition of even more technical debt as they struggle to understand the design. So, the project cost will increase because the team will spend more time maintaining the software and adding new features due to the technical debt incurred, ultimately resulting in a less efficient and more expensive project. The clients/users will be unhappy because the quality of the software is poor, resulting in performance issues, a bad user experience, and numerous bugs.

- Option B: Provide the necessary job framework, including time, resources, and development environment, for the team to tackle the technical debt and carry out the required refactoring. In this way, the refactored design can be implemented in a better and easier way to add new features. The team will see that the manager supports them, and together, they can help to keep the technical debt at a minimum possible level.

- Options 1...N: Other options that I would not know.

And how can we explain why option A is chosen most of the time? The explanation can be found in the concept of 'Hyperbolic discounting'. In simple words, "Hyperbolic discounting" means that humans prefer sooner rewards with less benefits than later rewards with higher benefits.

In the given example, if there had been a communication framework in place between the client, users, technical leader, and developers, the feature of 'transparency on layers' would have been discussed and identified in the first meeting itself.

With the result being significant cost savings, not only in terms of money but also in reducing technical debt, as the software team would have taken the concept of Layer into account from the beginning.

In conclusion, as we have seen above, ignoring technical debt can lead to an increase in project costs, loss of competitiveness, and unhappy clients/users - all of which are detrimental to business. These factors should matter to managers, who should take into account technical debt and help their teams cope with it. Technical debt is not solely a concept that should be managed by technical leaders and software developers but also by managers.

How can managers help reduce technical debt? In my opinion, as a software developer:

- Create a job framework where honest communication exists among all members of the team, including managers, technical leaders, developers, users, stakeholders, and so on.

- Managers should have knowledge about the basic technical vocabulary of the project (technology is change at fast speed, even, catching up for developers it is difficult) . So when the technical leader tells them, "We have a huge technical debt," "We must do regression tests," "To better understand the codebase, it would be helpful to pair a senior developer with a junior for a while," "We need better computers," "We need static and dynamic code analysis tools to detect static and runtime errors," "We have to consider upgrading to the latest, more stable development tools," etc., they will have an understanding of what is happening in the engine room and can take appropriate action to help reduce technical debt. Therefore, we will have a better chance of developing great software that can easily compete with other similar software.

I hope (in what I have been able to) this post has helped to provide a better understanding  of this problem from both sides of software development: management and technical perspectives.

Felix

felix.romo.sanchezseco@gmail.com