Manager In A Strange Land: Books Are Good

In my last column I talked about cost-benefit analysis and using it to decide how to improve your processes. This column I'd like to point out that other people have already done some cost-benefit analysis for you.

There are a lot of books and articles on software development and management out there. There are even a couple on game production. You could do a lot worse than to just follow these books advice blindly.

I know a lot of top-notch leads at game development companies who read books, not just on how to program, but how to manage. Mick West of Neversoft, for example. He's one of the few people out there who really does ship a great product on time, every time. And he doesn't do it by making everyone put in a lot of overtime.

An example of something I've learned from books: there's widespread lore in software engineering literature about the value of fixing bugs as early as possible in the development cycle. Now, the source of this widespread information may be suspect. How exactly did they estimate the cost of fixing these bugs? But the fixing-bugs-early thing has the power of our experience behind it; any coder can tell you that they had to fix some bug that was in code they hadn't looked at in months, and it took them days to find something that they would have found in just a few minutes if a tester had alerted them the day after they submitted their code.

This is something I continually hammer on; that one of the best ways to improve productivity on a project is to increase the amount of testing and debugging early on in the project. I went over this some in a previous article, "Production Testing and Bug Tracking", but I want to reiterate it, because a lot of people find it counter-intuitive: "Rushing a project into testing before it's done just means you'll get a lot of bugs submitted having to do with features that aren't even implemented yet."

Bill Dugan, our executive producer, calls this the "duh" factor. All those bugs reported that say things like, "Characters don't have shadows" or "Placeholder textures on this building" tend to piss developers off.

What is the big deal, exactly? Because somebody might say something we already know, we'd rather shut them up completely and have no bugs reported at all? There's a certain machismo going on here: we're acting like the guy who's driving and who gets pissed off when his wife tells him there's a cop on the side of the road ahead. "I see it," we growl angrily. The next time she sees a cop she doesn't tell us. And we get a ticket. And then she's really smug.

We have to learn to accept these redundant bug reports, so we can catch the ones that aren't redundant. You can deal with redundant bug reports in a few ways. You can leave them assigned to nobody and wait for the feature to get done before marking them fixed. You can mark them low-priority and assign them to the person who is going to implement that feature, and tell them to mark it fixed once they've actually gotten around to it. You can mark them "Not a bug" and add a note saying that this "bug" will be fixed when the feature is actually implemented, which is on the schedule for such-and-such a date. You can try to stop the bugs being submitted at all, by having a test plan set up with your production testers that tells them exactly what they're supposed to test and be looking for, such as crash bugs.

But I digress. I was talking about books. It is possible to be misled by books. Rapid Development discusses the importance of code reviews, for example. So I read multiple books on how to do code reviews, and instituted a code review policy on my team, and…it took so much time, and caught so few bugs, that it would actually have been cheaper for us to wait for testing to find the bugs and then fix them later. I'm not actually saying you shouldn't do code reviews, by the way: although they were a wash as far as reducing the cost of bugs, the benefits in communication and enforcing code standards may still make them worth it.

So although following books advice blindly is better than learning things the hard way, better still is to adopt the suggestions from books slowly and carefully and then analyze for yourself whether those suggestions really were worth it.

Also, books tend to have a really low ratio of information to words. One of the reasons I'm writing this column is to take the things I've learned from books and condense them into one-thousand word snippets. If you don't have time to read books, read these articles. If you do have time to read books… then you don't need me.

And if you do have time to read books, I recommend that you read these, more or less in this order: