Management-level bugs fixed at the development level.

Management-level bugs fixed at the development level.

The following lines are solely my opinion, and I'm certain that I could be mistaken.

The next lines are likely to be familiar to all of us, but I believe it's necessary to emphasize them.

I believe that most of the time, it is assumed that bugs only exist at the development level. This assumption stems from the fact that when something is wrong with the software, who has developed it? Yes, the software developer, programmer, software engineer... So, who is going to shoulder the blame? Can you guess? ;-)

So, at what other levels can bugs exist? For example, at the management level, human resources level, and so on. At these levels, a bug can be more costly than at the development level. Even a bug at the management level can result in several software bugs. I will attempt to provide some examples. However, these management-level bugs will not be visible to the customer or the final user of the software; They will only experience the software bugs, poor quality, lack of user-friendliness, and so on,..

Let's go to see same examples.

"Recruitment Policy": If management does not take care of this and does not pay attention to finding the best profile that can fit better into their project, it could lead to more software bugs. If during the job interview, you only ask, "Do you know C++? - Yes - Okay, perfect, you're hired," and ask only a few superficial questions, it doesn't predict well for your project. Why? Because maybe the new developer knows C++, but finds it challenging to read source code written by someone else. They might also introduce anti-patterns that make the app more error-prone and less maintainable, ultimately resulting in more bugs. On the other hand, for developers, if you're in a job interview and are only asked if you know C++, it can give you some insight into whether they truly care about software developers.

"Wrong Technology": If, for some reason, management has decided to use a particular technology, the programmers will not only struggle with the project's inherent complexity (essencial complexity) but also with the chosen technology itself (accidental complexity), making the development process even more painful. If the wrong technology choice complicates the project, there will likely be more errors and a higher chance of project delays.

"Poor Environment": The environment encompasses everything surrounding the project. This includes the personal computer you use, whether the company provides excellent restaurant services, whether you have access to the right development tools, and whether your manager is open to providing new software development tools. These factors can make a significant difference. Additionally, a psychologically safe environment where you can freely express your opinions without fear is crucial. If the environment is not conducive, developers may feel that management doesn't care about them, which can affect their dedication to the software they are developing (performing regression tests more efficiently, generating new ideas to enhance software quality, etc.).

"Polling Management": This type of management involves constantly asking, "When will the functionality X be finished?" week after week, but it doesn't involve asking if you're facing any problems or if they can offer assistance. This management approach can create a negative office environment. "Polling management" can be done even by my mother ("Have you tidied up the room?", "Have you tidied up the room?", "Have you tidied up the room?"), but the challenging part is attempting to help developers meet their deadlines. The latter approach is more beneficial.

"Misunderstood requirements": Most of the requirements are gathered by the management, and an error in this phase can result in significant bugs. This is because, based on these requirements, the software architect must design an initial draft of the software architecture. If the requirements are incorrect, you might end up selecting the wrong architecture. Changing the architecture of an application can be quite expensive.

So what happen when the above happen? in my point of view, these management bugs are trying to solve at development level. consequence? death march, burnout, stress, unhappy, high rotation,...So I believe that each level has own bugs, and each level must to learn, think about, improve each day in order to reduce them.

Indeed, there will likely be more management-level bugs, but the crucial point is that these types of bugs are indirectly visible to the customer through the multiplication of issues within the software application. This can result in numerous bugs, significant delays, and poor quality."

If you are a manager, perhaps this can offer you another perspective. It's also evident that I may not have an in-depth understanding of the management role. However, I believe that if we all have a better understanding of each other's roles, we can collaborate more effectively. And if you are a developer, you may come to realize that it's not always our fault. When a software system encounters issues, responsibility should be shared among ALL team members and individuals involved in the project.

I hope this sheds some light on the fact that bugs can occur not only at the development level.

Best and happy design&coding.

felix.romo.sanchezseco@gmail.com

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