All developers have responsibilities in business life.
We have to deliver the task before the deadline.
We have to go into production with the app as soon as possible
We have to fit our development schedule according to Stakeoholder’s requirements or consumer’s
and so on and so forth…
So, these responsibilities sometimes force us to have a mindset that drives us into a crazy rush in development! Due to this rush, we may end up writing code without caring about clean architecture principles and saying “we can deal later on”. This results in spaghetti code and bad architecture.
The Clean Architecture book defines this delay in architecture maintenance as “overconfidence”. We will discuss why this “overconfidence” is problematic.
The book talks about a company that wants to stay anonymous, but they shared their data for a software project. The data is shown with graphics and we will shortly analyze the graphics and talk about what is going on.
We have 8 release periods of data in these graphics. Firstly, we have data about how engineering staff increases through this time.
As it is seen, the company hires more Technologists and engineering staff is increasing over time. This may look to you as if the company is growing, things are going well, etc… However, Upcoming graphs are not saying so!
Another graph shows the product size over the same time.
As you can see in the graph, it shows us the product is not growing as much as the engineering staff. So there has to be a problem, right? 🤔
Let’s continue with another graph that shows the cost per line of code (LOC) over the same time period.
Again, there is a critical problem! Cost per line of code is increasing over time, though there are more developers as time passes.
What about productivity? It is here:
Productivity is going down drastically as time passes.
After all these graphs, there is a much worse graph for the whole company and the project. Which is:
My goodness! Payroll is increasing exponentially after each release! What is going on with this project?
Think about what happens when the executives see this data. Think about the future of the project. Let me say, probably the company will go down or stop the project.
What Was The Problem?
In Aesop’s stories, there is a story about the hare and turtle’s race as you may all know:
Hare trust himself so much that he sleeps during the race. However, this overconfidence of him causes his loose because turtle was consistently and regularly walking and passed the finish line before the hare, even if she is much slower than the hare.
Similarly, the writer gives us a nice saying:
"The only way to go fast, is to go well." Robert C. Martin
As a result, we can say the turtle was faster because she was going much well than the hare. I can hear you say “What is the relation of this story to development?”
Here is the relation:
The book talks about the “OVERCONFIDENCE” of developers. That is like these:
“Let’s implement the feature first, then we can fix the mass anytime.” “I can handle after the release, let’s first make it work!” etc..
We, technologists sometimes think in the above ways like the hare. Hare was saying “I can continue later on the race because I am faster”.
We are meaning something similar which is “We can handle the mass after development or creating the architecture, we just need to be faster now.”
The problem here is not developers are sleeping, instead, they are working really hard but they are "not working well". The architecture is not taken into consideration enough just for the sake of speed. However, this speed is useless because the badness in architecture causes a mess which results in difficulties for:
Adding new features
Testing
Maintaining
Understanding the project
etc…
These difficulties make us much slower, even if it decreases our productivity to nearly zero.
The problem (in the company) was this actually. The architecture was not clean enough and the reason for this bad architecture was trying to be faster. However, as we saw in the graphs, it is not possible to be productive or faster without a clean architecture although the developer resource is increasing over time.
To conclude, “Overconfidence” of believing ourselves that “we can fix the code later” is a toxic mindset and causes us to be slower.
So, “The only way to go fast, is to go well.” 😉
See you in the next posts… 🤓
Comments