Apply Standards Consistently

In Surely You’re Joking, Mr. Feynman!, which, by the way, is a wonderful read, Richard Feynman explains how the famous gambler Nick the Greek was able to win at casinos. Knowing that casino odds are always in the house’s favor, Nick would instead make side bets with other players.

It’s good life advice to avoid games that you know are rigged against you. Yet you see people bet against software quality–and, of course, lose. Here are a couple of reasons why people may relax quality standards.

Low Business Value Implies Low Software Quality

I’ve definitely seen this in more than one organization. It has to do with a fundamental misunderstanding of how software works and so I think this mistake is probably ubiquitous.

Very often the product requests of business stakeholders are experiments. They are asking for that new feature because they want to test its value in the market, not because they are certain of its value. And sometimes these experiments show that there is not enough value in that new feature and it gets deprecated or changed. This is the natural, iterative, exploratory nature of building a business around a software product.

So when a business stakeholder is talking to a developer, they may emphasize the potential ephemerality of this feature and so imply–or explicitly request–that for expediency’s sake all of the quality-related effort be skipped as this feature could end up getting scrapped later.

Now, it makes sense to negotiate many non-functional requirements with business stakeholders, since non-functional requirements are ultimately driven by business needs. But when it comes to software quality, which I’ve previously defined as software’s resilience to change, the standards must be uniform across the entire code base. That’s because in well-written software there is a great deal of code reuse and so the code that powers different features are deeply interconnected. And this is the fundamental misunderstanding of how software works that I mentioned previously. It seems that some business stakeholders have a mental model that code for different features are as siloed and separate as they appear in the UI.

False Emergencies

Urgency is different than emergency.

Urgency is different than emergency.

If you’ve got an immediate problem that is an existential threat to the business, then yes, ship a solution as fast as you can and worry about testing and craftsmanship later. But if you are dealing with negative business consequences that do not threaten the fundamental health of the business, then this is not a true emergency and all of the usual engineering standards should stay in place. It’s basically the difference between running a red light because you are an ambulance or running a red light because you are about to miss your flight. One is an emergency; the other is merely urgent.

It’s generally the case that you will always have a steady supply of business requests and they will always have some sense of urgency to them. So it’s the quality standards that happen in the face of urgency that really define the quality culture of an organization.

Before Getting Product-Market Fit

This is the only circumstance that I can think of where you can bet against code quality and win. First, your business is in its infancy and you have not yet found product-market fit. This means that, chances are, the current incarnation of your product will not be the final, revenue-generating one. You will end up pivoting or even scrapping the product to replace it with a different one.

Perhaps for lack of capital, you may not have been able to hire a developer that already has a lot of good development practices. In this situation, it may not make a lot of sense to spend a lot of time (money) learning and implementing the best development practices. You have a limited runway of capital and are scrambling to find a good product-market fit. Your business will fail because of a lack of customers, not because of a lack of code craftsmanship.

Granted, even in this scenario, if you were able to hire a developer that already had good quality habits, you would be ahead.

Efficiency of Habit

So, assuming you have a healthy business, the best approach is to have standard code quality expectations that do not vary. Settle on certain code quality practices and ensure they are applied at all times. Code reviews are a great forcing function for this. There is an efficiency to having fixed quality standards because they become ingrained habits.

Quality As a First-Class Citizen

To create a culture of quality, quality has to move from being an aspiration to a first-class citizen. This means that software quality is given equal value to the business value of the feature currently being worked on. If the current feature is not complete or correct, then obviously it will not ship yet. Likewise, if the code is not written to quality standards, that should also prevent the code from shipping.

Wyatt’s Rules of Software Quality

I hope this blog post has given you something good to think about! If you wish to read more, this post is part of a four-part series on software quality:

  1. Define quality
  2. Manage causes, not effects
  3. Do not treat quality as a separate activity
  4. Apply standards consistently
You can skip to the end and leave a response. Pinging is currently not allowed.

Leave a Reply