God had it wrong. The seven deadly sins aren’t wrath and sloth and whatever is in that list. He forgot a very important one: inefficiency. In fact, it should be made into a commandment:

Thou shalt not create a situation in which other people are waiting for you in order to be able to perform their tasks. This will only unnecessarily drain the company’s resources and make the waitees incredibly cross. So sayeth I.

Say, hypothetically, that a person is entering a new project and has taken upon himself the task to write a library. This project attempts to be agile and contains very little documentation. In fact, it is encouraged to store knowledge in people and not on paper. On Monday he proposes an API to the library in question but receives no response. On Wednesday he offers a more detailed description of the API and brings a few ambiguous situations into light. Still no response. He discusses the functionality verbally with some people, and then offers an even more detailed description of the API the following Monday. This is met by a short e-mail response at last: “Let’s discuss this tomorrow.”

Well.

Hypothetically, what’s wrong with this situation?

First of all, keeping little to no documentation may sound fine in practice, but it will lead to ambiguous interpretations and difficulties for new team members. Secondly, despite this it can function well if feedback is offered speedily; but it will cause unnecessary work due to unclear specifications otherwise. Thirdly, the lack of information in the response makes it totally useless: does the API need corrections; does it need to be re-structured totally; is it passable but needs to be understood by all parts – the e-mail response tells us nothing about that. It becomes the final nail in the coffin: it becomes impossible to perform any more work on the library because there’s no way of knowing if it will be useful or not. Many hours of productive time is lost because of this. The person responsible for the library will most probably rant about the situation on his blog instead of doing anything worthwhile – effectively losing the company money since a useful pastime is not possible to find.

I hate inefficiency. Or rather: I hate waiting for other people. I don’t care how others do their work, but I loathe being unable to do something productive when I want to. It just leads to frustration, cynism and irritation. The library in question could be written in a few days if the desired functionality was known and specified. In a perfect world projects would be agile, but there would be non-ambigous and thorough specifications for everything. A contradiction in terms? Maybe, maybe not: I fully believe that a team can work in an agile manner but still keep information readily available.

However, playing the devil’s advocate I have to blame myself as well. The information is readily available – it’s simply spread out over several people who have lots of other issues to deal with. If I were truly desperate to be productive I would hunt them down and demand instant feedback on my thoughts, and ask them to guide me to the ones who could offer constructive criticism if they weren’t able to give me feedback. Maybe that’s what’s expected and required in a situation like this. Personally, I would prefer it if people could offer these hints by themselves, without any external pressure.

Maybe I should think of that the next time someone is waiting for a response from me.

Final note: I used the term deadlock in the title, but that’s of course not applicable anywhere. This is simply a mutex that’s locked for too long. But I like the power and force of the word deadlock, so I used it anyway. Sue me.

This entry was posted on Monday, March 19th, 2007 at 5:25 pm and is filed under Software Development. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.