The title of this post comes from a story out of IBM back in the early 1980s. Apparently some executive in a meeting asked about delivery of some feature in the software package he was managing and was told it was a man-year's development effort. "No problem", he replied, "put 720 programmers on it and have it ready by noon."
This is, unfortunately, an attitude many non-technical people have about development processes. (This isn't just in computer-related subjects, of course, but many disciplines.) There's the general attitude that work can be parcelled out easily, tackled in parallel, assembled into a whole, and everything magically works out. Obviously, this ignores so many issues I could write a book about it, but suffice it to say it demonstrates a lack of understand of software design and development.
A corollary of this issue is the "throw more developers at it" syndrome. If four developers can solve four work tickets in a week, the obviously eight developers can double the number of work tickets in a week, right? Naturally, there's no consideration for the complexity of the work tickets, knowledge of the code base, ramp up time, and a host of other complicating factors. More is not always better, and given the choice of one developer on a project for four weeks or four developers for one week, I'll take the former in almost all cases (unless parallel development truly is possible, which is rare). Again, things are not linear: one developer taking eight weeks does not mean two developers will take four weeks (more likely, two will take six weeks). Conveying this information to non-technical people is difficult.
To be fair, technical managers are not helping. In many cases, I'll get asked in a management meeting how long a feature takes to develop. I'll say something like "about two weeks", which the non-technical assume means it will be ready in two weeks, instead of that's the amount of time it would take once we start. This disconnect between effort and delivery is a major issue, and comes from a lack of understanding on both sides. When I hear "how long does it take to develop" I hear "how long does it take to code and test this, given nothing else in the way" whereas they usually mean "when can we have it".
The final point here is the complexity issue. The number of times I've had a discussion with a non-technical person who says "it's only a single line of code that needs changing, so that's about 1 minute's work" is huge. They don't understand that identifying the problem, isolating the one line, and testing the result is hundreds of times more time-consuming than actually fixing the one line of code.
There is no solution. This problem has existed for the last 50 years and will continue to exist as long as non-technical people try to understand and manage technical people. That doesn't mean non-technical people are not going to be great managers. That's very often the case. It's simply a statement that those technical people who del deal with non-technical people need to be more careful in how information is conveyed.
And I promise to stop saying "it's only a few days work...". Or at least I will try.