     |
 |
 |
 | | | | |
 |
|||
 |
||||||
          |
 |
 |
||||
|
Manager In A Strange Land: So you want to make some changes at work. A bunch of people on the team have some ideas for how things could go better. You've done a postmortem or two. Maybe you've even done Critical Stage Analysis, as suggested by Wolfgang Hamann. These ideas probably range everywhere from "we should have a massage therapist come in every week" to "we should have someone actually maintain the schedule." Some of the ideas contradict each other: "We should put in more overtime." "We should put in less." "We should all use instant messaging." "We should outlaw instant messaging." Even if everyone is ranking these ideas for process improvement from least important to most important, you still don't really know which ideas are going to get the most bang for buck. One thing is certain; if you tried to implement all the ideas, you'd be so busy implementing ideas (and then un-implementing them when everyone complained) that you'd never get any actual work done. It's more important to do the right thing than to do things right. That seems obvious, so why do we make so many boneheaded decisions all the time? We need to practically assess how much an idea for process improvement is really going to help us.
When you're playing Kohan, you often have to make this decision: do I spend more to build the Iron Export, which makes more money, or do I go for the quick-and-dirty Stone Export? Most people say the Iron Export, but it takes about five minutes of playing for the Iron Export to break even. If you need money now, the Stone Export is actually the way to go. Similar decisions come up in game development all the time. (Game development is a game where the turns are eighteen months long… See? All that time you spent playing games really does pay off.) A lot of the time, you can do a quick and dirty cost-benefit analysis. For example, "If we adopt this tool, it will cost us this much cash and time up front, but then we'll save about a half hour per person per day, so it'll pay off after this many weeks." We did just this sort of analysis when we decided to switch to Perforce from SourceSafe. The ! / $ was obvious. (That's bang-over-buck. Get it? I'm such a geek.) Sometimes, the bang-over-buck isn't so clear. We considered switching from Max to Maya, for example, in order to get the improved animation and texture-mapping tools. The tools weren't quite as good as advertised, and Discreet made efforts to keep us happy with Max, so it certainly wasn't worth the massive overhead that it would have cost to switch. If you plan on staying in business forever, almost anything you do will be worth the upfront cost. But if you're always doing things that cost you upfront for benefits later, you won't be in business forever. A good example of this is engine building. Rewriting an engine from scratch is almost always going to be cost beneficial in the long run, but the cost benefits are almost never going to be realized on your current project. Your break-even point comes two or three projects down the road. A lot of newbie coders don't want to believe this. I don't want to believe this; I'd love it if we could whip up a new cruft-free engine in a couple months at the beginning of every project, which contains none of the mistakes we made on our previous project. The thing is, it's the project you're currently on that's important. If you sacrifice the quality of your current project, you may never see another project. We decided to rewrite our engine for Draconus, and if it wasn't for the fact we were doing other games on the side with other people's engines, the Draconus engine never would have lived to become Spider-Man. Engine reuse is a big example. You'll encounter many small examples at work all the time, every time a coder says, "This system is crap, we might as well chuck it all and start over." Different people have different rules-of-thumb for dealing with these situations. Joel Spolsky says Never Start Over. Shawn Hargreaves says Always Start Over. These rules of thumb are no good. Every time a situation like this comes up, you have to ask yourself: can we afford to take the hit? Here's my rule of thumb: in my experience, I've been burned by rewriting code that I didn't have time to rewrite much more often than I've been burned by "chopping wood with a dull axe." When you ask people how long it's going to take to roll out this new system that's going to save so much time in the future, remember they're going to give you an optimistic estimate. And if you're not sure that it's going to be worth it…don't do it. Unfortunately,
it's rarely easy to estimate the cost or benefits of putting a new
process in place, adopting a new tool, or the like. For example,
we recently considered upgrading to the latest version of Photoshop.
Will it be worth the cost? It has a bunch of cool new features that
our artists really like. How much more productive does it make them?
There's no way to measure. For situations like these, we need different
ways to tell what the right decision to make is, and I'll hit these
in future articles.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||
!
/ $
Features
|
|
|