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.