Designing for the future

I think I finally found the words for why I don’t design for “90%” of the use cases. It’s because doing so is designing for the past, while my creations will be used in the future, which I see as unboundedly creative. Moreover, the claim that “user’s won’t want to X” turns into a self-fulfilling prophecy.

One Comment

  1. conal:

    A reader asked:

    Then what do you design for? 95%? 99%? […]

    Even 100% would not satisfy my goal of supporting creativity. I don’t design for preconceived use cases. I design a coherent world that captures the uses I can think of while being a simple/general as possible. (I measure simplicity in a particular way, by describing a precise math model.) The anticipated uses serve to give me hints about that world, rather than defining it.

    If a design meets my expected uses and is very simple, then I’m confident about it handing my unanticipated needs as well. If it uses complexity (special cases) to address my expected uses, then I expect it will need more complexity thrown in to handle unexpected uses.

    As Tony Hoare said in his Turing Award lecture,

    I conclude that there are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is make it so complicated that there are no obvious deficiencies.

Leave a comment

You can use (extended) Markdown syntax. The default code style is Haskell.