Tool Patterns

One of the things that's missing so far (or, at least, so far as I know) is a strong distinction between types of software.

  -- These may be the same as or isomorphic to SystemMetaphor's -- Kent Beck

Not at the level of Word-Processor versus Spreadsheet versus Database-n-Forms.

But, more at the level of "intended audience." Or, perhaps, "intended use."

There are certain tasks that are well-defined right from the start. You know what you have to do and software which is somewhat rigidly constrained and forces you to make all the decisions up front is fine.

There are other tasks where the outcome is uncertain. You're not sure what you're going to produce (more precisely, how what you're going to produce works), or what the essential points are.

This distinction leads to different types of software (based on different use patterns). Examples:

     Category 1 Software:Income Tax Software
     Category 2 Task: Developer Tools 

I think that, in the world of the future, all software will eventually be designed to handle tasks in category (2) (all tasks start out in category (2). Part of the job a good software package will do is, when a task has evolved into a category (1) task, is generate scripts for it).

And, thinking about software this way leads to emphasizing certain design principles.

For example: AllowForBootStrapping

WilliamGrosso