Still reeling at the shock of that question, it feels like time to introduce another hypothesis:
#4.2 Simplicity is Inversely Proportional to the Number of DesignersPosted by iang at January 11, 2008 02:35 PM | TrackBackNever doubt that a small group of thoughtful, committed citizens can change the world. Indeed, it is the only thing that ever has. Margaret MeadSimplicity is proportional to the inverse of the number of designers. Or is it that complexity is proportional to the square of the number of designers?
Sad but true, if you look at the classical best of breed protocols like SSH and PGP, they delivered their best work when one person designed them. Even SSL was mostly secure to begin with, and it was only the introduction of PKI with its committees, models, digital signature laws and accountants that sent it into orbit around Pluto.
Sometimes a protocol can survive a team of two, but we are taking huge risks (remember the biggest failure mode of all is failing to deliver anything). Either compromise with your co-designer quickly or kill him, your users will thank you for either. They do not benefit if you are locked in a deadly embrace over the pernickety benefits of MAC-then-encrypt over encrypt-then-MAC.
It should be clear by now that committees are totally out of the question. They are like whirlpools, great spiralling sinks of talent, so paddle as fast as possible in the other direction. On the other hand, if you are having trouble shrinking your team or agreeing with them, a committee over yonder can be useful as a face saving idea. Point them in that direction of the whirlpool, give them a nudge, and then get back to work.
.... 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.
Posted by: Lynn Wheeler at January 11, 2008 03:04 PMThe 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.
Posted by: Richard Johnson at January 21, 2008 05:44 PM