Saturday, February 19, 2011

The Laws of Software Engineering; or the Lack Thereof

The first law of software engineering is that there are no laws of software engineering, at least, yet! As the recently deceased software engineering pioneer Watt S. Humphrey had so succinctly said, “Physicists and engineers make approximations to simplify their work. These approximations are based on known physical laws and verified engineering principles. The software engineer has no Kirchoff’s law or Ohm’s law and no grand concepts like Newtonian mechanics or the theory of relativity”.

Where would the laws of software – when we do discover them – be placed in the pantheon of factors that influence software development? Booch has identified the following levels in the limits of software: influence of politics, impact of economics, importance of organizations, problems of functionality, problems of design, difficulty of distribution, challenges of algorithms, laws of software, and laws of physics.

When we compare the state of the art in software engineering, vis-à-vis other engineering disciplines the following lines of divergence can be noted:

Predictable outcomes – Engineers are focused on ensuring there is lowest possible surprise in the production process so that its outcome can be accurately predicted. On the other hand, software engineers reared in the art of programming and/or computer science research often regard surprises and unpredictability of outcome as key motivators for software development.

Design metrics – Software engineers do not have corresponding metrics for allowable stresses, tolerances, performance ranges, structural complexity, failure probabilities, etc. These are routinely used in other engineering disciplines. Commonly used retrospective measures of software, such as lines of code or performance ranges, may present an oversimplified view of the problem domain.

Failure tolerance – The fundamental aim of any engineering effort is to prevent failure; and when it unfortunately occurs, to learn from it. Software systems fail often and sometimes spectacularly. Yet software engineers do not have an established framework to document and share the lessons from such failures.

Separation of design from implementation – In other engineering disciplines, designers design and handover the ‘blueprints’ to the construction specialists. Software design and implementation together are too closely tied conceptually to enable such a separation. The same software engineer usually has to do both, often simultaneously.

It is wondrous and a little confusing how software engineers manage to create systems of such complexity and criticality in spite of such divergences and without an established set of basic ideas and first principles (enshrined as laws) to fall back upon.

But then, wondrous yes, but confusing, may be not, as structures of immense grandeur and longevity have been built when humans had no inkling of the laws that underpinned such feats of engineering. The pyramids of Egypt are just one example.

16 comments:

Aditya Sriram M said...

Hello Sir,

I have a question.

I was always under the impression that science comes first, then the art!! I have mentioned the same in one of my post.
And you proved me wrong in the class – Art first and then Science.

I was thinking from the point of Soft Engineers who have to follow some SE guidelines/processes/rules to ensure success with minimal damage to the project. Now this is science in place and it’s the employees who follow it. As long as one follows them mechanically, it is just a science. Only when (s)he *realizes* that this is something more than just a process, it becomes an art in his blood. This way I thought Science first and then art and posted “until we make SE an art by understanding why we do things, SE is a complex and tough subject”.

The way you told us also seems quite convincing from the other end. One particular being first does a lot of work by his own nature and *sees* that it has a huge potential and starts marketing or sharing the art to others in some English sentences (can be an algorithm, design etc). This now becomes science.

Finally now, I believe that it is both combined.
It is art - science – art in essence as shown below.

Picture to Describe the above

Subhajit Datta said...

A very insightful comment! One wonders whether we can have a science-art-science progression of a discipline also, in some situations.

Pradnya Gaonkar said...

All said and done, we can understand that efforts in software engineering are being done towards improving designs and methodologies so as to bring about greater developments in the field. But someone has hardly thought of laws and their implementations in SE.
Quite right!..When the modern software and its behavior has ‘changed’ tremendously from its older versions and when we are certain about the ‘changes’ in future , restricting the software by laws seems unimportant. Laws define something that can be proven with facts always which is not the case in SE..
As already pointed out..the change gives birth to the new and kills the old here in SE...
Also , in my opinion ...we are able to see all these newer developments in SE due to the fact that there aren’t any laws in SE yet...How can we expect customers , developers and others to analyze and design based on laws in spite of knowing that the system is so dynamic and that the laws would not hold true always. Unpredictability forces minds to work , take chances and risks, collaborate and invent...

