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 process.

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