Development war room

I had a friend over the other day, one of the smartest people I know and an extraordinary talent. We were reminiscing about the olden days, and we were reminded of the principles we have learnt in the army so long ago. Actually, he was the one being reminded because I was never even close to anything like combat myself. As he was reciting his lines I came to think that some of the guidelines may apply to software development. I’ve listed them with some relevant modifications

1. Pursuing on the task at hand, in light of the goal. Goals have the awful habit of changing all the time: the market is prone to change; your boss might have a sudden change of heart. Thus tasks may become irrelevant. I found it a good policy to check every once in a while whether what I am doing, is still in concordance with the goal. Another term that might pop into mind would be the word adaptation. Yet, I don’t feel from it the conviction of getting the task done.

2. The customer is my supreme commander. The customer in this case may range from the actual person or company that makes use of the product, to the sales department. All in all, my customer has a wider angle of view on things than I do

3. Creativity and innovation. While creativity is thinking out of the box, innovation is the yoking of it to the purpose of the product. It’s a tipsy tread, balancing between both. Creativity without innovation is a waste of time, but there is no innovation without creativity.

4. Never fall in love with your own creativity. I keep forgetting that one.

5. Keeping it stupid and simple. Might make the difference when you are showing the product to a customer. Letting go of this principal, may also cost a fortune in application maintenance. Keeping up with simplicity is a task for no fool. Some Damoclesien solution is needed to chop off the unnecessary.

6. Logistics. The average developer, like me, has a thread timeout of half a minute. Any logistic task I have to do that might exceeds that, waiting for coffee, or a long walk to the little boys room, has an overhead of reengaging the lost thread of thought when arriving back to the seat (oh, caffeine enriched coffee may help as well)

7. Standardization vs. opportunism. For me, the key word here is balance. Before the agile love affair, we used to call it the quick and dirty approach, i.e. having things done the fast way, when a customer is at the door. The difference between quick and dirty and plain old sloppy is the set of guidelines and standards that the course of production is built upon.

8. Mapping the critical paths. Pretty obvious where this is going. While mapping tasks, it’s not that difficult to make estimation about dependencies. Once that’s figured out, any project management software provides tools to visualize the critical path

9. Reserve management. Each developer manages his own buffers. This is important when you want to deliver within the time frame you are committed to. This behavior backfires when buffers aren’t properly manages and instead, layers upon layers of time buffers are created. When a developer asks for 3 days on a 2 day job, on average, he or she would only start working on it on the second day. In most cases, the product would be ready on time, in some it would actually take worst case of 3 days, summing up in a 4 day total. The best practice for me is to club all buffers to a single pool. Each developer is assigned with a best case time table, and the development manager controls the pool of time buffers. The probable outcome would be that only a fraction of the tasks are delayed and exceed the time assigned, then pool reserve time is given. No time is spared to be abused.

10. Task breakdown; autopilot.

special thanks to Uri Holtzman