Today at work, we talked about ripping of^W^W repurposing some material from that McConnell book on software engineering, Code Complete. So maybe today is a good day to post a book report on another McConnell book, Rapid Development.
This is a book about software project management. In theory, this book isn't a generic software project-management book. Buuuut a lot of generic software project-management advice creeps in. After all, before you can tune your project for fast development, you need to know basics of project management—learning how different things can affect your schedule. How to diagnose a borked schedule.
So in theory, the book was supposed to rush through the basics and then really wallow around in some best practices that you might use if you're less concerned about, say, project cost, but really really want to pull in the schedule. But it ends up talking about all kinds of project management stuff. This makes sense: try to think of an aspect of software project management that doesn't affect the schedule.
So the bad news is that, despite this being a thick book, there weren't many techniques in here that I hadn't seen before—it covers a lot of the usual suspects. On the other hand, I've read a bunch of stuff already; if I hadn't then this book would be a good survey of software project management techniques, with some thoughtful discussion about the trade-offs of choosing one over the other, the situations in which they're useful and/or harmful, etc.
And there were things in here that I hadn't heard of. There was one section with a case study of a project that had gone over schedule and been killed. And then upper management decided to revive it. The folks working on the project set up dozens of "mini-milestones". It sounds like a PITA to set up, but it worked. Keep in mind: the people on this project were de-motivated. Their project had been killed! They felt like losers. So each time someone finished off a mini-milestone, they got a little reminder: hey, they were accomplishing stuff. They just weren't accomplishing stuff at the rate predicted by the original, wacked-out schedule.
I've seen projects in a past-the-deadline reeling punch-drunk mode. I never really saw a better way out than "buckle down and code harder", even though that's the attitude that led to the trouble in the first place. And if you're just a leeeetle of schedule, then buckling down for a while will work. But you hear about the nightmare situations and you wonder: what would we do? This book had some techniques to bring to bear.
It also talked about the difficulty in scheduling in organizations where schedules aren't respected. The place where I work now, we don't usually try to work to a schedule. That's not the kind of disrespect this book gets into. It talks about the kind of disrespect I'm thinking of from a few jobs ago where we had schedules—but nobody actually expected work to finish by then. Except... some people did. Our CEO would ask an engineer how long it would take to do some task. The engineer would say it would be done by mid-1993. The CEO would tell customers it would be ready around mid-1992. Customers of our company who didn't know about software scheduling might make plans to use this software in mid-1992. Employees of our company who didn't know about software scheduling got fooled, too. One might think "Gee, we need to get ready to ship this software in mid-1992: we'll need lots of floppy disks and boxes, I'd better order those..." and then wonder why those boxes gathered dust for a year.
Later on, I asked that CEO about his schedules. He said, If we do not plan for the impossible, then we shall never achieve it. At the time I thought That is the most asinine thing I ever heard. Of course, the whole reason I'd asked about schedules in the first place is that I was grumbling over the fall-out of some nutzo schedule for a schedule that had gone poorly. But... really, that was not the most asinine thing I'd ever heard. Although his attitude towards schedules played havoc with my sense of responsibility, his attitude was in touch with the zeitgeist.
Most scheduled projects blow out their schedules, and most software projects just plain go nowhere. That CEO must have been doing something right, because that company had a darned good engineering organization, one I feel lucky to have stumbled into. As for short schedules, there is something motivating about a tight schedule. Oh, a 50% unrealistic schedule is de-motivating, sure, but a 5% tight schedule can focus a team of programmers. Real artists ship, but not all programmers are artists by nature. Some programmers stay focused just fine without schedule pressure. But there are some where you just want to nudge them so often, remind them "There are other people out there—we call them 'customers'—who would love a chance to play with that software you're tinkering with. In fact, they're so eager, they'd like to play with it soon. And maybe that's more important than you finding out whether the supplemental index sorting service could be implemented more elegantly in Scala right now." A schedule can be a fine process for reminding developers about that lovely plan they signed up for a few months back. A tight schedule can remind one of priorities.
This book didn't make me want to start scheduling out my projects. Respect the schedule, yes. Miss it, no.
This book had some other good bits. It has a ranked table things that motivate programmers, programmers' managers, and the general population. This table was aimed at managers, reminding them that programmers respond to different stimuli than they do. Of course, I read these books so that I have an easier time dealing with management, so I'll jot down the first few items that motivate them:
- Responsibility
- Achievement
- Work itself
- Recognition
- Possibility for growth
Managers value trust and loyalty in others; thus it makes sense that they'd be motivated by responsibility—a measure of their own trust and loyalty.
Managers value recognition more than most folks do. A programmer knows that elegant work is often overlooked—it's so smooth that it doesn't catch the eye. So much of a manager's duty involves judging others, they think about it a lot, want to make sure you know how much other folks value your work.
Another thing I wanted to remember from this book: if there aren't enough people in a group, they might not gel as a team—the interpersonal stuff between individuals drowns out the team feeling. Maybe a "one-pizza team" (if I may use the Amazon measure of team size) won't hold together as well as a "two-pizza team". That's nonintuitive at first... you think of small groups as the ones that have the easiest time getting along. But the dynamic that he describes sounds familiar. So, glad I read that.