Pradnya Gaonkar said...

All said and done, we can understand that efforts in software engineering are being done towards improving designs and methodologies so as to bring about greater developments in the field. But someone has hardly thought of laws and their implementations in SE.
Quite right!..When the modern software and its behavior has ‘changed’ tremendously from its older versions and when we are certain about the ‘changes’ in future , restricting the software by laws seems unimportant. Laws define something that can be proven with facts which is not the case with SE...
As already pointed out..the change gives birth to the new and kills the old here in SE...
Also , in my opinion ...we are able to see all these newer developments in SE due to the fact that there aren’t any laws in SE yet...How can we expect customers , developers and others to analyze and design based on laws in spite of knowing that the system is dynamic and that the laws would not hold true always. Unpredictability forces minds to work , take chances and risks, collaborate and invent...

Unknown said...

As change is inevitable,i think we should restrain ourselves from applying strict principles to the way the code is written.Good design comes from a innovative mind which would be productive only if it is free from the fetters of rules and regulations.

Obviously some amount of methodologies are necessary.Like documentation,commenting of the software should be there so that the software is productive to the coming generations as well.But the innovative factor should be kept open in the software so as to allow young minds to express their thoughts.Author rightly mentiones that unpredictablity is the driving force in the development of the software.If we keep ourselves bounded on thoughts then our software cannot evolve,thus stagnating the growth of our skills.Today a layman with a little knowledge of computers can contribute to the world of software thus we see that a university pass out student with a masters degree does not have to be necessarily a pioneer in development of software.Ideas and thoughts flow in software from every possible surrounding and is not restricted like other engineering fields.

Need for a change is what i think drives software development.As change and principles generally have a love hate relationship.To allow change we have to let the young minds of our developers free from the cumbersome task of worrying what the outcome would be,though techical aspects are necessary but what this young enginnering field needs is evolution and that too at a rapid pace.

BHARAT GOEL(MT2010023) said...

As change is inevitable,i think we should restrain ourselves from applying strict principles to the way the code is written.Good design comes from a innovative mind which would be productive only if it is free from the fetters of rules and regulations.

Obviously some amount of methodologies are necessary.Like documentation,commenting of the software should be there so that the software is productive to the coming generations as well.But the innovative factor should be kept open in the software so as to allow young minds to express their thoughts.Author rightly mentiones that unpredictablity is the driving force in the development of the software.If we keep ourselves bounded on thoughts then our software cannot evolve,thus stagnating the growth of our skills.Today a layman with a little knowledge of computers can contribute to the world of software thus we see that a university pass out student with a masters degree does not have to be necessarily a pioneer in development of software.Ideas and thoughts flow in software from every possible surrounding and is not restricted like other engineering fields.

Need for a change is what i think drives software development.As change and principles generally have a love hate relationship.To allow change we have to let the young minds of our developers free from the cumbersome task of worrying what the outcome would be,though techical aspects are necessary but what this young enginnering field needs is evolution and that too at a rapid pace.

BHARAT GOEL(MT2010023) said...

As change is inevitable,i think we should restrain ourselves from applying strict principles to the way the code is written.Good design comes from a innovative mind which would be productive only if it is free from the fetters of rules and regulations.

Obviously some amount of methodologies are necessary.Like documentation,commenting of the software should be there so that the software is productive to the coming generations as well.But the innovative factor should be kept open in the software so as to allow young minds to express their thoughts.Author rightly mentiones that unpredictablity is the driving force in the development of the software.If we keep ourselves bounded on thoughts then our software cannot evolve,thus stagnating the growth of our skills.Today a layman with a little knowledge of computers can contribute to the world of software thus we see that a university pass out student with a masters degree does not have to be necessarily a pioneer in development of software.Ideas and thoughts flow in software from every possible surrounding and is not restricted like other engineering fields.

Need for a change is what i think drives software development.As change and principles generally have a love hate relationship.To allow change we have to let the young minds of our developers free from the cumbersome task of worrying what the outcome would be,though techical aspects are necessary but what this young enginnering field needs is evolution and that too at a rapid pace.

Unknown said...

