The Programmer's Dilemma

Client: This program isn't working the way I need it - I need a program that will do 'X' for me

 Programmer: Okay, that's a tall order it will take some time to do.

Client: Oh, I didn't realize, how long do you think it will take?

 Programmer: Umm, depends, but I'm guessing about 3 weeks.

Client: No that simply won't work -   my reports are due next week, I need it by Monday. I'll just put another 3 programmers on it with you, that will make things 3  times faster, so you should have no problem getting it done by Monday!

Programmer: Scratches his head - muttering  "umm,  that's not going to work"

- Sound Familiar?

Their seems to be a mistaken belief (held by a fair number of people), that any project or process can be made faster simply by adding more resources to it. This is the law of outrageous oversimplification. Brooke's Law coined by Fred Brooks in 1975- Specifically

- "adding manpower to a late software project makes it later"
(Yep - people did build software back in 1975!)

To illustrate some of the problems - allow me to give you a few practical examples:

Example 1:

 You hire a painter to paint your 12x12 living room. You ask him how long the job will take. He tells you about 1 day.  You ask him what if you have 2 painters, he tells you probably 1/2 day.  So then you decide to hire 12 painters and assume the job will take only 2 hours, or perhaps hire 720 painters and assume the job will take 2 minutes?  - Does this make sense? No? - Why? - Because the resource (painter) it is quickly realized is not the constraint that is slowing things down. 720 painters would be unlikely to even fit in a 12x12 living room, and even 12 painters, who might fit, would constantly be bumping into one another's work. One painter cannot apply a second coat to the wall before the wall had dried - While the Math Works - The whole idea is ludicrous - you will end up spending a fortune and come home to a mess all over your house.

Example 2:

You are the manager of a hospital, and you are concerned about the amount of time it takes your surgeons to complete heart transplants.  The 6 hour procedure, takes 3 of your doctors, uses your only O.R. and  means you hospital can only do a maximum of 3 heart transplants a day.  So you decide to hire 9 more doctors, put them all in the same O.R. together and conclude now each heart operation should be 3 times as fast so only take about 2 hours and now you can do up to 12 heart transplants a day? - Right? Of course not. If you put 12 doctors in a room with 1 patient, the patient is probably doing to die, simply as the Doctors argue of which way to preform the procedure.  If you cram 3 patients in the room each with 3 doctors, they will probably spread who knows what diseases to one another during the operation and die of infection. Plus if you only have one set of monitoring equipment, how do you intended to share it with the 3 patients at the same time?- Again ludicrous

Example 3:

You work as the history professor of local college.  You ask one of your students how fast they can type. They proudly tell you 60 words per minute.  Great! You exclaim. I need everyone in the class to write a 1,500 word essay on the war of 1812. That should take you each about 1/2 an hour, but since different people may type at different speeds I will be generous and give you until 9AM tomorrow - plenty of time to have it on my desk - Right? -- Hogwash! - Your student might not have even know about the war of 1812, plus an essay requires draft, review, editing, proof-reading, final copy. Is the essay anything about the war of 1812, or a particular aspect that  the professor is looking for?. Even if the students drops everything else in his/her life maybe they can meet the deadline, but still get an 'F' because the professor really wanted to know the specific Canadian/US views on the war, but he didn't tell you that, and you didn't have the time to ask.

Example 4:

You work for a manufacturing plan that produces FM radio's on an assembly plant.  The plant employs 10 workers on the production line. Your job is to assembly the volume control on each completed assembly as it comes down the line. You work with 1 other person, and between the 2 of you - you are able to assembly about 4 knobs per hour, but you have a backlog of about 250 assembled units.  The box assembly down the line is assembly the boxes at about 10 boxes per hour, which is why you have the backlog.  A manager, upset at the fact that the final boxes are only coming out of the end of the system at 4 boxes per hour, decides to solve the problem by hiring 10 new employees. (Thinking this should as least double his plants throughput).  The foreman assigns each employee to a different assembly station. (ie: You now have 1 more person helping you assemble knobs). Together the 3 of you can now do 6 knobs per hour. But the manager is suddenly enraged - Why did we not double our output when I hired 10 more employees? Perhaps he tries hiring another 10 more employees, and instead of his assumed triple of production, it now only outputs 8 units per hour - See the problem ?

So why is it - that in all of these examples, we realize that it is foolish to place expectations, by using an over simplistic formula believing that the bottleneck of all problems is resourcing, and that simply adding manpower makes the project go faster?  - Perhaps it comes from the consulting industry? If you hire a company and I work as a programmer for that company, and you want me to use 10 more resources (even though it makes nothing faster). Your math error translates into a lot of wasted money for your company, and a lot of revenue for my company - think about it.

Being a programmer, is a lot like being a painter, a surgeon, a student writing essays, and a manufacturing plant employee all rolled into one. With all fairness and respect to surgeons, generally no one dies from  bugs left in the code - and this is a key difference!

My point is that with any project or process - it is very dangerous to simply assume - that the bottleneck is a specific resource. If I gather customer requirements in a series of meetings, and each of those meetings are 1 week apart (say due to the availability of everyone's calendars). Hiring 10 new programmers isn't going to solve that problem. If a programmer needs 8 hours to debug a key piece of code written 10 years ago, that no one understands how it works yet is used by the rest of the system, hiring 4 additional programmers to work on the 'rest of the system' during that same 8 hour period  adds no value, and may even make things take longer.  Testing of code simply cannot happen before the code is developed to test. Until you know specifically what constraint is slowing down 'the system', randomly adding more resources will likely only make the problem - much - much worse, and end up costing your much more money down the line.  Something to think about, the next time you wonder why 'Project 'X' is taking so long' and before you jump to any conclusions about how to solve it.