Why Does Software Cost So Much?
Tom DeMarco
3.5 / of 5 Camels
I finished "Why Does Software Cost So Much?" by Tom DeMarco a week ago, and I thought I'd write down the highlights here. I just found that doing that is a real good rehersal of the subject, and I got to re-read some interesting things I already had managed to forget.
Overall, this was a nice book to read, but not great. It feels a bit dated (published in -95 with some texts written a few years earlier) and could use a bit more focus. Still, there are some very good texts in there, especially the things about teams and project management.
1. Why Does Software Cost So Much?
It doesn't. It's the wrong question. And we do fantastic things, even if we do them badly.
So why the slipping schedules? a) We're bad at planning schedules, and b) schedules aren't used to predict delivery dates, but to motivate programmers.
2. Mad About Measurment
Metrics can be useful, but only if you think about what the numbers mean and adjust accordingly. Only one metric should be collected now and forever: defect count. Many other metrics are worth collecting for a while.
Metrics can be beneficial if they are used to discover facts or steer our actions. They can become dysfunctional if they are used to modify human behaviour. That's when we risk people beginning to satisfy the metric instead of the real goals the metric is supposed to measure.
Lots of statistics are out of context or plain wrong. Be suspicious, especially if they confirm your beliefs.
3. Management-Aided Software Engineering
[This chapter is very, very good. It touches on a number of important issues. It's written as a conversation; a very easy-to-read and engaging format]
3.1 The Project Postmortem: Learning from our mistakes
This should be standard practice, but isn't.
A post-mortem should be honest in a no-bullshit way. Admitting mistakes can spread courage to point out existing malpractices in other parts of the organisation.
Post-mortens are often skipped because people are frightened to admit mistakes. When it's skipped, it's because management didn't feel safe enough to examine their failures in the light of day.
It may be useful to hold the post-morten as a group event, the group analyzing it's own performance. The manager should be more of a secretary during this event, and perhaps not even present.
Analysis of the team performance doesn't have to wait until the project is over, until it's too late to fix things. This should be an ongoing activity.
3.2 Better Quantitative Management
We're bad at setting schedules and budgets.
Late delivery is almost never due to lack of skill or effort. "Gee, we missed out schedule so we have to become more productive. Wrong. We missed our schedule so we have to learn to set schedules more reasonably."
The time to start measuring is at the beginning of the project, not at the end.
The most important thing to measure is the burn rate of the most valuable resource: time. The sense of urgency that is so apparent at the end is often hazy and indistinct at the beginning. Yet a week saved in the early days is just as important as a week in the final rush.
Hold up the burn rate for all to see: "Look, we used up one percent of our time today; did we get one percent closer to ship?"
3.3 A Word About Lying
People lie because they have trouble facing up to their own failure. When you lie to yourself, that's denial. That's more difficult to deal with.
The project may need a way of voicing Unspoken Truths.
3.4 Getting The Most Out of the Day
Overtime, since it puts the project under anaerobic stress, is like sprinting; it might make sense in a short race, but none in a marathon.
Meetings should be meaningful. If you don't have an agenda, everyone needs to be there, and you don't know when you're done.
One of the biggest time-savers is a roving tools specialist - a person who's given the latitude to develop tools that save engineers' time.
3.7 Leadership Styles
Listening is the mechanism for pushing control downward, so decisions get made at the right level.
The project leader's main job is to make sure the right people make the right decision at the right time. The leader can't be the one to make all the decisions.
Assembling the right team is an act of leadership. Not just to get the strongest talents, but to get the strongest mix of talents.
People who are blindly loyal or militantly opposed to you aren't useful, people with the attitudes in between are potential allies.
3.8 Co-Location
With the new technology available, is it possible to develop complex system with a physically distributed project team? No, you still don't get the equivalent of side-by-side interaction.
There are many signs that co-location are essential.
Interaction at a distance isn't really interaction at all, just as phone sex isn't really sex. If software development were just coding and debugging, we might get away with some kind of groupware, but the bread-and-butter activity of a software engineer is talking to another person.
