Why quality is important

Everybody knows that software quality is essential, but when I ask why, many developers struggle to explain. In this article, I will describe three primary reasons why we should care about quality and strive for technical excellence.

Quality is mastery.

The crucial need of any developer is the desire to improve, also known as Mastery. Developers enjoy doing things “the right way” and stand to their quality standards.

To attract good developers, you should aspire to create a culture of technical excellence, where quality is not negotiable.

According to HackerRank, when developers decide which job offer to accept, the main criteria is professional growth and learning. This result applies to both juniors and senior developers:

Mastery beats business domain, company prestige, and even compensation. I was always choosing a company where I can learn from masters and enjoy working on a well-crafted codebase.

By allowing developers to grow professionally, learn from masters, and work to the highest quality standards, you attract the best people. The results won’t keep you waiting. Your people will spread a word and bring more like-minded professionals.

A players hire A players.

On the contrary, by compromising on software quality, you reduce workforce quality. Working on shitty codebase is torture. Cutting corners under pressure is a shame. Continuous degradation is professional suicide. No sound person wants to suffer, so eventually, you won’t be able to hire any good programmer.

Paying big salary will make things worse – you will attract developers who will do whatever you say, not what needs to be done. B players hire C players. C players hire D players. It doesn’t take long to get Z players. That’s how the culture of mediocrity emerges.

To attract new developers and keep your best people, make quality the top priority.

Quality is speed.

There is no conflict between quality and speed. Quality enables speed. No developer has ever said – “this shitty codebase makes me sooo fast!”. Every good developer knows that working on a good codebase makes us faster because we spend most of the time reading someone else’s code. Some experts claim that the ratio of time spent reading versus writing is well over 10 to 1. Because clean code makes reading easier, writing clean code is a reasonable investment. Making the code easy to read makes it easier to write. Pure profit!

But there’s a nuance here.

We invest time in quality because we want to prevent the situation when bad stuff accumulates over time makes development slow and unpredictable:

But what if we’re building a disposable prototype or a Fake Door Experiment?

In this case, bad stuff doesn’t accumulate, because we’ll throw the code into the trash bin. Following rigid engineering standards might not be the best idea. There is no point in building the thing right before you know what the right thing is. Hack it, ship it, delete it.

Once you’ve validated your idea and want to build a sustainable, long-term business, you better build it right. Now you’re running a marathon, not a sprint. Remember – the only way to go fast, in the long run, is to go well.

Quality is hard.

To be fast in a long-run, we need to pay attention to quality. But slowing down in the sake of a long-term gain is costly. The only solution is to learn skills that allow us to produce quality results fast.

For example, test-driven development (TDD) leads to better quality. But to work fast in TDD style, you need years of practice. You can’t master TDD by completing a set of Fibonacci code katas. Production code is different from code katas – it’s non-trivial, sometimes messy, partially written by that fired guy who likes static methods. When you start applying TDD on production codebase, your productivity declines. Under pressure, it becomes tempting to restore productivity by ditching TDD, because TDD learning slows you down:

We forget that nothing great comes without sacrifice and stop in the middle of hard, never reaching the next level of mastery. But there is no fast-track to mastery. The only way to mastery is sacrifice, discipline, and years of practice. Quality is hard.

Quality is reputation.

Quality of your work shows how much you care about your teammates and people who will work on the codebase after you leave the project. You are what you do, not what you say you do. If you want others to treat you as a professional, behave accordingly. That is, do quality work.

If you work in a team, you should care about your teammates. If someone is spending extra hours at work away from their family, trying to understand your shit, while you are on vacation, you’re not a good teammate. If you expect victims of your crimes recommend you in their circles – forget about it.

Your reputation precedes you. If someone caught you cutting corners, you immediately become a person of low standards. That’s how people will see you. Sloppy work becomes part of your brand. To build a spotless reputation, you have to produce quality work for years. To ruin your reputation, deliver sloppy work once. It’s a one-way street.

Your brand is what other people say about you when you’re not in the room.

Draw the line that no one can cross. Everything is flexible – project scope, time, money, but not quality. No matter what others are doing, always do your best work. You are what you do. It’s better to lose a job than your reputation. Don’t negotiate quality. Be the person of quality.

• 🥇 Quality is mastery.
• 🚀 Quality is speed.
• 🏋️‍♂️ Quality is hard.
• 👍 Quality is reputation.