There are mainly three important characteristics of good software. It should be readable, extendable, and maintainable. I am sure every reader of this article would like to add another important characteristic to this list.
First of all, the code that we develop is a long-lasting, “living entity”. Once it is created, it evolves by time. In every part of its life cycle, the code is read by many developers many times. Especially, if you are developing open-source software or developing software in a big organisation. Therefore, it should be easily understandable by the other developers as well.
“Any code of your own that you haven’t looked at for six or more months might as well have been written by someone else.” Eagleson’s Law
According to studies, developers spend 80% of development time reading the code! So code is read much more often than it is written,
Code changes, due to several reasons like bug fixing, upgrading the tech stack, and enhancements. Most companies have to spend up to 80% of the development budget for maintaining the code.
The design is good if we want to change it, we don’t have to spend too much time and effort. And also, we should extend it without fear. A good design should be adaptable to the changes, and the cost of the change should be as minimum as possible. Otherwise, adding new features costs more and more! if the code is maintainable and extendable, you can modify it without fear, and adding new features does not cost too much.
“Maintenance typically claims 40–80% of all projects cost” Barry Boehm
The Good, the Bad, and the Ugly!!!
How can we define good design or bad design? It is hard to formalise what good design is but we all somehow can feel when we see a good design or a bad design. It is one of the things that make software both an art and a science.
Let’s talk about the difference between good and bad design with a city analogy. When you visit a city you walk around to discover the neighbourhood. In an organised, clean, and well-maintained one you enjoy and feel the atmosphere. It is the total opposite in a city like in the second picture. These are also valid for software design. To achieve a good design we should thoroughly think about our design.
Good design may take longer at the beginning but make future changes easier. On the other hand, bad design can make you have a feature sooner, but make future changes harder short term long term.
Of course, the reason for a failed project is not only poor quality. Another fact about quality is the cost of design and the cost of fixing design defects. Studies show that only 10% to 15% of the total cost is designed itself. On the other hand, fixing design defects can cost up to eighty percent of total development.
Like in city architectures in the software also There are common practices to guide us, they are called design principles and design patterns, like SOLID, YAGNI (You aren’t gonna need it), DRY(Don’t repeat yourself), don’t repeat the effort. They create common solutions to common problems, and create a good development atmosphere for all of us, once they applied correctly.
On the other hand, there are also some anti-patterns, often called “code smells’’ or “bad smells”. They are disharmonies and anti-patterns in computer programming code, referring to any symptom in the source code of a program that may contain an area of concern. They can be used as an indication of a weakness in the design. A code smell is a surface indication that usually corresponds to a deeper problem in the system. More specifically, a code smell has to be sniffable, something that’s quick to spot. However, they don’t always indicate a problem.
What we don’t want to see in the code the indicator of the weakness in design that may be slowing down development or increasing the risk.
“A code smell is a surface indication that usually corresponds to a deeper problem in the system”. Martin Fowler
We can imagine external and internal attributes as an iceberg. Users see external attributes like functionality performance reliability but those are some kind of reflection of internal attributes like coupling, cohesion complexity, reusability Some example pictures may help us to figure out how to design quality that may affect maintenance cost. Maintenance cost can increase dramatically for some bad designs. Whatever programming languages you use.
Relation Between Design Quality & Change Cost
Technical debt (also known as design debt or code debt) is a concept in software development that reflects the implied cost of additional rework caused by choosing an easy solution now instead of using a better approach that would take longer. Ward Cunningham explains Technical Debt with a financial analogy, like financial debt, the technical debt incurs in payment. It is acceptable and manageable until some level if you can control it while maintaining the project schedule and budget. However, “prevention is better than cure”, just like for health, also for software, the cost of a defect rises significantly the later in the process it is discovered.
For more info please visit:
- Website: https://www.codemr.co.uk/
- Twitter: @CodeMR_
- LinkedIn: https://www.linkedin.com/company/codemr
