Piling programmers lead to devastating deadlines

Small red bomb Ever been in a situation where the deadline is getting closer yet the project is getting nowhere? Ever had deadlines looming closer and everyone’s attending meetings, doing discussions but nothing is really done? And the solution from management? Pile on more programmers.

This isn’t like hacking logs, where the more people who chip in to hack logs, the faster all the logs get splintered into firewood.

This isn’t like cleaning house, where the more people who sweep in to mop floors or wipe windows, the faster the house becomes brand new spanking clean.

This isn’t even like data entry, where the more people who come in to type information, the faster all the data gets into the computer database.

Programming is a thinking activity. Thinking activities call on quality, not quantity, of the people involved.

Synchronising actions is easy. Monkey see, monkey do. See log. Grab axe. Swing, splinter, repeat. See dirt. Grab broom. Sweep. Eye on data. Fingers flying on keyboard. Tappity tap, tappity tap. Synchronising thoughts is much harder.

Simply piling on more programmers doesn’t make the project progress any faster. In fact, it just leads to devastating deadlines. Why? It’s the human factor.

This reminds me of a time when I was in a team of 12 (I think). We were working on an enterprise web application (warning bells sounding), since I just joined, I was given documentation of the application framework to study. There were custom web controls, dynamic browser sizing based on user’s resolution, security logins, language resource handling, translations, workflow management class codes and on and on.

I was the new guy, so I was given all sorts of miscellaneous stuff to do while they decide how best to use me. Then I got something to work on. The resulting code wasn’t my best, but I learned a lot from the team and the experience.

Then the deadline started slipping, and management brought on 2 more programmers. While I had some professional experience to speak of, these 2 had hardly any, from what I had seen. She needed help getting a DataGrid sort and bind to work!

New staff, even if they’re experienced programmers, need time to get accustomed to the team and the project.

Me? I got relegated to testing the web application. Somewhere in my resume I stated I did test cases before, and that’s where I ended up, writing test cases. The whole application was finally coming together, and then some of the other colleagues were tasked to help with the testing.

At least management got this part right. Having me help with the coding wouldn’t have made much difference at that point. Testing the application would have smoothed the project’s progress back within deadline, while the last bits of coding were done simultaneously.

Estimating project deadlines is hard enough. Don’t introduce a new variable into the equation. New staff are new variables. And if you really want to hire new variables, make sure they’re polymath programmers.