Monday, January 24, 2011

Expect the unexpected

What slows development down more than anything else?

One thing that provides endless amusement to me and I'm sure many others is when libraries or the existing source you have to maintain do something unexpected. When I say unexpected, I mean something that no-one would expect given the standard practices that you've come to understand, or standards you've been lulled into appreciating by the first class obvious nature.

Why would you expect a function titled "addThing" to remove the last thing that was added and replace it with the new one? Why would you expect "addThing" to add to a list, but that list to be handled as if there was only ever the first item that was added in the list?

I think that most of the time I spend debugging something, it's because some common sense lead the coder into thinking that a function behaved a certain way, and that was wrong.

Does this mean that the coder responsible for the original code is wrong, or the user of the code? To me it is hard to say as we are all the makers of code, and also users, but why do we end up blamings the coders instead of something else? What else could there be that makes it possible for us to misinterpret the meaning or use of a function? This problem is normally covered by the Ronseal rule, but when functionality needs to change, sometimes people forget to change the name of a function / class.

The simplest solution is to peer review, but that doesn't always work as the peers have to be aware of the dangers too.
Maybe submitting misleading names as bugs?

What would you suggest?

1 comment:

Funcan said...

I suggest blunt force trauma in gradually escalating amounts, largely because I've been having a bad day due to a similar issue...