If an engineer says a bridge will take so long to build and cost this amount of money, we do not argue. We just decide if the benefit is worth the cost. If a good programmer gives the same estimate, we try to talk him down. We are more comfortable paying for girders which we can count than lines of code we cannot measure.
We do not pay to build a footbridge, and then decide to drive cars across it - we understand that if it was built to do a certain task, we cannot expect it to do significantly greater or different work without considerable expense, probably the cost of pulling it down and starting again. But we expect software to be stretched and extended, applied to new situations and different conditions, and cope with vastly different loads from that which it was designed for, and we expect it to work perfectly. We do not see the internal structures which make it do some things well and some things not so well. We do not see how what it was designed to do affects how well it can be applied to new and different purposes.
The cost of a piece of software is essentially non-negotiable.
We have many people doing things they are not good at and not trained to do.
We need to investigate the cost and implications of decisions before they are made - of options before they become decisions.
The devil is in the details. We need to keep a close eye on the details of what people build for us. Hands-on project management is the only way.
