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.