December 07, 2009

H4.3 - Simplicity is Inversely Proportional to the Number of Designers

Which reminds me to push out yet another outrageous chapter in secure protocol design. In my hypothesis #4 on Protocol Design, I claim this:

#4.3 Simplicity is Inversely Proportional to the Number of Designers
Never doubt that a small group of thoughtful, committed citizens can change the world. Indeed, it is the only thing that ever has.
Margaret Mead

Simplicity 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 classic best of breed protocols like SSH and PGP, they delivered their best results when one person designed them. Even SSL was mostly secure to begin with, and it was only the introduction of PKI with its committees, world-scale identity models, digital signature laws, accountants and lawyers that sent it into orbit around Pluto. Committee-designed monsters such as IPSec and DNSSEC aren't even in the running.

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 choice, they do not benefit if you are locked in a deadly embrace over the sublime but pernickety benefits of MAC-then-encrypt over encrypt-then-MAC, or CBC versus Counter-mode, or or or...

More at hypotheses on Secure Protocol Design.

Posted by iang at December 7, 2009 09:04 AM | TrackBack
Comments

Iang,

"Simplicity is Inversely Proportional to the Number of Designers"

No sorry you are working backwards from effect to cause which is not always a sound thing to do.

There is a recognised engineering process for dealing with (the inverse of simplicity) complexity, and it works for tangable objects that "engineers" make that you see all around you.

It is one of the reasons I hate the term "software engineer" they are code cutters / artisans / artists not engineers often with a Van Gogh outlook.

Their chosen design method has much in common with early steam boilers constructed by Victorian Artisans which is "if it breaks bolt a bit on".

This produces heavy ineficient designs that waste resources to no good effect, in fact usually the opposit.

The Victorian Artisans became Engineers when they started following fundemental design based on "reason" not "art".

One of the problems with working with an intangable like software is that it is "information" and is not subject to the physical constraints of the tangable world.

This means that they can as artists "over paint" or as artisans "bolt on" more and more to fix their ill begotan design without suffering the issues and limitations of the physical world where bridge decks "fly wryther and die" in strong winds.

If software designers could see their creations in a "physical" representation most large systems would resemble a melted gothic horror so vile and repugnant that it would turn the most hardend stomachs...

As normal the usual disclaimer,

'This is my view as a "Safety / secure systems and communications design engineer" and occasional software developer for extream resource limited systems (Embedded RTOS etc).'

Posted by: Clive Robinson at December 10, 2009 07:35 PM

I believe this observation already was made by Frederick Brooks in his legendary "The Mythical Man-month":

Conceptual Integrity
To make a user-friendly system, the system must have conceptual integrity, which can only be achieved by separating architecture from implementation. A single chief architect (or a small number of architects), acting on the user's behalf, decides what goes in the system and what stays out. The architect or team of architects should develop an idea of what the system should do and make sure this vision is understood by the rest of the team. A novel idea by someone may not be included if it does not fit seamlessly with the overall system design. In fact, to ensure a user-friendly system, a system may deliberately provide fewer features than it is capable of. The point is that if a system is too complicated to use, then many of its features will go unused because no one has the time to learn how to use them.

(summary quoted from the wikipedia)

Posted by: Twan at December 11, 2009 03:45 AM

@ Iang,

Hmm, but which version grips you and keeps you awake?

And thus stays where it should 8)

Posted by: Clive Robinson at December 12, 2009 04:51 PM
Post a comment









Remember personal info?






Hit preview to see your comment as it would be displayed.