Thursday, January 1, 2009

Code with less noise

Accidental complexity

Like most developers (I guess), I often have to deal with code that other people have written and more often than not the code that is providing the real value pales in comparison to the amount of code that is generating noise due to language verbosity & lack of abstraction power. Brain cycles are simply wasted focusing on stuff that provides no value, because it does not add meaning (on the contrary). This is one of the side effects of accidental complexity or choosing the wrong tool (i.e. language/framework) for the task at hand. Which leads us to the concept of:

Noise and signal

Noise in programs: the hard to read and the tedious a.k.a bloat a.k.a accidental complexity

Obviously, noise makes code much less meaningful. Ideally:
We want to strive to make sure every single line of code has some value or meaning to the programmer. Programming languages are for humans, not machines. If you have code that looks like it doesn’t do anything useful, is hard to read, or seems tedious, then introduce an abstraction that will let you remove it.
So then:
If a shorter program is shorter by virtue of having less accidental complexity, it’s better. It has a higher ratio of signal to noise. - Reg Braithwaite

Some code

Let's write some simple Groovy code to illustrate this.







So what?

Well, as a simple example take the line:

assert ['ULC'] == invoices.items.grep {it.total() > 7000}.product.name

In Java we would write something like:
It's obvious that I'd rather read one line. This is just a simple example (from Groovy in Action btw) but it's obvious that:
Less noise -> less accidental complexity -> more meaning -> less maintenance cost.

Programming is a pedagogical trait
If your language’s mechanisms for abstracting away accidental complexity are so laborious that you cannot remove the useless, the hard to read, and the tedious from your programs without introducing code that is even more useless, harder to read, and more tedious to your framework, then change languages. -Reg Braithwaite
To sum it up:
  • Code is read much more than it is written. If people can't read your story, they can't improve it or fix it. Unreadable code has a real cost. This is the famous technical debt
  • There are many ways to write meaningful code, even in Java
  • Groovy is definitely a good option for people who would like to stop torturing themselves with native Java syntax and want to make their code easier to read while at the same time protecting the Java investment that has been made in different frameworks and tools (flat learning curve). It has the best IDE support and the syntax is very Java-like. Yes, syntax is very important.
This last point leads us to the concept of learning: new languages, new techniques, in order to work at higher levels of abstraction and thus reach higher productivity. There's no other way if you want to be among the mythical 5%. :)