When to Focus on Speed, When to Focus on Quality

Published at 03 Jan 2020 by soywiz ( Sources: [1] )

As developers and as teams we often have to decide what to prioritize: Speed, quality or cost. You cannot have the good-cheap-fast: something well done, that is cheap to do, and that can be done fast.

Why is that? People with advanced knowledge that can do things quickly and with good quality is super hard to find, and thus expensive. And adding more people to parallelize the stuff, requires paying those salaries. And to coordinate that people effectively is even harder, so usually you require even more resources to achieve half of that.

You can also put several cheap monkeys pressing keys on a computer, but probably that won’t produce anything with a good quality.

So yeah, it is true: you have to choose.

Companies usually have a limited number of resources, so the costs have to be limited.

Let’s consider we have a team already, and a fixed amount of resources; that is a pretty common scenario. What should we do? Make things fast, or make things good?

Except for super consolidated companies, normal companies and specially start-ups are in a constant battle for living. There is a lot of competition, so they have to validate and build good products and services fast, and acquire and keep customers. They need to be fast, specially on the first stages.

For startups that are starting, it is better to go fast: Create an early MVP, validate the hypothesis and then iterate. At this point I would totally choose speed over quality. Know what? Even if the product is pure shit but works, it is always better that a high quality product that comes way too late when resources have been depleted and the company is dead.

Once startups have been validated, acquired a few costumers and maybe even got inversion, you can just throw away the MVP, or iterate the prototype with more people and resources.

For companies that are already out of the valley of death, there is a different scenario. You probably heard already about the Technical Debt. Technical debt is a concept that indicates problems in working code that makes it difficult to evolve, to update. The decisions about the design might force a big refactor or rewriting to include the required features. Of course if you kept things DRY and KISS (you can do this being fast), that will be easier to solve.

Here you have to invest a percentage of time and resources into improving the code and infrastructure (quality), and continue investing most of your time on the main goals of your company (fast).

It is a trade-off: But you shouldn’t invest all your resources into quality. You are still in a forest full of wolves. You have to continue progressing, your whole company should be focused on your company’s KPIs with a single vision as a whole, that’s the only way to be competent in this world.

For companies full of resources, that are dominating the world, they can invest in full teams of I+D focused on high-quality stuff. But even in that case, they are still companies: only focusing on the process, or on the team, instead of focusing on creating a product that is real and works is usually something that doesn’t work too long for periods of time. Don’t you think?

So my conclusion is that we should focus on quality when we can; we should make good things that work, but all that work must serve to a purpose, and we don’t have to loose the focus in the process. Let’s continue being competitive, let’s continue being fast.