Ars Subtilior

Less Code

It is a fact that the code we write today is tomorrows legacy. Have you been working with legacy code? I guess all of us have already refactored, rewritten or translated legacy code in their professional career. It can be painful. It might also open up a new view on programming topics (like when I learned about COBOL for one of the projects I was involved in).

But since our own code, written today, will soon be legacy, what should we consider when we write that code?

For me, the documentation of the code is only a part. I’m a big fan of documenting the interface level contract of code. At the same time I’m all against documenting the body of functions (which imho is a violation of DRY). I mean, where is the sense of:

#Update each item <- stupid comment!!!
items.each { |item| item.update }

And that example brings me to this post’s title: writing less code will make life for those who have to deal with the legacy we are producing easier.

Less code can in my opinion be achieved by using the right programming language for the right job. The snippet in ruby above is self explanatory (even for someone who doesn’t know ruby well, all he/she has to learn here is the syntax for passing parameters into blocks). It can get more efficient with DSLs. Rails style of declaring associations is about as succinct as it can get.

For concurrent programs, using a language that supports concurrency on the language level like Erlang will make your code more terse.

I am not claiming that programs written in Ruby or Erlang or Scala or Haskell are easier to read than programs written in C# or Java. But I think that choosing the right language for the job can keep a lot of boilerplate out of your code. Some people claim that about 80% of the legacy code of any given system is boilerplate and infrastructure and only 20% are of business value (I would disagree in the case of COBOL though, my feeling is that it is more like 50/50 there). And exactly this is what makes working with legacy code annoying, tons of infrastructure to step through to find the few business parts your interested in.

Try to keep as much boilerplate and infrastructure out of your code, and the coders coming after you will thank you for this.

P.S.: Sure, you can write Java with that goal as well, keeping classes that contain business logic separated from classes that contain boilerplate, but most people don’t do it, because tha language doesn’t encourage it.

Back blogging

The last one and a half months I didn’t find time to write articles although I had several topics in my mind because other activities kept me busy:

First, I had been in a customer engagement with a busy schedule. It was JSF project and I was called in late to help out before the imminent release date. Working with JSF again included lots of workarounds, especially yet another workaround to get the GET verb working. I guess I’ll write a bit about that project here in the next days.

Second, vacation! Yes, I managed to have some vacation and even managed to get it in sync with the busy schedule of my wife.

Third, I’ve been talking with several startups lately. The economy is on the rise in Germany and the risk averse tendencies of the last five years are finally starting to ebb away. And Ruby gets some attention as well :-)

Fourth, a busy private schedule with lots of appointments and meetings (which I might talk about later on as well, but probably on an other blog).

But since there a several topics in my queue now, I will be blogging more often in the next weeks.