Only a fool would build a building, show it to the customer and say, “is this what you want?”
Most of us on this site can list several important differences between a building and a piece of software. For example, if you want to turn your nice one-bedroom cottage into a 318-unit apartment building, you're going to have to dig a slightly larger hole and wait for a few more yards of rebar-reinforced cement to dry.
Software tends to have fewer physical restraints. That's one reason we don't call it hardware.
In the business that I ran for 15 years, we made fixed price, time-definite task-contracts on everything.
I suppose if your definition was merely "Delivered what the customer used to want on time and on budget" then you deserve congratulations. Me, I stopped arguing with customers that they still had to pay me to get what they didn't want anymore several years ago.
Unless I build a system that's exactly like several systems I've built before (in which case there's something wrong with my development process), I don't believe in trying to predict the future and suffering the inevitable consequences of occasionally being wrong.
"On-time and on-budget" only impresses me if the results deliver working, useful, usable business value to the customer.
In reply to Re^7: "Practices and Principles" to death
by chromatic
in thread "Practices and Principles" to death
by ack
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |