Jim Highsmith also hinted at this in his workshop at AYE on team decision making. He gave the example of toyota, where, when developing a car, several car bodies, transmissions engines etcetera are developed. Measurements etc. are taken and discussed with tool-makers, assembly workers, so that when it is time to produce the actual car, there is always a choice of components. When there is a problem with a certain component, it can easily be exchanged.

Interestingly enough, while checking out Dave Thomas’s blog today, I found a related note, "mechanism versus policy" . One size does not fit all, he says when discussing user interface implementations. For expert users, NakedObjects (where users can manipulate objects in the application domain more or less directly through a very thin GUI) might be an excellent solution, since they are free to manipulate everything, while for novices or casual users, a wizard-driven interface is more suitable. Why then, not wrap your NakedObjects in a wizard, and offer the choice which to use to the user?

I have the same feeling about editing web-sites through browsers. As a power-user, I prefer to work with files and be able to do batch modifications with scripts and tools like secure shell. For casual users, the previous sentence might contain 4 strange words (‘batch’, ‘scripts’, ‘tools’, ‘secure shell’), so they’d think, ‘what the …’ is he talking about? The other way around, I feel constrained when having to upload 100 jpeg files one-by-one through an upload dialog - an experience I had when trying to get some digital photos printed recently.

I’ve been walking around with this idea for some time, at least with the frustration of working on one solution (e.g. in this rant), but expressing it to others is much easier now I have a term (Set Based Development) to describe the alternative.

References:

Toyota’s principles of set-based concurrent engineering (text only link )from Sloan Management Review, Winter, 1999, by Durward K. Sobek, II, Allen C. Ward, Jeffrey K. Liker