Friday, February 8, 2008

Hidden Parameters of Software Design

Have you ever thought the printer paper that u use and the shoe brand your neighbour wears have any influence on software that you design ? If i say yes ,then I am sure every one will say me mad. It seems to be stupid idea how could my neighbour shoe have effect on softwares I design ?But the fact is there are subtle things which can affect the software you design.

A man named Mel Conway have stated a law about the most hidden influential parameter of software design

Any organization that designs a system will produce a design whose structure is a copy of the organization's communication structure.


In other way

Software is doomed to reflect structure of the organization that produces it.


How could communication and organisation structure affect the software design? This seems to be a joke... Really ? No not at all..

Here's description

Consider a large system S that the government wants to build. The government hires company X to build system S. Say company X has three engineering groups, E1, E2, and E3 that participate in the project. Conway's law suggests that it is likely that the resultant system will consist of 3 major subsystems (S1, S2, S3), each built by one of the engineering groups. More importantly, the resultant interfaces between the subsystems (S1-S2, S1-S3, etc) will reflect the quality and nature of the real-world interpersonal communications between the respective engineering groups (E1-E2, E1-E3, etc).

Another example: Consider a two-person team of software engineers, A and B. Say A designs and codes a software class X. Later, the team discovers that class X needs some new features. If A adds the features, A is likely to simply expand X to include the new features. If B adds the new features, B may be afraid of breaking X, and so instead will create a new derived class X2 that inherits X's features, and puts the new features in X2. So, in this example, the final design is a reflection of who implemented the functionality.

A real life example: NASA's Mars Climate Orbiter crashed because one team used English units (e.g., inches, feet and pounds) while the other used metric units for a key spacecraft operation. This information was critical to the maneuvers required to place the spacecraft in the proper Mars orbit. "People sometimes make errors," said Dr. Edward Weiler, NASA's Associate Administrator for Space Science. "The problem here was not the error, it was the failure of NASA's systems engineering, and the checks and balances in our processes to detect the error. That's why we lost the spacecraft."

What a basic error..! Hence the proof of Conway's law...

I think this why the Googles have great design in their software they make ... It reflects the organisation structure .. Its reflects the communication they have.


Another Conways law
In every organization there is one person who knows exactly what is going on at all times. This person must be fired.


One more law
If a group of N persons implements a COBOL compiler, there will be N-1 passes. Someone in the group has to be the manager.


This seems to be funny but you know this is quiet true..

So when u design Dont have a Y guy who only knows how to do X thing and considered to be the blocker of the project in case he s absence . Have a collective ownership of what every one do It keeps the team unblocked, and gives everyone the opportunity to do more than one thing (Agile ) more importantly makes every one interesting.

Atmost communication between the team is important. keep improving the communication inside the team..!

1 comment:

Peerlessdeepak said...

Thats true!! Imagine a project where we dont even know the size of RAM while coding...!