Back to Home
You know it does not take a huge amount of skill and knowledge to write code and make it work. Yeah, that’s right. Nowadays, a kid from high school can do it. Though the code they write might not be pretty, it damn works 💯! BUT getting software right is much harder than making code right. Because it requires some high-level knowledge and skills that most kids and young programmers don’t have. That's the thing that makes the difference between a senior and a junior developer. I will give you a glimpse of the Importance of knowledge that is required to get Software right from the perspective of Design and Architecture.
Note: In this article the word developer is used interchangeably with programmer.
There has been a lot of confusion about design and architecture over the years. Some people think they are same, and some people don't think so. For beginners, I would say don’t think much over them. Assume that they are same in Software Development. No difference at all. Usually, the word “architecture” is used for some high-level context whereas “design” more often seems to imply structures and decisions at a lower level. Believe me, when you know what a real architect does, you would not find any difference between them.
For example, I have the architectural design of my home currently in my hand. I see high-level things like the shape of the whole house, the outward appearance, the layout of the spaces and rooms. When I look through the diagrams, I see the lower-level details as well like where will be the lights and switches and which switches will control which lights. So, I get the idea of how low-level details support all the high-level decisions to become fulfilled. They together define the whole shape of the system. Indeed, no clear line divides them.
Every software provides two values to the stakeholders.
We, the developer make machines behave in a way that makes money for the stakeholders. We write code that aligns with the machines and meets the software requirements.
Do you know what “software” means? It has two parts “soft” and “ware”. “ware” means product. And we know what “soft” means. So the thing is “software” must be “soft”. That means the software should be the product where changes can be easily made for the behavior of machines. If it's hard to change, we will call it “hardware”.
We know that changes from the stakeholders are always welcome 😃. So when the stakeholders change their minds about a feature, that change should be simple and easy to make.
The difficulty for making such changes should be related to the scope of the change and not to the shape of the change. The costs grow out of proportion to the size of the requested changes. Thats’ why in most of the development cases,
the cost of 1st year < the cost of 2nd year < the cost of 3rd year < ..
From the stakeholders’ perspective, they are just giving some new changes of mostly similar cases. From the developers’ point of view, the stakeholders are giving them a couple of jigsaw puzzles.
Each new request might seem harder than the last. Because the current shape does not match with the new shape request. And, do you know the reason behinds that? If your answer is the vulnerable Architecture, then you are right.
So, at this moment you have a rough idea about the two values. But which one has great importance?
Is it more important for the system to work or is it more important for the software system to be easy to change?
From the managers’ point of view, they would say it’s more important for the software system to work. In some cases, Developers would agree with that thought. But it is wrong.
Let's go through two cases below:
But you may not agree with me when I say no new changes are possible to fit. I did not say that only considering the coding part. Sometimes, you want to change, but the time 🕔➵ Architecture and budget💲do not allow you to do so. This is one of the major causes while the developers are not capable of doing any update to the architectural design, though the design requires to be upgraded.
So, architecture should be well defined before jumping into the coding. Architecture could not be 100% percent well-defined, but it should be at least at some point that will welcome new changes warmly ✔️.
Actually, the problem is finding out when — which value (behavior and architecture) is important or which value is urgent.
We can apply a solution to overcome the problem I mentioned above. We should have a focus either on the first value of Software — Behavior or on the second value of Software — Architecture.
And the solution is Eisenhower matrix. Some people know it as Priority Matrix.
For our case, we can say,
behavior: is urgent but not always particularly important.
architecture: is important but never particularly urgent.
In most cases, people fail to separate those features that are urgent but not important from those features that are truly are urgent and important. This failure often leads to ignoring important features like architecture in favor of the unimportant features of the system.
But the managers may not be able to evaluate the importance of architecture. And I will not blame them for that. They are right at their places✌️️. But it is the responsibility of the software developers to assert the importance of architecture over the urgency of features.
If architecture gets less importance than other tasks of the task list, then the system will become in a state where new changes particularly impossible to do considering time, budget, and codebase. So MUST think about architecture before coding.
You are welcome to read other articles of mine here.