this is false and debunked in mythical man month. It follows from "adding manpower to a late software project makes it later" that we need to add hours, not people. Or we can break our contract if we'd rather to that.
"We respect ourselves and our people enough to honor their time and their personal lives so we cannot agree to your deadline."
This also misses the point - projects start on time and end late. at the time the deadline was agreed to, we happily accepted payment.
The Mythical Man Month points out that adding manpower doesn't accelerate a project. In no way does that mean that adding hours does. They are completely unrelated ideas.
Adding manpower doesn't accelerate a project because more people doesn't immediately mean more productivity. Adding hours can only accelerate a project if more hours means more productivity. There are multiple studies that show this is false after a short period (a week or two), and that you rapidly go in the opposite direction. The mythical man month's points are irrelevant to this.
You're starting off with the base idea that there is something you can add can make a late software project more on time. Reality seems to indicate that often, a late software project will simply be late, unless you cut scope or corners mercilessly. Unless, in essence, you remove something.
"From a business point of view, long hours by programmers are a key to profitability. ..."
wrote Phil Greenspun[1], here's the rest of the quote:
"... Suppose that a programmer needs to spend 25 hours per week keeping current with new technology, getting coordinated with other programmers, contributing to documentation and thought leadership pieces, and comprehending the structures of the systems being extended. Under this assumption, a programmer who works 55 hours per week will produce twice as much code as one who works 40 hours per week. In The Mythical Man-Month, the only great book ever written on software engineering, Fred Brooks concludes that no software product should be designed by more than two people. He argues that a program designed by more than two people might be more complete but it will never be easy to understand because it will not be as consistent as something designed by fewer people. This means that if you want to follow the best practices of the industry in terms of design and architecture, the only way to improve speed to market is to have the same people working longer hours. Finally there is the common sense notion that the smaller the team the less management overhead. A product is going to get out the door much faster if it is built by 4 people working 70-hour weeks (180 productive programmer-hours per week, after subtracting for 25 hours of coordination and structure comprehension time) than if by 12 people working 40-hour weeks (the same net of 180 hours per week). The 12-person team will inevitably require additional managers and all-day meetings to stay coordinated."[1]
This is a mathematical analysis built on unstated assumptions of how long the brain can focus on something in the long term. By this line of reasoning, 4 people working 168-hour weeks would be maximally productive, but they wouldn't be sleeping, so obviously the purely mathematical argument falls down on its face.
My point is, knowing that turning dial A up doesn't help doesn't mean that turning dial B up does. It just means turning dial A up doesn't. Sometimes the reality is that turning neither dial up is the only option, and you have to plan around that fact.
In reality, there's decent evidence out there to support the statement that turning dial B up can be just as counterproductive as turning dial A up unless it's done very judiciously.
>This also misses the point - projects start on time and end late. at the time the deadline was agreed to, we happily accepted payment.
Deadlines are artificial constructs in software development, usually built up and justified using completely fictional inputs. It amazes me how many can input assumptions and guesses and then treat the output as some concrete statement of fact.
This isn't to use the too common "it'll be done when it's done, man" Dude-ism, but it is a complete cop-out to point to some initial, often agreed-to-under-duress calendar mark as the agreement to unlimited overtime. It never means that.
I remember being in an agile meeting once where everyone estimated out some features and gave them durations (span of weeks based essentially on gut feel). These were all studiously entered into the workboard, where the manager then said "okay so that is n hours assuming 6.5 hours of work a day [assuming administrative overhead, bug fixes, etc]. So now if we just put in 9 hours of work a day we'll be done by [some calendar date]". That is the nonsense that yields most "deadlines".
this is false and debunked in mythical man month. It follows from "adding manpower to a late software project makes it later" that we need to add hours, not people. Or we can break our contract if we'd rather to that.
"We respect ourselves and our people enough to honor their time and their personal lives so we cannot agree to your deadline."
This also misses the point - projects start on time and end late. at the time the deadline was agreed to, we happily accepted payment.