quality – Dazed & Confused

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: https://web.archive.org/web/20101227161814/http://jkarlsson.com/blog/2009/06/24/the-locality-of-code-changes/

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.

Report on zero-defect code

The US National Security Agency has released a case study showing how to develop zero-defect code in a cost-effective manner. Diomidis D. Spinellis has taken a closer look at the claims and the code released for this project. At first when I read through the article I agree with most his points, but it gets quite interesting when I read the comments.

The things we consider important when living in our business-entrepriecey-systems-world might not be feasible when you’re doing realtime-secure-flightsystems etc. If you are working under the paradigm of formal verification, loops might be a bad thing.

I don’t know much about this stuff, and I am quite content not needing to think about it. That said I really try to strive for zero-defect, maintainable code, it just doesn’t seem worth it doing formal verification on most systems I work on. I should look into it though to learn a little about it without picking it up. I think working in this fashion will probably block all attempts to be agile.