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

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.
MT::App::Comments=HASH(0x55aa87757648) Subroutine MT::Blog::SUPER::site_url redefined at /home/iang/www/fc/cgi-bin/mt/lib/MT/Object.pm line 125.