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

Clean Desk Policy, really necessary? How expensive is it?

In this post, I would like to put my point of view about the clean desk policy. 

I know that it is a new trend and, like any new trend, it seems to be good in all of its aspects, but I am not a big fan of it.

I will write my arguments which may seem weak or without basis to you. So it is only my opinion. And as an opinion, it could be wrong.

It is seen that the clean desk policy was born with the 5S. The 5S stands for:

Sort, Set, Shine, Standarize and Sustain. (1)

Basically, the purpose of this policy is to maintain a clean desk, make tools and documentation easy to find, and protect critical documentation.

And can these principles, which fit well in just-in-time manufacturing, also be applied effectively in software development?

In some way, when these principles were applied to software development, the first thing to do was: no one would have their own desk.

So if no one has his own desk, everyone will have to clean the desk before leaving.And with this action, one can almost fulfill the 5S. 

It is said that a clean desk promotes a professional image, protects critical documents, and encourages collaboration with other coworkers.

- professional image: I believe that a professional image must be primarily achieved through satisfying customers. But all employee can clean his own desk before leaving.

- protect critical documents: each employee should have desk drawers with locks to store critical documents.

- collaboration with other coworkers: I believe that one should be close to the coworkers with whom they need to communicate more often. If I work on system A, which communicates with system B, I would be very keen to sit near my coworkers who work on system B.

So, if professional image, document protection, and collaboration can be achieved without the "clean desk policy," why is it so popular?

I believe that it is mostly to save costs. It is more expensive to have 100 desks than 50, isn't it?. Companies have to look for ways to reduce costs. And I understand this and they should do it.

And one way of doing it is by implementing a "clean desk policy". We could call this "hot desking" (2). But..But what about the cost of implementing the 'clean desk' policy? How would it affect the process of software development? 

Do you think that the "clean desk" reduces the cost of the software development process? or does it increase? In my opinion, implementing a clean desk policy may increase costs, but further studies would be needed to confirm this.

When a person owns a desk, they will typically sit near other people with whom they talk more often. In other words, the people who make up a team will be sitting near each other. In this way, the information about the software development can be transmitted more easily. And here is where the key is. The better the information is transmitted among the team members, the lower the probability of misunderstandings, the better the understanding about the work, and the less time required to resolve problems. Saying that, it seems to me that information is the blood of software development. What would happen if our brain, our neurons worked with a 'clean desk policy'?. One group of cortex neurons in the foot and another group of cortex neurons in the hand. How efficient would their communication be?. Therefore, if each member of the team is placed in a random desk away from the rest of the team, how efficient would their communication be?. So, what would be the cost of having inefficient communication in a software project?. Hard to calculate but not cheap.

In the other hand, when you have your own desk, you can set it up in a way that makes you more productive.

In conclusion, I believe that if a software company wants to implement the clean desk policy, it should follow these points:

1. Assign clean desk zones divided by teams, so that each software team has their own designated clean desk zone. This way, only team members will be allowed to do "clean desking" in their designated zone.

2. Create the "clean desk zones" based on the communication patterns among teams. If Team A communicates frequently with Team B, we should create a "clean zone A" near "clean zone B"."

But I must say that I prefer each developer having their own desk.

felix.romo.sanchezseco@gmail.com

Refs:

(1): https://en.wikipedia.org/wiki/5S_(methodology)

(2): https://en.wikipedia.org/wiki/Hot_racking