"The goal of software architecture is to minimize the human resources required to build and maintain the required system"
- Uncle Bob (contributor of the Agile manifesto)
Has it ever happened to you as a manager, salesman, team leader, scrum master, CEO, CTO, that the system you are responsible for costs more and more for every little new feature to be added? Where you also find that the developers want to stop you with arguments like "unable to do", "there are too many bugs", "we have to rewrite everything"?
Then you're not alone and the tragic truth may be that you're actually the one who created the problem with your team and not just the developers.
Many companies end up in this seat and the sad truth is that, unfortunately, it is not just due to lack of skills. One major reason is that we as humans in our nature are quite short-term and think very well about ourselves.
We are always in a hurry, we think we can handle more than we actually do. We are like the rabbit and the turtle. We think we can do better, the rabbit had just bad luck. The same goes with architecture, we focus more on features then the non functional requirements regarding our SLAs for supportability, mean time to recover (MTTR), security, testability, etc...
"If you think good architecture is expensive, try bad architecture"
- Brain Foote and Joseph Yoder
There are four factors to take care of around prioritization
1 ... Urgent and important
2 ... Not urgent and important
3 ... Urgent, but not important
4 ... Not urgent and not important
Looking at architecture that is important but rarely prioritized as a matter of urgency, it is on top 2. Architecture is included in points 1-3. What many companies make mistakes is that both developers and managers typically value features in positions 1 and 3. They usually miss separating features from what's not urgent and not important to those that are not urgent and important. This mistake often ignores the requirements for architecture and design of systems and focuses instead on features that is usually not important. Which is a major reason for the creation of a technical debt.
It's just called technical debt, because it's just a debt.
Let's look at some interesting graphs.
1: 1 Red pile shows the number of employees increasing by number of releases.
It is very common for projects to start with a few participants and then increase over time. The increase in most cases is due to incorrect decisions during the work process. Most often, we have an increase in teams in order to fix bugs and maintenance, it also affecting the delivery rate of new features. Much due poor priorities.
1: 2 Product size in rows code
When we look at the next effect, more employees are added but the product size does not increase. New features create new bugs in other places that need to be blocked. We start spending more time on operations. Our lead times are also increasing because more employees increase the number of communication routes. This leads to more misunderstandings and conflicts.
1: 3 Cost per lines of code over time
When we get more employees to a project, everything we do will increase in cost and less features are delivered than when we were fewer. The reason is lack of good architecture and too much complexity around framework, structure, etc. We usually choose the cool before the productive. This is typical when to much technical depth exist in the systems.
1: 4 Productive over time
Another thief in the drama is that productivity and motivation over time decreases. When we do not feel that we are moving forward, motivation that affects productivity also diminishes. To mention is that productivity decreases not only because of reduced motivation. The increased technical debt in a system also creates this side effect over time. Much because we mostly ignored the non-functional requirements. We spent more time keeping the system alive.
1: 5 Cost per release over time
Last but not least, we have the graph of how the cost also increases over time. When we spend more time servicing and repairing the system in combination with taking in more resources, all the problems will increase. We will not solve problems this way. Does a car get faster the more horses you give it and at the same time increases the weight of the car? And will a woman get a child in a month if we give her nine men? Unfortunately, it's not that easy and it's the same with software.
What's happening now?
When we end up in this state and feel that we do not get things as fast as we wish, then not only does the product feel bad the corporate culture also does as a whole. The fact that we end up here is usually due to poor architecture and knowledge of what is required for long-term and cost-effective development. We usually think so well about ourselves that we make the wrong decisions even if they are logically feels good. It often leads us to the Dunning-Kruger effect.
Personnel also begin to quit. They do not have fun any longer, no one listens to them, they lose motivation and begin to be displeased at work.
What is usually also happening in such a state is that developers want to rebuild the system from the belief that things will get better. However, the new results usually become the same.
"organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations."
— M. Conway[3]
Conclusion
Do not ignore the fact that is required for well-crafted software. Hurry slowly, prioritize based on customer's value. Give the team the resources and education they need to create qualitative systems. Work actively with your SLAs and non-functional requirements. If too often, there are very technical discussions about details and you feel you are not coming forward, it may be a sign of low knowledge within the team. See if you can get an expert, mentor who can help you move on. If you start talking about details before you even start working with the projects User stories you are really in a dangerous path.
Spend more time on Important and Urgent, and import but not urgent before creating features that you think the customer wants because you think you know them best. They are often in the category Not urgent and not important...
Comments