We coders are extremely proud of the quality of our work. We hold quality in great value, because well crafted product is an indicator of our craftsmanship and our capability to create something concrete and beautiful from scratch. But what do we really mean with quality in the context of software development?

High quality software does what it is supposed to

From customers viewpoint quality is almost always external, which means functional. High quality software does what it is supposed to do and perhaps even a bit more. Customer values software’s capability to provide the best possible customer experience as efficiently as possible. These external characteristics of quality can often be measured objectively, which makes it possible to set formal indicators for defining quality.

Another aspect of external quality is user experience. For example, how the user can achieve his or her goals with minimal effort. For service designers, this is one of the most interesting viewpoints to quality, but also highly valued by customer. We can measure user experience objectively to a certain degree with analytics, A/B tests, user tests and performance tests.

Beautiful code is economic code

We coders view quality often from internal viewpoint. High quality code is simple, unambiguous, readable, concise, testable and modular. Abstractions and responsibilities between components are carefully though out and justified. Code maps out the underlying business domain, actors and functions precisely. It also communicates with other services over well defined interfaces. There is no bubblegum, glue or anything else that doesn’t belong to the codebase.

Beautiful code is like poetry - with the exception that code communicates the message without any room for interpretation. The message is unambiguous. When the code is backed by an appropriate architecture we have something remarkable at our hands, which will touch emotionally even the rugged developer. We are in the crossroads of craftsmanship, art and engineering. This is the junction where innovations that change the behavior of individuals and organization are created.

How can we asses code quality?

The tricky part in internal quality is the fact that it is subjective - making it difficult to be measured. Best that we have found is a group of rules of thumb and good practices, which all need to be still interpreted on a case by case basis. It is easy to state that “You will recognize good code, when you see it”. It’s difficult to argue with that statement. I’m not saying, that we should rely on formal methods for measuring code’s internal quality. That doesn’t justify the needs. The question then is, how can we justify the importance of internal quality to our customers, if we can’t point out the existence or absence of quality with clear indicators?

Code quality has no value on its own, but rather it has to reflect into our capability to produce better software. The concrete value of high quality code can be easily demonstrated with a few examples. First, high quality code is effective to maintain, which in turn enables faster development making it easier to adapt into market needs. Second, hight quality code is productive from an operational viewpoint as well. We can fix possible bugs rapidly and adapt business logic swiftly almost without any risk. Third, it is a joy to work in a high quality codebase. I am much happier working with elegant code, when the spaghetti code is not in my way. Happy employees are the backbone of every successful organization.

Finding the right balance

We have found out that there is external and internal quality. Software which has an elegant codebase, but doesn’t meet the functional expectations can’t be perceived as a high quality product. Same applies vice versa. Even if the software would surpass the highest user expectations, we can’t consider it as hight quality if the internal structures of the code are chaotic.

Balancing between external and internal quality is always a decision which should be taken on a case by case basis. Far too often we end up overvaluing wither external or internal quality, and we can’t find the optimal balance considering the totality. It might be justified to take debt from internal quality, if that increases user experience dramatically and the need for change id urgent.

We should still keep in mind, that the debt taken from internal quality must be paid back some day or the burden of the debt will cripple our software’s capability to adapt to ever-changing requirements. And if we can say something for sure, it’s the fact that the world changes every single day.

This post was originally published in Finnish in LinkedIn Pulse. Photo credit for Zephyris in Wikipedia