Should You Invest in Software Quality or Speed? | by Luiz Scheidegger | Nov, 2022

both, but on different occasions

photo by Ditch Feather unsplash

We get paid to make products, so nothing is more natural than investing our time to make more and more products. However, releasing these products comes with direct and indirect costs such as maintenance, support and complexity costs.

In this article, I’ll explain in three parts whether your company should invest in quality or speed.

“The new feature is going to be killer, isn’t it?”

“Yes, conversions and retention will increase!”

“The world will be better off when this feature is gone!”

“Let’s do it live, don’t worry about technical debt. After release, we can fix it!”

“What about testing, alerting, logging, tracing, monitoring and resilience? ,

“We can do all this later. Fast time to market is important.

If I earned a cent for every time an engineer heard a sentence like that, I’d be a billionaire.

IMHO, a big misconception is assuming that our measure of success is the number of features released rather than their impact. It’s hard to admit, but customers usually aren’t fast asleep waiting for your next feature release.

Let’s say you already have a customer base using your products that is satisfied with the current features. In that case, retaining your customers with a reliable product is more important than bulking it up with features at the expense of its stability.

Companies do not earn money from the products they are developing but from the products they are operating.

As I said about it in this other blog importance of teamsEvery feature you release increases support and maintenance efforts as long as the feature is in production. If issues are live in this feature, it will consume your potential from responsible teams, first-level support and stakeholders, i.e. sales.

Rest of the images by authors

The graphic above shows how some capacity for maintenance/support will be compromised after product development, slowing down the development of the following products.

The volatility will consume the support bandwidth even more, thus reducing the team’s ability to develop more valuable features.

In other words, the better the quality of production, the less you have to invest in support and maintenance, and the more productive your teams are. But after a turning point, it’s not worth investing much in quality. Overengineering is just a fancy type of waste.

Products have a core that is the solution to a need. For example, Airbnb acts as an intermediary between people renting a room and people looking for a place to spend a few days.

To make room renting more reliable, fun and profitable, Airbnb built in features like map search, host ratings, and more.

These features are helpful and provide value. They are overused and have become part of the core of Airbnb.

As you can read in Eric Ries’s classic book “The Lean Startup” (or in blog), we have to experiment a lot to find the right features for our customers and not rely on our intuition to release feature after feature.

We must have at least two ways of working: a) how we work with our core, and b) how to discover the following products or features.

While working with our core, we should not accept any compromise. This core should have the required quality in all relevant aspects:

  • Usability and Design
  • performance
  • Stability
  • Reliability
  • maintenance
  • test ability
  • resilience
  • integrity
  • Security

Your core should have a zero-bug policy and mean time to fix in minutes. The responsible team gets alerted to any problems and starts working on them immediately.

Initially, teams will do a lot to put out the fire, but they will learn and use patterns and tools to help them, such as the following

  • release automation
  • test automation
  • Monitoring, Logging, Tracing and Alerting
  • chaos engineering
  • SAST (Static Application Security Testing) and DAST (Dynamic Application Security Testing)
  • on-call duties
  • runbook

It is also necessary to invest in state-of-the-art architecture and good and practical code quality.

All these aspects will improve the quality of your product in operation, thus reducing the cognitive load of supporting it and avoiding context switches in your teams.

After a while, your core becomes a reliable platform. On top of this, you can create new products and features efficiently and hopefully effectively.

Discovery of new products and features should be as fast and affordable as possible, iterating rapidly and discarding 100% of what has been tested, even if successful. The goal is not to create something “production ready” but to validate the problem and its solution.

Separating what you’re validating and what you want at your core is important because developers feel attached to everything they build and have trouble letting go of any work, even That failure too.

If the idea turns out to be valid, and you decide it’s worth building it, you can do it with whatever qualities you have for the current platform.

There are many tools, frameworks and practices to make validating ideas as simply as possible:

  • design sprint
  • rapid prototyping
  • canary release
  • A/B Testing

Everything you validate should be discarded without leaving any residue in your platform.

The idea is to only operate products that undoubtedly provide value for your customers.

Build a flexible technology platform approach to reduce the cognitive load of your teams.

Validate ideas as cheap and straightforward as possible, and if they are a truly adequate solution to a relevant problem, build them into production keeping their excellence in mind.

Leave a Reply