.... I had given a talk on assurance and the aads chip strawman
http://www.garlic.com/~lynn/x959.html#aads

in trusted computing track at intel developer's forum a few years ago. during the talk, I happen to quip that it was interesting to note that over the previous couple years, the TPM design had started to look more and more like the aads chip strawman. person running the effort was in the front row and quiped back that I didn't have a committee of 200 hundred people helping me with the design.

The principle #4.2 is in general a good guide, with well-known exceptions (law-making, for example). But, even when it may apply, how about feedback, criticism, peer review? They have not evaporated. They are possibly better done before and after the design phase.

To really Keep It Simple, in the design phase it is thus better not to have to argue about it except with yourself. So the "KIS principle" really shines when you get rid of that extra pesky "S" that some like to add to it, and which is unnecessary.

After the design phase, it is often the case that the best comments come not from experts, but from ...users.

Conventional development, on the other hand, operates under the principle that we get some experts, they do the filtering, and then we look at their conclusions. Conventional development also operates under the principle that control over development is more important than the users' needs.

Conventional development is a lot about authority that people trust.

While we can still use conventional development as a tool, we also want development to be able to shape and enable the way business is done and communicated in the 21st century.

We see the liberation of often previously inaccessible corporate information to general discoverability, consumption, and reuse using both Web- and desktop-based models. We see a consumerization of enterprise users, who want to liberate their work from their IT departments, while enterprises want to reduce the training and support that employees need before they can effectively use the technology. We see that enterprises increasingly need to include partners and consumers in many ways that are not foreseeable by a development team.

Broadly framed, both in the enterprise and enterprise-consumer markets, business is changing from an authority that is ‘theirs’, to the remaking of knowledge and authority that is controlled by the user. Users, enterprise or consumers, often need and would like to ‘roll-their-own’. Enterprises, however, need to balance this need with the increasing regulatory and business needs to control who has access to particular levels of information and databases.

How about security?

Simplicity is good for security and usability. Which is a counter-example to the conventional wisdom that security and usability are antinomies -- somehow, mutual incompatible.

So, having a small (even one-person) design team makes a lot of sense for several reasons -- provided, however, that the design phase is preceded and followed by ample discussion that should include both users and experts.

That's a very useful metaphor, the whirlpool. To get out of a committee whirlpool before it sucks you down to your shared doom, it's actually more effective to swim across the current.