If you work in IT and communicate with clients then you perfectly know the situation when a client wants everything to be done at short notice and with minimum expenses. «A client» could also be your product manager, project manager, head of your company etc.
At this moment I try to explain that this will result in a non-maintainable code. If your client is concerned about a quality of a product, it is possible to highlight the importance of high-quality development with a sophisticated architecture using the first chapter of «Clean Architecture. A Craftsman's Guide to Software Structure and Design» by Uncle Bob.
Design and architecture — what is it?
Let's take my house as an example. Does this house have an architecture? Obviously! What parts does it consist of? Well... in general, it consists of shape of the building, appearance, setbacks, placement of rooms and spatial organization. Though looking more closely at the drawings of an architect, I saw plenty of details. I saw the whole lightning system — the placement of light switches and which lamps they control, I saw the placement of plugs, heating system, water heater and water pump. I also noticed the detailed explanation of walls, roof and basis construction.
Basically, these are the small details that provide the existence of high-level solutions. Low-level details and high-level solutions make the design of the house.
There is nothing different in software architecture. Low-level elements and high-level structure are parts of the whole. They create a basis for a shape of the system. One cannot exist without the other; there is no way to distinguish them. There is only set of solutions of different level.
Let's take a look at the research based on real cases of a company that prefers to stay anonymous. Examine the chart of dynamics in population of engineering group as the product grew. The tendency is definitely impressive; the increase of staff should be the sign of company success.
Now take a look at the chart of company productivity over the same period measured in lines of code in thousands.
Seems like there is something wrong with it. Even though every version of the product is maintained by bigger group of developers, the amount of code lines is getting closer to the limit.
And now here is quite a disappointing chart: the dynamics of price for every line of code over time.
This tendency is a signal of project non-viability. No matter how cost-effective is the company at the moment, the increase in spendings would overcome its income and would possibly lead to company's collapse.
What's the reason of such a significant change of the productivity? Why a line of code in the 8th version of product costs 40 times more expensive than a line of code in the first version?
The reason of troubles
The reason of these troubles are in front of you. When software is created at short notice and increase in staff is the only way to release new versions, when clean code and its design isn't a priority at all, there can be no doubt that this tendency will lead to the collapse of the product eventually.
The picture below illustrates this tendency in terms of developers productivity. At first they show around 100% effectiveness, though with every other version it decreases. As you can see, starting with the 4th version, the effectiveness decreases and almost reaches 0.
The developers are not guilty — they still do their best. Though they still can not produce more: they do not implement new functionality, they spend their time and resources on trying to clean up the mess of code. They just move that mess from one place to another in order to add some new little feature.
Management's point of view
If you describe this situation as the awful one, let's assess it from management's point of view. The line chart below describes the dynamics of monthly salaries budget over the same period.
When the first version was released, this budget was several hundred thousands. As for the second version, salaries budget had grew by more hundred thousands. By the release of the 8th version salaries budget had become 20 millions and kept increasing.
This chart not only looks awful, it is terrifying. Obviously there is something wrong. The only hope is that rise of income outrun the rise of spendings, but this line anyway is concerning.
Now compare the dynamics of monthly salaries budget and the dynamics of price for every line of code. In the first version they managed to implement a lot of functionality and it costed them several hundred thousands; in the last version they added basically nothing new and spent 20 millions. Looking at this trend, any manager would come to a conclusion that they need to do something to prevent a collapse. What went wrong? What can managers do besides releasing their anger on developers?
About 2600 years ago Aesop has created a fable named «The Tortoise and the Hare», which point can be stated differently:
- the slow and the consistent wins the race;
- it is not always the fastest to win the race and not always the strongest to win the fight;
- the more you hurry, the less you do.
The fable emphasizes the silliness of presumption. The Hare was so confident in his speed that didn't take the race seriously, decided to take a nap and skipped the moment when the Tortoise finished first.
Modern developers take part in the same race and show similar presumption. They do not sleep, of course, they even work a little too much sometimes, but some part of their brain seems to be asleep — the one that knows the value of a clean high-quality code.
Those developers believe in a lie: «We will clean this mess after the release!» Eventually this mess is never cleaned — the market creates competition, and the company now has to release more functionality to be ahead of all other companies.
That is why developers never switch. They can't go back and clean the code since they have to implement new functions one after another. The amount of bad code only grows, and the effectiveness of work decreases dramatically.
As the Hare was too confident in his speed, so are developers, thinking that their ability to stay productive isn't vulnerable. The moment they assume that they will be able to clean it later becomes the starting point of failure.
The biggest lie that developers believe in is that bad, but rapidly created code will help them release their product faster, though in reality it will just slow them down in the long term. The thing is that writing a bad code always make you slower compared to writing a good one.
Let's take a look at the picture below. These are the results of a 6 days experiment taken by Jason Gorman. Everyday he has written a simple program to convert integers into Roman numerals. The program was considered as complete when it successfully passed a couple of tests. Each day the task took a little less than 30 minutes. On the first, third, and fifth days he used a well known cleanliness discipline named test-driven development (TDD). On the other days, he wrote his program without it.
The results are listed on the graph above. Light blue indicates the days without TDD, the darker one — days with TDD. As we can see, work on the latter days is completed more quickly than the former days. Notice also that work on the TDD days proceeded approximately 10% faster than work on the non-TDD days, and that even the slowest TDD day was faster than the fastest non TDD day.
Some people would be surprised looking at this result. Though the ones who did not fall for the lie I described above would consider this result as an anticipated one, since they know a simple truth of software development:
«Festina lente» (make haste slowly)
This is also an answer for management's questions. The only way to turn around the decrease of effectiveness and increase of costs is to make developers stop thinking like the Hare and start to take responsibility for the messy code they created.
Developers might think that the problem can be solved only by starting again and rewriting all system, but this is their inner Hare speaking again. The same presumption, which has already lead them to a huge mess, is telling them to take the race of rewriting the code to get a better result. In reality it is not that simple:
Presumption, controlling the process of rewriting, will lead to the same mess as before
Any software development company should avoid presumptuous decisions and take the quality of product architecture as a priority from the very beginning.
translated by Ksenia Malykh