Does business need a good code?

Aleksei Berezkin - Oct 8 '21 - - Dev Community

Photo by Markus Spiske on Unsplash

We developers enjoy a good code. We know what is GoF, SOLID, KISS, YAGNI and dozens of these abbreviations. We read a lot of books, we attend meetups and large conventions, we debate on social media. But... Does business we work for really need all of these?

Why business needs a code in the first place?

Business needs a code to solve business problems, and that seems obvious. However, I believe it’s very important to internalize this. The whole thing of writing a code is solving business problems. This means that speaking of a good vs bad code is senseless without regarding a business.

What is a good code from programmers perspective?

There’s dozens of different ways to tell a good code from bad one, but if I’d be asked to put it in one sentence, I’d say:

A good code is a code which is easy to understand.

Yes, it’s that simple. There are a lot of techniques to achieve this, but the purpose is the same: make a code as clear as possible. With such a code a lot of things become easy:

  • Implement new features: it’s easy to read, so it’s also easy to extend
  • Fix bugs: it’s easy to understand and to find where a problem is
  • Move to a cloud: system-dependent parts are separated from other logic, so it’s clear which code needs to be rewritten
  • Optimize: all tradeoffs and bottlenecks are explicit

So does business need all these good things?

Let’s try to rewrite these “good things” into a business language. A good code allows the following:

  • Launch new products in reasonable time
  • Keep product quality high
  • Reduce operation costs
  • Reduce cloud or hardware costs

So the answer to the main question is:

If a business needs quick launches, quality products, and optimal costs, it needs a good code. Otherwise it doesn’t need it.

When the business may not need a good code?

It’s perfectly fine to have quick and dirty solution in some cases:

  • Hypothesis check
  • Prototype
  • Very small and short project

But here comes another hard problem: recognize a moment when it’s not a prototype anymore but a product. That’s the time to deliver the first refactoring 😉


Thanks for reading this. Have you ever explained the business the value of a good code? Did you succeed?

. . . . . . . . . . . . . . . . . . . . .