Can we postpone quality?

Can we postpone quality?

The speed of change is increasing, the demand for change is also increasing. Knowing that quality is multidimensional, and that time is also part of those dimensions, we need to handle quality matters wisely, by being prepared as much as we can. The decisions we take today, or that we don't take, will affect quality. Teams continuously face challenges; some may be more aware of this than others.

The performance challenge

Let's look at a real life example, based on feedback collected from some teams I've worked with. As mentioned in a previous article, some time ago, we did an assessment with several teams. One of our goals was to understand how these teams were approaching testing.

From all the conversations we had, we could realize several things (I'll just enumerate a few):

• having a product "without bugs" was a concern
• performance was also a concern, with different levels of importance, in some teams

Let's focus on the performance concern as I think it can be used as a reference.

Depending on the nature of the product, how it is deployed and maintained, how it used, and how often, performance as a quality criterium can become more or less relevant.

The "we have already dealt with it" team

One of the teams had struglled with performance many times in the past. Once in a while, a performance issue would popup. There were several reasons for it (internal and external), and some of them were actually kinda of good ones - usage in more high-demanding scenarios, with thousands of concurrent users and with unthought usage scenarios. I remember the team addressed each performance issue, one by one like in a firefighting mode. Performance wasn't being tracked consistently; there were some ad hoc prrocess to measure some aspects of performance, but a dedicated performance environment, where performance could be tracked continuously only came later on.

Whenever the team decided to tackle performance, not just by reworking some core aspects of the product but also by implementing a whole performance approach with a dedicated environment, gains started to arise and performance issues became very rare. Confidence increased a lot but we know that pursuing quality is a neverending story.

The "data" team

This very small team focused on processing data was currently in firefighting mode. A dedicated performance environment is missing and so are continuous measurements on performance. The team is overloaded trying to address performance issues as these keep coming, as the product is being used in numerous and uncontrolled ways. This in fact needs some thoughts: of course we need to measure performance upon changes in the product but we also need to have come clarifications about product usage. A clear commitment (spec if you want), about the minimals the product shall handle was missing. And more than that: there were no ways of controlling/limiting the source data which could ultimately affect that specific product usage but also the overall product related infrastructure.

"Not worried at all" kind of teams

Several teams were in this category. They hadn't faced any significant performance challenges so far, therefore they were not worried; performance was not a concern on their daily activities.

Meet the "Quality Mountains" model

Even though what contributes to quality (i.e. quality criteria) changes with time, teams will face some common challenges. Sometimes it may be performance, other times it's security, other times it's something else. We need to be prepared to handle those challenges by not just shifting left, but also by embedding that as a concern in our day to day activities.

Performance, for example, is an issue that sooner or later will come to almost every single team. The later it comes, the harder will be eventually to address it as it may require rebuilding the architecture of the application, for example. Don't expect easy fixes, like changing some flags in the compiler or in the JVM; those are possible but most times they are just workarounds, which don't solve performance problems that are due to the way the solution was built.

I realized that similar challenges will come to teams at different times, with different intensity and different relevance. Not all teams will have the same kind of challenges but we can see similar challenge patterns across teams, such as performance, security, accessibility, among other.

Therefore, I came with the "Quality Mountains" model, which I tried to sketch in a very rough way :-)

Each mountain represents a quality challenge. There are mountains of different types (here annotated with distinct letters), representing different quality aspects you have to address. No mountain is the same, even whenever they are of the same type. Mountains exist ahead of us, even if we don't see them coming. Sometimes we may already be climbing one these mountains and drowned dealing with all the technical and non-technical aspects we have to overcome.

The sooner we prepare to climb them, the smooth our trip ahead of us will be. Sometimes we may use some telescope, or send some probes, to see what's coming ahead (up to a point).

Our overall software development & maintenance trip is not flat; flatiness is an illusion.

Wrapping up

For some teams, a given challenge, such as performance, may be more or less relevant in the context of their product and its usage scenarios. That's fine. However, we need to realize that we're in a road, at full speed ahead and challenges will come, no matter what.

So, we cannot postpone handling quality because quality challenges, no matter if we're talking about performance, security, or other, they will come at fast speed. Are we prepared to handle them somehow? Can we do something about it? Can we start perhaps embedding performance/security/and other quality related practices to diminish risk, its probability and its impact?

What about taking some time to reflect within the team about those risks we're ignoring or not properly handling right now? Then define some countermeasures, such as deepen knowledge in certain areas, so our (individual and team) skills are improved and we can tackle the problem with thoughful actions.

Remember that challenges ("quality mountains") will come, even if you don't see them ahead. Are you and your team already preparing for them?