getting it right the first time is the wrong goal
the best software is a well-designed clone of something that grew organically.
a clone or rewrite, an unburdened implementation.
you can't design like that the first time, because you don't know what you'll
need next week.
you don't know what your needs are yet. you can only try your
best to be generic and flexible, but you will make mistakes and you will have
to do bad things to force your code to do something you weren't able to predict.
it's like how you can't guess the abstraction until you have a few
implementations you can learn the general case from. you can't design something
before you know what it needs to do.
in the past we had long periods before the typing began when we would research
and try things and soften the fabric so we had a good idea of what we'd need to
type. but that time seems increasingly hard to budget for, and it is difficult
to explain to your manager that the week's budget you've just spent has
produced nothing but has given you a good idea of what to do next.
research does not seem to be considered a first class part of the development
artists do sketches to find the weak in their ideas, to work through problems
before they commit hours and oils to the final piece when stumbling would be
costly and difficult to recover from.
writers write first drafts to get the ideas out, they rewrite and rewrite until
it's ready for publication.
a programmer should be creating a first draft, refactoring and rewriting before
ready for production.
getting it right the first time is an unachievable goal, and an obstacle to the primary goal: getting it right