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
