Joel Spolsky explains Five Easy Ways to Fail when managing a big software project:
Mistake No. 1: Start with a mediocre team of developers.
Designing software is hard, and unfortunately, a lot of the people who call themselves programmers can’t really do it. But even though a bad team of developers tends to be the No. 1 cause of software project failures, you’d never know it from reading official postmortems. In all fields, from software to logistics to customer service, people are too nice to talk about their co-workers’ lack of competence. You’ll never hear anyone say “the team was just not smart enough or talented enough to pull this off.” Why hurt their feelings? The simple fact is that if the people on a given project team aren’t very good at what they do, they’re going to come into work every day and yet — behold! — the software won’t get created. And don’t worry too much about HR standing in your way of hiring a bunch of duds. In most cases, I assure you they will do nothing to prevent you from hiring untalented people.Mistake No. 2: Set weekly milestones.
Say you’re remodeling your kitchen. That guy you hired to do the work has done a lot of kitchens before, and can estimate the cost of the job without having detailed blueprints. But software developers are building things that they’ve never built before. If they had, they’d just sell you another copy of the CD-ROM. So rough estimates are impossible. They need to draw up detailed plans before they start writing code. Whether you’re the customer or the developers’ manager, your job is to make sure they come up with that blueprint. When you ask developers for one, however, many of them will respond by creating a schedule that breaks pieces of the process into weeks. This may seem perfectly reasonable, but it’s not. If you let a software team submit a schedule with big chunky estimates of time (by big I mean more than two days of work), you can be almost certain that they’re not considering every detail that needs to be implemented, and those details will add up to a huge delay.Mistake No. 3: Negotiate the deadline.
What’s worse than accepting a schedule that breaks down a software project by the week? Demanding that a team commit to completing its work much sooner than forecast. In my experience, most developers are optimists and will take your cue and engage in split-the-difference bargaining. You’ll have a nice, agreed-upon schedule that you’ll never stick to.Think of it in these terms: Mama walruses deliver their calves at the end of a 15- to 16-month pregnancy. You might ask the mother to commit to 15 months and she might say, “No problem!” Or you might say, “Fifteen months? Are you crazy? We need this in eight months!” Of course, haggling like this can’t possibly make things happen any faster, and even if you get the walrus to agree to an eight-month timetable, I’ll let you in on a little secret: It’ll never happen. You can have a schedule that says 11 months, but you’ll still ship in 15 months, because that is how long it takes to make a baby walrus. Sixteen, sometimes.
Mistake No. 4: Divide tasks equitably.
Here’s a great way to torpedo any project. Make a list of all the work people have to do, and then reassign things to different people to balance the project. If Mary has too much work, give some of her tasks to John. This sounds completely sensible, so you won’t be challenged.But I promise you, in the long run it’s sure to cause problems. That’s because when one developer steps in to replace another, it’s reasonable to assume that the new one will work at about one-tenth the speed. John’s going to have to spend untold hours figuring out all the things that Mary already knows about her area of code. And John can’t fix Mary’s bugs as fast as Mary can because Mary knows where all the hidden traps are.
Mistake No. 5: Work till midnight.
Let’s say a project should take six months at 40 hours a week to complete. If you told everybody to work 60 hours a week, you could finish the development in four months flat. The software team might even embrace this challenge because it will make them look like heroes (“How great is that Walrus team? They’re here every weekend!”). This should work, right? Guess again. There’s a whole body of literature establishing that working more hours doesn’t produce software any faster. Edward Yourdon, the software entrepreneur and author, dubbed this kind of project the “death march.”Software development takes immense intellectual effort. Even the best programmers can rarely sustain that level of effort for more than a few hours a day. Beyond that, they need to rest their brains a bit, which is why they always seem to be surfing the Internet or playing games when you barge in on them.
Compelling them to spend even more hours sitting in front of a computer won’t really translate into more output–or if it does, it will be the wrong kind of output. When their brains are completely fried, software developers are almost certainly going to do more damage than good, writing unusable code and introducing bugs galore. And if you do ban the Internet and multiplayer games to force them to keep writing code past their natural bedtimes, well, they’ll probably start quitting on you. Running a death march is not the only way to make a project late and a budget buster. But it is a surefire way to do so.