Sunday, February 15, 2009

What is good code?

Well... I have nothing to say about The Da Vinci Code. Looks like that code is much better than mine.

If you're in software development, you've heard phrases "good code" and "bad code" at least once. It's rather safe to say that any code is bad. But does anyone know what a good code is?

In the past I had to answer this question on one of the job interviews. I spoke about technologies, patterns, readability, reliability, extensibility, girls, clubs... well... the last 2 things were part of a different conversation. I got an offer, so I believe my answer was OK.

I sincerely described what I thought a good code should be, but that was developer standards. Who cares about developers? Sorry, guys, that's the reality...

For a software developer his code is a product of his work. There's no work without a client. There are all kinds of clients out there: customers, managers, developers themselves and any combination of the above.

Client makes the rules and eventually owns what the developer had produced. So, if the client is happy with the code, then the code is good. It's that simple.

For a client to be happy with the code it has to meet all his requirements. And a lot of developers would be surprised finding out that, for instance, readability or extensibility are not always part of those.

The reason is developer's standards are not always in line with the client's goals.
Here are a few examples:
  • Chances are the more requirements a client comes up with, the more expensive the product would be. The client is trying to optimize the requirements to fit into the available budget, resources and time constraints.
  • Time is money, but nobody says it works the other way. Clients may have funds, but not enough time to build the whole house, they just need 3 walls, so they can register it as a building at the town hall by the end of the year (don't try it at home).
  • Some managers specialize on making a career growing huge bloated code that will never work. It's understandable. They are salaried employees. Till promotions affect their lives more than stock fluctuations it's naive to assume they care about efficiency more than about number of their reports.
Good code is like good food.
What is good food?
Peanut butter and jelly? Is it still good for you if you have a peanut allergy?
French cuisine? What if you're not willing to spend your daily wage for a huge fancy plate with a tiny piece of liver of a duck that died from cirrhosis?

To each his own. That's exactly the case with software development. If the client is happy with the code, this means the food was good.

P. S.
Client may be happy with the food, but not with the service. That's a different story.

P. P. S.
Your next question is probably "How to make a client happy?" Not only is it a different story, but it's unlikely anyone knows the right answer. I can only define 2 main aspects:
  1. It's important to have a good chef in the kitchen. The one capable of delivering a code that satisfies a client. So if client wants it to be reliable, readable, extensible and medium-rare, the developer has to be able to make it that way (not just well-done).
  2. It's even more important to know what the client really needs. And this part is not easy at all. Unlike with food... Since it's not food related, it can wait till the next time slot for blogging...

No comments:

Post a Comment