Hello sir,
I think laws for SE is not there yet because laws are for something which is definite. But SE is a stream in which "Change" is the only thing which is definite.
Another thing could be the lack of standardization among different vendors. To survive in the market vendors come up with different ideas, then other and so on. So there is no baseground for all. But in other fields of engineering they have same standards to be followed by all like, say to build a bridge this should be the ratio of concrete with water or something like that.

Unknown said...

Hello sir,
I think laws for SE is not there yet because laws are for something which is definite. But SE is a stream in which "Change" is the only thing which is definite.
Another thing could be the lack of standardization among different vendors. To survive in the market vendors come up with different ideas, then other and so on. So there is no baseground for all. But in other fields of engineering they have same standards to be followed by all like, say to build a bridge this should be the ratio of concrete with water or something like that.

Shreya Barsaiyan said...

MT2010138(Shreya Barsaiyan)

I agree to the fact that there are no rules in software engineering, but certainly software engg. provides guidelines to the aspirants of software development field. The guidelines may be simple enough like modularization of complex problem or a really huge process model.
In fact Software Development Life Cycles are examples of protocols followed by the Software Engineers. Engineering can not always be defined within laws, some times it has to be defined or illustrated as the standards followed. Although there is no measure to accuracy or no strict estimation techniques yet the s/w development firms are graded with CMM levels.

A few SE guidelines could be :
Modularization
Data Typing, Declarations, Variables, and other Objects
Naming convention
Abbreviations
Principles of software design(Object Oriented Design etc)

I could not agree more to the fact that before even knowing laws the human society has successfully built huge and flawless systems. These flawless systems were not built or designed as a one day effort or one time effort, this unique ability of human mind to learn through experiences made things possible.There were a lot of failures and experimentation and then a success was achieved. All I can say is Software Engineering is in its EXPERIMENTATION phase now, may be years later as a result of experiences through present we may discover Software Engineering SET of laws.

Skanda Kumar (MT2010143) said...

Software Engineering is more often referred to as an Art than Science, and as all other forms of Art it is not expected have laws that precisely describe the domain. Software these days is coming more closer to human life than it was ever before, as a result of which it gets all the unpredictable components of the human society attached to it making it more difficult to be described by concrete laws.

Philip Joseph said...

Software Engineering is having a history of around 40 years. This by itself is too small a time period to analysis its class as comapared to various banches of science and technology. The branch of physics originated during 500BC to 380BC. Aristotle and Plato observed physical phenomena as a way to discover natural laws guiding the universe. But it took centuries for that branch to come up with some formal definitions and laws. Only in the 17th century Newton came up with the laws of gravity. Observing these facts, software engineering is still in its infancy and we could hope that as time progresses, there will be laws defined for each process. We could hope that in the future there will be a time when design and implementation are two independent process, each governed by its own sets of rules. As stated in history, a falling apple made Newton to think and invent laws of gravity; some day an Apple, a Gingerbread or HoneyComb could guide some brain to formulate laws of software engineering too!!

MT2010101

Abhinandan said...

One of the *spectacular* failures of software and the credit of preventing a very horrible aftershock due to it should be attributed to Lt.Col Stanislav Petrov.
More software failures at http://www.devtopics.com/20-famous-software-disasters/

gaurav kaushik said...

Gaurav Kaushik
MT2010043

Good Evening,
yes Absolutely there are no laws in software engineering.But still software engineering is quite successful and even play a significant role in the development of other engineering fields like electrical,electronics,mechanical,etc.Software engineering makes other engineering fields work faster and easier by giving quick analysis,design of models etc.....actually what i think that there can never be a fixed law in software engineering like laws of nature(laws of motion)etc it is because software engg. does not deal with fixed challenges, changes and complexity.There is very very large domain of different varieties of problems and challenges in software engg.So it has to modulate or acclimatize itself according to problem for getting solution in best possible and faster manner.This is because sometime there is possibility to meet the need of some company(client) very fast.so here time constraint is highly taken into account,Like if some client need a text editor urgently in couple of weeks so company will provide him this with simple writing , deleting,adjusting size and little bit formatting functionality to meet his need with in the very limited time and enhance functionality in later stages.But if client doesnot require it very immediately and he gives 2-3 months then here time is not constraint then SW engg. can provide the client with very high functionality with spelling grammer check,custom pictures and world art facilities etc.So at last we can say that there can not be a fixed law in SW Engg.It depends upon the problem and adopting excellent way to solve in proper manner.Some Requirements of organisation is that o/p should come in very short time there software engg. will use most efficient algorithm to get o/p as fastest as possible even though it may require large amount of memory.some requirements of organisation is less amount of memory program there SW engg. may use such algorithms which require less memory but can take comparatively large time to get o/p.
thanx

