The cost and benefits of cleaning up code

I’m not a very scientific person. Actually I’m probably quite un-academic in my approach towards software development. There are a lot of stuff I consider essential that havn’t really been proven, but I won’t stop doing it just because of that. It might be a weakness, but this field is also way too complex for us to wait for stuff to be proven scientifically before we do it. Yeah. People are complex. 😉  It is however very nice when people smarter than me can prove stuff, especially when it matches my own world view. 😉

Even though it is not very scientifically conclusive Joakim Karlsson has some very interesting results on the locality of code changes.

EDIT: The original article is gone after all this time. Here is a link for the internet archive:

As Joakim discusses this relates closely to how you evaluate whether the code you are currently looking at is worth a cleanup. It’s very hard to do a good evaluation of this, especially since we always seem to underestimate the time to, and frequency, of when we will be re-visiting that code.

On my own gut feeling I have started to do a lot more fixes when I stumble upon them, exactly because I have done this error so incredibly many times: I have tried to be cautious, and avoid doing unnecessary work by cleaning up stuff that I’ll “touch just this once”. But by touching it you introduce new bugs, change old behaviour and learn something new. All of this feeds back into the code, and you will most likely be debugging or making more changes to that code within the near future. It’s nice to see a more structured approach to investigating this.

There are some good suggestions and even references in the comments of the article. It’ll be interesting to see any refined results on this.


SOA and it’s promises

Johannes Brodwall has a good article about SOA and what it claims to deliver. They claims are appealing theories, it’s just too bad it’s doesn’t work. The only thing I wish to extract and use from SOA is the governance, but you don’t need an ESB to do that. 🙂


Automate it all

When doing Agile development identifying and eliminating waste is a important practice. There is many things to eliminate, but one of the usual remedies is to automate a manual and error prone task. In my experience it is worth spending a lot of time automating tasks, not just because it saves time but because it gives you predictability.

Taking automation and predictability all the way would probably lead you to something like Continious Production that Paul Duvall has a post on. Johannes Brodwall also has some good perspectives on something similar.

It is sort of the holy grail of agile development, and would be something like what Jeff Sutherland said the are doing at Patientkeeper. They have deploy at the push of a button that enables them to deploy new versions to all their customers on a regular basis.

Spend time automating people. 🙂