Drought breaks..

I’m pleased to report that it appears the biscuit drought has broken. We’re seeing good falls of assorted creams as well as the good old family assorted again.

That is a relief!

One of the nice things about my current workplace – they provide tea, coffee, Milo (but not Bonox!) and usually once a week if you’re lucky you’ll find some bickies in the kitchen, presumably left by the biscuit fairy.

Death March by Edward Yourdon

- published by Prentice Hall, 1997

When I first began reading this book, I thought it would be all about the team that came before us… the one that spent a lot of time delivering something that didn’t work. But the more I read, the more I found myself identifying our current team with the descriptions in each chapter. Curious as the title doesn’t sound that positive! As Wikipedia defines it, a death march project is one that is destined to fail.

One point that comes out repeatedly is that while in some ways “Death March” projects are not intended to be the norm, more often than not they end up being the de facto way that many IT projects are run.

In Ch. 1, characteristics of a “Death March” project are listed as including:

• Tight schedules
• Small team
• Limited budget
• More features
• Smaller scale

Hmm.. that sounds familiar!

In subsequent chapters he goes on to cover topics such as Politics, Negotiations, People, Processes, Tools & Technologies and finally the idea of “Death March” projects as a way of life.

In Ch. 3, the topic of Estimation is examined, and the value of having an experienced project manager who can estimate slightly better than just “gut feeling”, and that there are software estimation tools that can improve forecasting accuracy. I reckon Steve McConnell’s Software Estimation: Demystifying the Black Art (Best Practices (Microsoft)) could be worth a read to learn a bit more about this topic. I’ll add that to my wish list!

People can make all the difference, and our team certainly bears this out. I can’t agree with the comment that 80 hours a week is ok though.

Yourdon also espouses the importance of good workplace conditions – in particular quietness and privacy (eg. separate offices). There’s certainly empirical evidence to reinforce the productivity benefits, which flies in the face of the current trend of “open” office space, cramming as many people into tiny cubicles as possible.

Triaging tasks/bugs are critical, and allows you to prioritise what is important.

When this book was first published, there wasn’t much in the way of “Agile” development practises, but I think Yourdon is alluding to this when he makes mention of using RAD tools (refactoring), mini-milestones (iterations) and daily builds (continuous integration).

One thing I did find annoying was Yourdon’s use of a monospace font when listing the emails in each chapter’s list of references. This made them very hard to read and I mostly ended up skipping over them as a result.

Overall I came away inspired by this book. Yourdon highlighted the many pitfalls that await a team who are engaged in a “Death March” project, but does offer hope that under the right conditions, you can achieve success.

sevenfold – Yeehaa!

We had a blast last night. It was great fun. We ended up performing about 10.40pm, and seemed to be well received. The stage was a little small but we managed to fit all 7 of us there (and Billy-Bob said they once had 14 so we’re not the largest group to play there).

The quality of the other bands playing was very good, but I think we held our own. No word from any record companies wanting to sign us up yet.

We all got a free drink voucher, but curiously they insisted the voucher was good only for a schooner of beer, even though all I wanted was a “raspberry” (surely soft drinks cost less than beer?). I bought one instead, but had to tell the girl how to make it - “just raspberry cordial and lemonade”. Yum.

On an final note, I also discovered that “pub rules” for playing pool do exist – fortunately I wasn’t the one who failed to pot any balls :-)