Gaurav Kaushik said...

Good Evening
yes Absolutely there are no laws in software engineering.But still software engineering is quite successful and even play a significant role in the development of other engineering fields like electrical,electronics,mechanical,etc.Software engineering makes other engineering fields work faster and easier by giving quick analysis,design of models etc.....actually what i think that there can never be a fixed law in software engineering like laws of nature(laws of motion)etc it is because software engg. does not deal with fixed challenges, changes and complexity.There is very very large domain of different varieties of problems and challenges in software engg.So it has to modulate or acclimatize itself according to problem for getting solution in best possible and faster manner.This is because sometime there is possibility to meet the need of some company(client) very fast.so here time constraint is highly taken into account,Like if some client needs a text editor urgently in couple of weeks so company will provide him this with simple writing , deleting,adjusting size and little bit formatting functionality to meet his need with in the very limited time and enhance functionality in later stages.But if client doesnot require it very immediately and he gives 2-3 months then here time is not constraint then we can provide the client with very high functionality with spelling grammer check,custom pictures and world art facilities.So at last we can say that there can not be fixed law in SW Engg.It depends upon the problem and adopting the excellent wayto solve it in proper manner.Some Requirements of organisation is that o/p should come in very short time there software engg. will use most efficient algorithm which works faster even though it may require large amount of memory.some requirements of organisation is less amount of m/m program here SW engg. may use such algorithms which require less m/m but can take comparatively large time to get o/p

Neelesh Malviya said...

Neelesh Malviya [MT2010086]
Very often human made systems first learn the modus operandi from nature's sophisticated ,tortuous and complex intermingled systems.Then gradually strides,break the system complexity into components and ordaining the charge on individual components, we facilitate the work.But to do this the 3 unrivaled factors are - extreme amount of experience, time and ability to learn from failures.Whereas in SE, we don't have much experience ,neither we have spent a lot of time in this realm nor we are competent enough to learn from our chronic failures in past.That is the reason that still we are shiftless to sunder the design and implementation part of SE.This issue is heretofore like an intermingled and subtle system of Nature.
Compared to other engineering systems,unlike SE, the design and implementation phases are like the modules having low coupling and high cohesion which are linked(coupled) only through a relation thread of BLUEPRINT.But in SE the same software engineer do these mingled threads of design and implementation.The major reasons for this may be the hurdles like -co-evolution of solution and problem domain,problem of change due to market conditions, customer new demands,creation of new entities during SDLC, time and scheduling constraints, etc.
Since the design and implementation is like a complex thought process like any other natural neural system.That's why we are still wrestling the problems in this field like:Unpredictable outcomes, Lack of Design metrics,abatement of parameters like tolerances,allowable stresses,performance ranges,structural complexity,failure probabilities,etc (unlike other fields).
But then again in spite of awful abstruseness, software engineers are like doughty divers in this thinking world ocean, full of complexity and criticality, snagging the strong waves of complexity without any watercraft like SOFTWARE Laws, and still covering the journey of building sclerotic and complex software systems in this ocean.Its all possible due to the marvelous and potential human brain and his hunch.
The LAWS like water-crafts at all times makes this journey in the ocean easier but for us the time is far for SE LAWs because we are having the limited tools for making these laws like retrospective measures of SW analysis, lines of code or performance ranges.To build laws that fit correctly in the law hierarchy proposed by Booch,we need experience but there is something else other than experience.
Just given data,can laws be formulated?
Can there be a softwares which deduces law of SW?
The construction era of SOFTWARE Laws is passing from such types of subtle questions!!