Does code quality matter?

What role does code quality play in the outcome of a business?

I know it when I see it—said a judge on pornography. Quality code is the same—you know it when you see it. It is challenging to define what quality code is. It is tough to come up with quantifiable metrics on quality code. But, the instant you see quality code, you know it.

Another reason for the difficulty in verbalizing quality code is that it lies in the beholder’s eyes. One person’s high quality is another person’s low quality.

Whenever you talk of quality code, a question pops up—how important is code quality to the success of a business(startup)?


I have wrestled with this question for ages. After spending years meditating on this question under a Bodhi tree in the Silicon Valley of India—Bangalore, I have arrived at an enlightened(also flippant) answer—you cannot quantify this, it matters for sure.

Whenever you talk of quality code and business success, someone usually points out at a business that succeeded despite horrible code.

Businesses are messy. Code is only a part of the story. There are other things that matter to a business’s success. It would be specious to claim a business succeeded despite bad code.

Many businesses that succeed with lousy code are in markets so good and have their timing right that they would have hit the home run anyhow. With quality code under their belt, the journey to the podium would have been pleasant.

A parallel I can think of is the importance of good health and habits. Conventional wisdom says that healthy habits keep you disease-free and lead to a long life. I can always point to a person who smoked and drank her way to a ripe old age. Conventional wisdom says that good habits lead to success. I can always point to a successful person with terrible habits.

Does it mean that good health and habits are immaterial?

Another problem with code quality is that you see its benefits gradually. It is a compounding effect.


The human brain finds it difficult to grasp compound interest. Albert Einstein said—compound interest is the 8th wonder of the world. He who understands it earns it; he who doesn’t pays it.

Compounding is tail heavy. During the initial days, it does not make your eyes pop. As time goes on, compounding gains momentum, reaching a crescendo at the end—the same with quality code.

Good code compounds positively. Bad code compounds negatively. Bad code gradually drags your business down, making it slow and sluggish.

Get articles on coding, software and product development, managing software teams, scaling organisations and enhancing productivity by subscribing to my blog

Photo by Volodymyr Hryshchenko on Unsplash

Communication Architecture

Organizations do not give attention to their internal communication architecture. Internal communication evolves organically. Deliberately designing the internal communication architecture makes a difference.

By internal communication architecture, I mean:

  1. How does information flow?
  2. How do team members communicate with each other?
  3. When do they communicate?
  4. What is the medium they use for communication?

A decoupled(push-based or broadcast) structure for communication works the best.


Guiding principles for a decoupled communication structure:

  1. People should not be polling each other for information.
  2. There should be a specific place for information lookup.
  3. There should be pre-defined contracts for the above.

Let us go through an example. 

Imagine an organization with a development(dev) team and a quality assurance(qa) team. Dev team deploys a build for testing. After the deployment, the qa team starts testing.

One way for the qa team to know the deployment status is to poll the dev team periodically and ask whether they have deployed the build.

Another way is to create a contract for the dev team to send a Slack message in a channel once they deploy the build. 

The latter broadcasting style of information dissemination is decoupled. No one has to poll each other for information. As long as the dev team adheres to the contract, and the QA team knows the place to look for this information, it works.

A simple test to figure out your organization’s communication structure:

If a person asks you for information, and you redirect them to a person instead of telling them the steps to find the information, your organization practices the polling style of communication. 

Polling Based:

Hey, how can I get this report?

You can ask Shyam to generate it for you.

Broadcast based:

Hey, how can I get this report?

Add yourself to this email group, and you will receive it regularly.

Polling based communication has the following downsides:

  1. It is anxiety driving for the person who is seeking the information.
  2. It irritates the person who is supposed to give the information.
  3. It does not scale as the team grows.
  4. All the above lead to unnecessary confusion and aggravation.

Push based communication leads to automation. In the dev qa example, the dev team can automate the publishing of the Slack message.

For the push model to work, everyone needs to adhere to the established contract. If one does not do that, the system collapses. 

Communication forms the cornerstone of organizational culture. Internal communication can make or break organizations.

Get articles on coding, software and product development, managing software teams, scaling organisations and enhancing productivity by subscribing to my blog

Photo by Franck V. on Unsplash