Quality vs user satisfaction

Software crafters care a lot about the quality of their work, but business realities are generally much more important.

As a software crafter, you'll often be faced with the following conundrum: how to deliver the best possible quality results, hence satisfying the crafter in you, while pleasing end users, who usually want high-quality results yesterday?

Let's explore this subject together. This content is part of the first volume of my Dev Concepts series of books.

Tradeoffs and responsibilities

It's always a question of balance. Software crafters should generally strive for better quality but, always have to make tradeoffs. Satisfying user needs and respecting hard deadlines always has priority, but it doesn't mean that you should always give up on quality.

As a professional, you should dare to question business choices and deadlines. You should also provide information and bring clarity. Your customers deserve to know about their options, the tradeoffs involved and need to be guided towards better choices. Moreover, quality is also closely related to user satisfaction, even if it isn't always obvious.

Software quality facets

Software quality is composed of both external and internal elements. External quality is usually much more tangible for end users. For instance, users of a system only see the user interface and its behavior. If the quality of the user interface deteriorates, then it'll be discovered rather quickly. Internal quality has more to do with the robustness of the system and its reliability.

If you cut corners on the internal quality, then it will also impact end users, but in different and seemingly less obvious ways. They'll receive incorrect results, or calculations will take much longer than they should, etc. The system might crash unexpectedly, and the defect rate might increase drastically. It might also take longer and longer to deliver new features over time, as more and more time is spent fixing bugs and putting out fires. Most importantly, quick and dirty can sometimes have dramatic consequences (e.g., reputation & financial) on businesses.

High expectations

Interestingly, our expectations towards IT systems are heavily influenced by the applications we use on a daily basis in our lives (e.g., Gmail, Office 365, etc). This translates into high expectations from customers, who don't understand (or care for that matter!) about the complexity of achieving the same results as the biggest organizations in the world. Chances are that you are not working for Google, Microsoft, Facebook, Amazon, Apple, and the like. This means that you will have limited resources at your disposal, varying skill sets, and obviously tradeoffs to make. Make sure to inform customers about the complexity of their requests, and bring them "back down to earth".

The constant tension between quality and cost

We are all used to the quality vs cost relationship. Often in real life, if we pay less, then we get tend to get lower quality, and vice versa. This is not necessarily true with software. There are always shades of gray. Let's consider a few more dimensions to better understand the possible solutions:

As shown on this wonderful "flower diagram" (yes, just made that up), there are a few closely related concepts:

• Scope: We can decide to develop fewer features, or to simplify the ones on the roadmap of the project
• Time: We can change the timeline to be able to reach the required quality level while delivering the expected features
• Quality: We can decide to make quality trade-offs and thus reduce the (immediate) costs while keeping the initial timeline
• Risks: We can accept taking more risks

Whichever approach you pick, all the dimensions will be impacted. For example, reducing the available time by 10 while keeping the same scope will most probably have a catastrophic impact on quality (and project risks). Reducing quality will increase risks, time to completion and thus overall costs, etc.

Clear and timely communication is critical for success. Before deciding to lower internal or external quality to meet deadlines, make sure to understand the possible tradeoffs, and to explain those to stakeholders so that conscious decisions can be taken by the business. A Strengths Weaknesses Opportunities Threats (SWOT) analysis can be useful for this.

NOTE: As a software crafter, you should also "fight" when needed so that quality is taken into consideration and is part of the project planning, just like other considerations. For instance, if there are code improvements/cleanups to take care of, then you should justify and defend those. Never remain silent about quality and security risks.

One way to help end users to realize that quality is not perfect yet is to make the user interface less polished. The idea is that if you deliver a top-notch user interface, then users will feel like they've received complete & high-quality software, independently of what's under the hood.

References

• SWOT analysis
• Tradable quality hypothesis by Martin Fowler
• Principles of Quality Costs, Implementation, and Use by Jack Campanella

Conclusion

In this article, I've quickly explored the different tradeoffs around software quality and user satisfaction. It's a tough debate because reality is complex, and each situation is specific. My main point is that you shouldn't always just cut corners and lower the quality of your work just to meet deadlines. Sometimes it's better to stand up, analyze the pros and cons, the risks involved, and help your customers make decisions that they won't regret later on.

What is your opinion about this topic? How do you deal with pressure to deliver and the tension it creates?

That’s it for today!

About Sébastien