The importance of code that communicates

One of the major reasons that our industry produces software that is full of bugs, with a massive cost of change and with a short life expectancy is that developers do not understand the importance of writing code that communicates. Yes, one of the most important aspects of software development is to write code that communicates.

Disclaimer: There are several reasons software projects fail and many of them are caused by management – way above the developers. Still, we as developers have to take our part of the blame, and crap code is our contribution to the failure.

It is not about algorithms and performance

I didn’t learn much about communicative code at the University. And I still do not think people learn a lot about it. Students probably still think that software development is all about performance and effective algorithms. I’m sorry, often it’s nothing like that. In most business applications today there are no fancy algorithms. It’s just a huge amount of code that is trying to express the rules and logic that exist in the business. Performance might be an issue, but it has nothing to do with tweaking algorithms, it’s about architecture, data loads and sometimes really bad code.

So, what’s the problem?

The major problem with business applications today is the huge amount of code. The amount is not a problem in itself, but it gets to be a problem very fast when it’s hard to understand what it does.

Let’s take a simple example: Methods in today’s software are often way too long. It takes a lot of time to understand 100 lines of code that does several different things, and it’s even harder to change it without breaking something. I’ve seen tons of code that looks like that, and I’ve spent ages fixing such code. Believe me, code like this is very expensive and it will soon be full of bugs. Such software deteriorates pretty fast, and before you know it you’re at a point where whenever you remove a bug, you add two new ones. We should all be ashamed, honestly.

Code that is hard to understand is hard to change; software that is hard to change will be expensive and slow to change, and the risk of the changes adding new bugs is high. Who wants an application where it costs a fortune to add features, takes forever, and adds new bugs?

It’s about communication

Yes, it is a mess, but what can you do? We have to understand that writing software is about communication!

Put simple: Code that is easy to understand is easy to change. When it’s easy to change the risk of introducing bugs is low. That’s the kind of software your customers want!

Martin Fowler hit the nail on the head when he said:

“Any fool can write code that a computer can understand. Good programmers write programs that humans understand.”

What can I do?

When I write software, my main concern is actually if I am expressing my code in a way that others will be able to understand. And the “others” are quite often myself. When I get back to code I wrote two months ago I want it to be really easy to both understand and change that code.

When I have to work with code that is hard to understand I often make it easier to understand first, then make the changes. I keep my methods short. I keep my classes short. I try to organize my code so that related logic is grouped together, and unrelated logic is separated. I write tests for my code that explains the code. I care about the code I write.

Writing code that communicates is first and foremost a mindset. Get it! Then it is a set of practices and principles. Read them, train them and practice them. Find out what works for you. Nothing can replace experience.

Robert “Uncle Bob” Martin has written an excellent book on the topic: Clean Code. Read it now! Kent Beck is also passionate about this, and wrote this book: Implementation Patterns.

I’m holding various presentations about what I call Code Quality. Communication is a vital part of that.

- Tore Vestues