rss feed
blog - why people add developers to late projects
posted by witten on February 24, 2007
If you've participated in the release of a software product, and you have any amount of ability to observe events in the world and draw logical conclusions based upon them, then you should've figured out by now that adding additional developers to a late software project only makes it later. Even without the ability to form coherent thoughts or reason about cause and effect, you could've had someone read The Mythical Man-Month aloud to you as you gazed with wonder at your own navel. There is no excuse for ignoring the ramp-up time, increased communication requirements, and other costs inherent in scaling up a development effort.I once worked for a consulting company that sent me and an armada of other developers to a customer's site to work on a large software project. We plodded away for several months, ticking off the implemented features one by one. But like so many poorly planned projects, it never quite reached completion. As the project dragged on, the customer got antsy. The management at my company, in their infinite software management wisdom, decided to speed things up by adding more developers to the project.But not just any developers. They actually pulled several people off of technical support and sent them to the customer's office as developers. I'm talking about guys who answered phones for a living and hadn't written a line of code in their lives. Now don't get me wrong, these were good guys and eager to learn. But throwing them at a late project only caused the developers already working on it to waste a lot of time bringing them up to speed, not only training them on the project itself but also teaching them the fundamentals of computer programming!One day at lunch, several of the tech support guys masquerading as developers and I had gone to one of those vaguely fancy Italian restaurants with butcher paper over the table. We had also gotten our hands on some of the crayons they had available so kids can draw pictures on the table while their parents ignore them. I spent the lunch hour alternately wolfing down mouthfuls of spaghetti bolognese and writing out regular expressions in Burnt Sienna on the butcher paper table cloth, trying to teach these guys some basic programming concepts. They were smart and they asked good questions, but there was no way they were going to be anything but a huge drag on the development effort.I don't need to tell you that the project ended with complete and utter failure, with my company losing their consulting contract. Unfortunately, with the exception of technical training relying on Crayolas, this sort of experience is alarmingly common in the software industry. By now, all developers and managers should have seen this sort of trainwreck firsthand, and should know better than to try the same sort of shenanigans themselves. Even throwing experienced developers at a late project is only marginally better than adding complete noobs.So if every developer, manager, or executive who has spent more than a few consecutive minutes in the software industry should know that throwing manpower at a late project isn't a solution typically associated with hitting deadlines, then why do so many people persist in adding developers to a struggling project in the hopes of getting it done faster? Why do so may people act irrationally when it comes to late software products?The first answer is perception. Imagine you're a middle manager in a consulting company, and your customer is giving you grief about the late project they're paying you to develop. Perhaps the customer is also putting pressure on the executives above you in your own company, who are in turn putting pressure on you. You need to do something to make the project get done faster, or at least do something very visible that looks like you're serious about the problem. Suddenly, the idea dawns on you that a sudden influx of new developers scurrying about would look awfully productive. Both your executives and the antsy customer would see that you're serious about the problem and that you're doing something about it. You might even be aware of the small fact that adding additional developers is only going to delay the eventual ship date, but that won't be evident for at least a few months. Right now, with more developers to type away at keyboards, perception will improve.Another reason people add programmers to a late project is out of simple ignorance. Managers truly inexperienced with software projects, such as those originally from other industries, often discount the communication and scaling problems inherent to growing software teams. But inexperience can also come from those who actually have read the relevant literature on the subject, but simply haven't internalized it.One of my friends used to work for a large, well-known software company where his team would regularly be assigned books to read on the topic of software development. It was almost like a book club. Everyone from the development managers on down to the newest coders would be expected to read the same book about best practices in large-scale software projects, and then they would hold a meeting during work hours specifically to discuss the concepts in the book. When the meeting was over, everyone would walk out of the room and promptly forget all the lessons learned, continuing to make all the same mistakes they had been making all along.During your everyday software development, it takes conscious effort to apply the lessons you've learned, whether they're from books or hard-earned experience in the trenches. For many people, it simply requires less initial thought and effort to lapse into reactionary fire-fighting mode instead of preventing fires to begin with. Even if the fire-fighting involves dousing things with gasoline.Finally, a major reason why people add developers to a late project is to stave off a feeling of powerlessness. Imagine you're that manager again, presiding over a late project. All questions of perception aside, if a project is running late, you might feel that you need to pull some sort of proverbial lever, any lever, to exert an effect on the project and nudge it in the desired direction. You don't want to stand idly by without taking some sort of action, because doing so would leave you feeling powerless. So you pull one of the only levers within reach, the "add developers" lever. Of course, adding programmers will actively harm the already late project, but hey, at least you're doing something.The right levers to pull on a software project to make it successful come near the beginning of development. For starters, you can try the "requirements gathering" lever. It's also not a bad idea to give "design and planning" a tug. But when a project is late, and you're feeling powerless, what levers can you pull that will actually improve matters? Two big ones are "cutting features" and "realigning the schedule with reality" (a.k.a. "slipping the release date"). If you don't have enough time to get all of the features implemented that you've promised, reducing the scope and cutting some features can get the project done sooner.And as unpleasant as it may be, it's often easier to sit down with the customer and renegotiate a new release date that you can actually stick to, rather than going through the charade of adding manpower and hoping that, this time, the laws of physics won't apply.