Accidental vs Essential Complexity

If you have not heard of this before here is a neat way to look at it....

say that you want to find the biggest number in an array. To do that first you decide to sort the array and then do the finding. Assuming the running time of the algorithm is your complexity your algorithm has O(n^2) complexity. Then some one comes up and say I can do it in O(nlogn) time. Well , in that case you have introduced some complexity in to your algorithm than this one and hence that's an accidental complexity. After thinking for while you decide..Wait a minute I can do it in O(n) time by simply comparing each number and remembering the highest! So now the nlogn becomes an accidental complexity. Now if someone comes to you saying they can do it in O(logn) then you know it's not true. coz that means their algorithm will find the biggest by not looking at every number which is not possible. So now you conclude that O(n) is the Essential complexity of the problem. Sounds good?

Where does this idea come from? In his famous paper Fred.Brooks brings up this notion of software systems having their essential and accidental complexities in the search of a silver bullet for software engineering problems. In summary, Accidental complexity is something that we bring on ourselves into the problem and Essential complexity is something inherent to the problem itself.

refs..

"No Silver Bullet"- Essence and Accidents of Software Engineering
by Frederick P. Brooks, Jr.,
University of North Carolina at Chapel Hill

[1] F.P. Brooks, The Mythical Man-Month, 1985, Addison-Wesley, Reading, Mass., New York, Chapter 16

Computer Science and Software Engineering

Have u ever wondered what really distinguishes the computer science discipline against with software engineering? I was given a little thought on this key difference between the two by one of my professors when I was learning about software patterns and I thought it’s an interesting point and decided to share it over here.

In engineering everything has to be done according to a specific rule or better said as a code of conduct. When software was considered to be a stream of engineering it also had to accommodate some conducts and that’s where software patterns came up. Because there is no specific way of doing a particular thing as such in software there has not been any rules given for writing software. But there always have been better solutions to a problem than a wrong solution to a problem. The artifact of a design problem is how good or better the design is than something else. The key behind design patterns was nothing but recommendations than hard and fast rules. But what exactly is a pattern?
Is it a solution to a particular type of problem? Well for some thing to become a pattern it better have the following 3 properties.
1.It has to solve a well known problem; that is, almost everyone writing software should encounter such problems
2. The problem has to be recurring meaning it happen almost all the time to all the ppl
3.The solution to the problem should not be invented from a specific problem but should be drawn from several possible solution sets.

So that’s what we call a software pattern. So as with all other engineering ppl , software engineering involves a set of code of conducts to which you have to conform while being a software engineer failing which you will be considered guilty. In contrast a computer scientist can still write a sloppy algorithm and get way from lawsuits. :o)
In other words a computer scientist is not guilty unless proven to be guilty and a software engineer is considered guilty if he does not follow his code of conduct.
So I am better off being a computer scientist than a software engineer eh? :o)