Does business need a good code?

#codequality #cleancode #programming #productivity

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?

Oldest comments (4)

UchiTesting • Oct 11 '21

Hello,
We IT guys and devs are for a big part of us obsessed with the idea of "good code".
Even as beginners we may not know exactly what it is, yet we instinctively know it makes sense.
So as a beginner I read about it, yet nobody really talks about it. Then names such as Robert C. Martin pops out. You end up imagining that code must be clean no matter what.
Then you developed the habit to worry about that matter yet you still don't know.
Until one day you read or see the actual Robert C. Martin basically telling your code should not be perfect while you write it. It should be clean at commit time. But in between you can do what it is you think is needed and refactor.
That was to me very comforting to realize it is not so rigid.

Also in the cases you mention there's no point to do super advanced clean code.

As an example, when I was trained in .NET and C# particularly, I did bring that taste for clean job with me. We were given assignments or regular basis. During the time of the training, when things became a bit serious, I often thought I was late compared to some others. But it was just me trying to apply MVVM that was fresh to me while the instructor expected us to write in the code-behind. When the instructor saw that, he told me to stop trying MVVM. And indeed it went faster from then.
Also at the end of the year I learnt that some people claimed they finished the assignments while they actually didn't. Also I could see some GUI worth Picasso or Dali with controls all over the place. Looks like they drag'n'dropped from the toolbox while I was trying to have those things organised properly writing XAML code.