"Learning
from experience is the worst possible way to learn something.
Learning from experience is one up from remembering. That's not
great. The best way to learn something is when someone else figures
it out and tells you: 'Don't go in that swamp. There are alligators
in there.'"
- Clay Shirky, "A group is its own worst enemy."
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:
______________________________________________________
|
