Software Design Quality

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 over 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 organization. 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 are 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 and, 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 project cost.”      

Barry Boehm

The Good, the Bad, and the Ugly.

How can we define good design or bad design? It is hard to formalize 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 neighborhood. In an organized, 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 designs may take longer at the beginning, they but make future changes easier. On the other hand, bad designs may make you have a feature available sooner, but make future changes harder short-term, and 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, there are also common practices to guide us called design principles and design patterns such as SOLID, YAGNI (You aren’t going to need it), DRY(Don’t repeat yourself), and don’t repeat the effort. They create common solutions to common problems and create a good development atmosphere for all of us once they are 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, this doesn’t always indicate a problem.

What we don’t want to see in the code is the indicator of the weakness in design that may be slowing down the development of 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, and reusability. Some example pictures may help us to figure out how the design quality may affect maintenance cost. Maintenance costs can increase dramatically for some bad designs depending on whatever programming languages you use.

Relation Between Design Quality and 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, this also applies to software, the cost of a defect rises significantly the later in the process it is discovered.

For more info please visit the following:

• Website: https://www.codemr.co.uk/
• Twitter: @CodeMR_
• LinkedIn: https://www.linkedin.com/company/codemr