I’d argue most people think programmers are additive. A project that would take 10 days to finish by one single programmer should take only 5 if you add a second programmer. This, unfortunately, is not the case. (See: Brooks’s Law) If this were the case, with 20 programmers you’d have that project done in half a day (with a million programmers, it would take just a fraction of a second to complete).
It’s important to remember writing code is like writing a good essay. You need an intro with a thesis, supporting arguments, and a conclusion to wrap everything up. Simply splitting up the task can be done, but the assembly of those pieces is going to be a challenge. How do you simultaneously write supporting arguments with out a thesis? Or, how would you wrap things up in the conclusion without knowing what needed to be wrapped up? Any time saved by splitting up the task is lost reassembling it. Additionally, you need to factor in more project management to keep everyone on task (a project manager that knows the technical/programming pitfalls of the project is crucial).
The problem is further compounded if the project is late or rapidly running short on time. There’s added time to get new programmers up to speed (which eats up even more time). Rushed code is rarely good code. Good code is a planned out system that uses good Object-Oriented Design which can be easily modified. UML diagrams of classes with their functions, future-proof database design, etc. Rushed code is usually, “I found this example on Stack Overflow, I think it’ll work”. This #YOLOcoding†approach is dangerous. Without fully comprehending what the code is doing, you open the application up to vulnerabilities. It also makes future extendibility/upgradability impossible (you likely will be doing a total refactor of the code if you need to add in any features later).
My point is: Late is late (not much you can do about it). Late and poorly coded is worse. Not only did you go over on hours, it’s also going to make any future additions take longer.
I think that most managers (non-technical managers) realize that it’s not purely additive yet they still think it helps. That 3 programmers can get a project done twice as fast, or maybe 5 programmers three times, as opposed to straight-up 3 programmers equals 3 times as fast. In my experience this gets frustrating because a) each hastily-added programmer is aware that they will not be outputting to their full potential (if they were working solo) and b) this is highly dependent on environment, background, and per-task management. Where this gets dangerous is when a project is behind and the manager is ‘willing’ to sacrifice the feelings of the programmers for a small potential increase in output.
You don’t blame the manager for poorly written code, you blame the programmer. The only person that should shoulder the blame or even be worried about approaching timelines is the manager. If a project is behind its the project manager’s fault for not laying out reasonable milestones, not appropriating resources at the correct times, or for not having the right people involved. More programmers will not help with poor project management.
Good topic, sir!