www.mixnerstrategy.com
"We're late on our software design project. What are we going to do?"
"Just add more people. More people means faster to alpha."
Ever had a conversation like that? Just throwing people at a project may not be the best solution says Fred Brooks in a now classic software design book. Brooks came out of IBM in the sixties where he managed the creation of big, main-frame software that took lots of time to create. Having seen it all, Brooks takes the time to share with us just what can go wrong on large software project - and how to avoid all the mistakes he watched happen over time. He has one basic premise. Actually, a bunch of them, but they all come back to the man-month.
Let's say management wants a computer program designed and implemented. They'll say, "Let's have it done by such-and-such date." Your job is to get the project done and the software implemented. Now, your company is like most others. It has a budget. So, wearing your best manager's hat you estimate how many hours you think the project will take. You do it pretty quickly, hand it in to the boss who approves it quickly, because, as we all know, the boss wants it done fast.
Brooks makes two points about the process just described: your estimate is always wrong because - are you listening? - you didn't plan enough for the ultimate implementation of the software (Brooks, 20). Interestingly, he says spend a third of your time planning before you even begin coding. Then, get the coding in a sixth of the time you have allocated to the project. "What?" you say. All the time should be spent on coding. Not if you want your software to work properly. You've planned it (and took a lot longer than you expected), you've coded it, and now, you want to implement it. You've forgotten half of the work, the early systems test (with the component test) and the late systems test with all the different modules in hand (Brooks, 20). They get half the work.
"OK", you're saying, "times have changed. We're making a different type of software than IBM made in the sixties." I agree with that. You've migrated to a different platform using all sorts of new bells and whistles, modifications and changes. I agree. My suspicion, however, is that Brooks has it right. Spend a third of your time planning, a sixth coding, and then, half of your time checking your work. That's Brook's first lessen.
The second one gets more interesting. When was the last time you delivered software on time? Never, right? Brooks has a formula for making up lost time. It's simple. Use the same number of - indeed, the same - coders. Extend the time. You can't do it right? It'll take too long. Well, adding more people won't save time. All you'll end up doing is messing up your time-line bringing people up to speed. The trainers are pulled from coding. The new coders never catch up (Brooks, 26). The only solution? I already told you: keep the same number of coders. Extend the time. Simple to do. Hard to sell to management.
What if you run a design firm? You have a job to do. Your firm's profitability depends on it. Estimate your project properly. Leave time for planning. Then, leave more time than you ever expected to test the result of your efforts before the code ever gets to a customer.
That's Brooks, 1982. The time has changed. The message has stayed the same.
Reference
Brooks, Frederick P. Jr. The Mythical Man-Month. Essays on Software Engineering. Addison-Wesley Publishing Company. 1982.