Software Success: Balancing Architecture and Behavior
“Your software’s behaviour can win clients today — but only its architecture will keep it alive tomorrow.”
What are the two important things a software is expected to do?
Well, everyone knows the first one — behaviour — meaning it should behave according to requirements. Easy-pissy.
But what is the other important thing? Software architecture — meaning how components of the software are arranged.
But is it really important?
What if I tell you it has the same value as behaviour, or maybe more, but not less for sure?
In this article, my sole purpose is to make you understand the value of architecture in such a way that your hands will get stuck on the keyboard if you do not care about architecture while building software.
1. Behaviour
You, your client, your manager, your development team — all of these understand what behaviour is because this is the thing you will present to the client or users.
You first develop the requirement document and then code the software so that it behaves according to that document. All the upcoming features and bugs are part of the behaviour of the software.
2. Architecture
It is how our software is arranged. Sometimes, managers don’t even know what it is, and a manager will prioritise it lower (if not a good manager) until he comes up with actual data — yes, data — which will reveal how much loss the company is making because of poor architecture.
The Data That Proves It
This shows the number of employees in 8 versions of a software:
And this is the productivity per release of the software:
It kept decreasing, and at a point, it will become 0.
Zero productivity — man, just think — it means you will not be able to change the software according to future requirements. Then what’s the purpose of the software anymore?
Okay, first you might think that it is impossible that we can’t change the software anymore, right?
But if its cost is so high that it makes you losses, then you don’t change it. This is what I mean by zero productivity.
Why It Happens
So why did it happen even with the increasing number of people per release?
Well, if the architecture of the software is so bad, then when you have to change something in it, you don’t understand where to start and how many files to change.
It becomes riskier, harder, and takes more time, which costs more to the company.
But with good architecture, even an intern can add a new functionality because he doesn’t have to focus on the coding hell — only on meeting the requirements.
A Great Experiment by Jason Gorman
This will make most people believe everything written here. Jason conducted this test over a period of six days.
Each day, he completed a simple program to convert integers into Roman numerals. He knew his work was complete when his predefined set of acceptance tests passed.
Each day, the task took a little less than 30 minutes.
Jason used a well-known cleanliness discipline named Test-Driven Development (TDD) on the first, third, and fifth days.
On the other three days, he wrote the code without that discipline.
And here are the results:
You can clearly see that when done with good architecture practices, the work is completed way faster.
And this is the data we have to rely on — not our intuitive decisions.
Final Thoughts
We all think we have to finish the behaviour and can focus on architecture later — but no, there is no time for us to do it later.
With each bad architecture, software becomes less flexible to change and performance decreases.
The conclusion of this article is that architecture has the same or more value than the behaviour of the software.
If we want to make software live longer, then a good architecture should be chosen, and we must be consistent with it.
But behaviour is also an important aspect, as we all know, so choosing a good balance and setting priorities is important.
That’s it for this article. I will keep showing up with future articles about Clean Architecture as well as other important engineering concepts like system design, databases, and problem solving — the real things that are needed.
Top comments (0)