The idea is not to convince the client to render a full specification, but to encourage them to understand--through the expedient of having them consider how much work would be involved in doing so--that giving absolute answers to "how long/how much" question regarding program development, especially in terms of physical metrics, is nearly impossible.
Milestones are a better metric except that non-developers have a habit of coming up with equations like of 20 milestones, the first 4 were completed in 5 weeks at a cost of X thousand currency units, so the project will take 25 weeks and cost 5X thousand currency units. The budget for the project was only 3 thousand currency units and the projected timescale was 4 months, therefore the project will run wildly over time and budget and we should consider cancelling it now.
The developer(s) then spend most of the next 4 weeks in meetings trying to disprove the math and justify why the project is not behind schedule, by which time it is.
If you can turn the onus for precision back on the specification, then you can 'relent' in favour of a compromise that satisfies both parties and perhaps achieve a good working relationship that doesn't fracture on the basis of "You only completed 100 LOC this week!".
Examine what is said, not who speaks.
"Efficiency is intelligent laziness." -David Dunham
"When I'm working on a problem, I never think about beauty. I think only how to solve the problem. But when I have finished, if the solution is not beautiful, I know it is wrong." -Richard Buckminster Fuller
If I understand your problem, I can solve it! Of course, the same can be said for you.
| [reply] |
I think I agree - this is a kind of End-To-End Argument, just substitute abiguity in the place of transmision erros. By the way I think there should be some more abstract formulation of the argument.
| [reply] |