Evolutionary quality

Evolutionary quality goals describe which software quality characteristics are relevant in which development phase of a product. A system goes through phases from genesis through individual production and product maturity to commodity. Functional suitability and reliability are important early on, followed by usability and performance, and finally maintainability, security, compatibility and portability.

Key Takeaways

• Software quality goals are not static: Which ISO 25000 quality characteristics are relevant depends on which evolutionary phase a software system is currently in.
• In the early experimental phase, functional suitability and reliability are crucial because a system has to prove that it works before investors or first customers get on board.
• Maintainability only becomes critical when rapid growth requires the onboarding of new developers and feature requests must be delivered in an acceptable time.
• Managing directors, users and developers systematically prioritize software quality differently: usability is at the top for users, maintainability at the top for developers and at the bottom for users.
• Those who promote technical quality issues such as maintainability internally need different arguments than for user-side qualities: Metrics on development speed or concrete onboarding costs are convincing where abstract quality terms fail.

What are evolutionary quality goals?

Evolutionary quality goals mean that the important quality characteristics of software shift over its maturity. What matters at the beginning of a system is not the same as what matters when the system is successful on the market.

The model is based on an observation from software architecture consulting: companies often want too much at once. Start-ups don’t see why they should suddenly worry about quality, after all, there is a running product. Existing software, on the other hand, carries technical debt and nobody knows where to start.

Markus Harrer assigns software qualities to the various phases of a system. This is based on the Wardley mapping technique developed by consultant Simon Wardley, a method for strategic, evolving maps of software systems. One of its axes is the evolution axis, and it is precisely on this axis that the topic of quality can be mapped.

The evolution axis describes four phases of a system

Software moves through four phases over its lifetime, which are related to the interplay of supply and demand.

In the Genesis phase there is only an idea. You don’t know whether there will be demand for the product or whether it is technically feasible. Using the example of a travel expense report: you have no idea whether you can systematically record receipts and whether anyone needs it at all.

In the individual production you build a first prototype or a minimal viable product. You record prices in an Excel spreadsheet, for example, and see that it works for you. It remains to be seen whether the market wants it.

In the product phase, it becomes clear that there is a broad demand. You build real software with a database behind it because the effort is now worthwhile. Finally, in the commodity phase, the system becomes a common good, for example as a cloud service that supplies a mass market.

The driver behind this turns: initially, the supply side is unclear, you have to prove that the thing can be produced at all. Later, demand picks up and new customers arrive with new requirements.

Which qualities count in which phase

Each phase focuses on different characteristics of ISO 25010. The standard provides a clarified vocabulary that can be used to talk about quality in a more informed way instead of everyone inventing their own terms.

The following classification summarizes which of the eight quality characteristics are added in which phase:

In the genesis phase, functional suitability is what counts most. You have to prove that your approach works. In addition, there is reliability, because the software must not break at the next click in front of funders.

Usability spills over into the customization phase because suddenly different end users with different levels of training need to be served. With the new users, performance also becomes an issue, because a responsive application is in demand.

Maintainability comes into play in the product phase. If the system is successful, you will need more developers to process feature requests in an acceptable amount of time. Modularity and analyzability determine how quickly you can onboard new people and let teams work independently. More demanding customers also require deletion concepts, commissioned data processing and single sign-on, which adds security.

Compatibility and portability remain in the commodity phase. You want to operate your system on replaceable cloud infrastructure and offer interfaces for other services, for example so that analysis tools can access your travel expense data.

The model relieves instead of just demanding

The practical value lies in the fact that you can deliberately leave qualities out. Not every theme has to be perfect from the start.

A startup that has no time for maintainability is often right in the genesis phase. Markus reports on his own startup with the aim of implementing clean code from the outset. The team was able to replace the persistence mechanism within one or two days and did so five times. It didn’t make sense, but it shows how easy it is to exaggerate portability while leaving function and usability behind.

The model therefore helps with two questions: Are you focusing on the right things? And which decisions can be postponed without taking a risk?

Why maintainability is so difficult to communicate to the business

Quality becomes more difficult to sell the deeper it is embedded in the technology. This explains a second axis of the model, the value chain.

It ranks components according to how close they are to the user. At the top is what the user comes into direct contact with, such as the website. Below that are the customer information system, operating platform and infrastructure. A user notices when photo printing is stuck. They never notice whether the system is running on a Kubernetes cluster.

The same applies to qualities. Functional suitability and usability are at the top, close to the user, easily accessible for product owners and management. Maintainability, security and encryption procedures are at the bottom, far away from the day-to-day business of the stakeholders.

It is precisely at maintainability that the argumentation tips over. Until then, business and development talk about the same, visible things. From maintainability onwards, quality becomes ominous for the business, and the familiar conflict breaks out.

We have to make it more maintainable. Yes, what does that mean? I don’t know, why should I do that to myself? Can’t we make it faster? I can relate to that better.

Markus Harrer

Different roles pursue different quality objectives

In software audit training courses, participants from three roles argue which qualities are most important. The evaluation of the assessments shows clear patterns.

• Users prioritize usability.
• Management prioritizes functional suitability, i.e. that what is promised is kept. Security is moving to the top since liability issues have become more visible.
• Developers prioritize maintainability, which is at the bottom of the list for the other roles.

If you combine the views of management and users, usability is at the top and maintainability at the bottom. This results in the team talking past each other. If you create awareness of this distribution, you can resolve the conflict earlier by writing down the goals and making them validatable. Non-goals also help to sharpen the focus.

How to promote internal qualities as a development team

If the business does not address internal qualities, you need different methods than for user-oriented features. A direct appeal to maintainability rarely works.

Establish a community of practice in your own company, such as a software craft community, which focuses on maintainability in your specific context. This way you keep the topic visible and create publicity for its importance, coupled with a real cause such as “We want to onboard 50 new people”.

Tie internal quality to business needs rather than technology. “We use Kubernetes” is too far away. “We want to intercept dynamic loads on Black Friday” is relatable. The intermediate point between deep technology and business benefits is the stepping stone that the business uses to get there.

Use suitable tools depending on the quality. DORA metrics are suitable for maintainability, such as the lead time from idea to roll-out, to make it clear that feature development is taking too long. For security, work with risks and fear scenarios that dock with the product managers.

Best practices from other companies provide shortcuts, but are only useful if they fit your context. The architect role here means becoming more creative and drawing more connections to the business.

Quality goals are never finished

Quality objectives remain in motion because the system remains in motion. New customer groups, increasing demand and an active system are good signs, but they constantly shift priorities.

The mistake is to tick off the top 5 goals from the beginning as done. Maintainability, security and portability become more important over time than they were at the start. So you have to keep re-ranking the list, depending on where the system currently stands on the evolution and value creation axis.

Captured ideas do not have to be lost. Put them on the back-up bench or roadmap and revisit them when the time is right. This way, you take teams with you without getting bogged down.