 |
|
|
Pioneer-soft's proof that there is a "Silver Bullet" |
|
Dr. Frederick Brooks, in his most influential paper “No Silver Bullet: Essence and Accidents of Software Engineering”, argued that most of the complexity is essence of the software application. Hence, he concludes there is no silver bullet. This website demonstrates many large "loosely coupled" components and the following WebPages contain clear conclusively proof to show that nearly 90% of the software complexity is undeniably Accidental, hence there is a “Silver Bullet”:
If design engineers can't group all the basic devices into various plug-in parts (e.g. Hard-Drive, Network card and Graphics card etc.), but instead forced to scatter on a large board randomly, is the resultant complexity Essence or Accidental? In OOP, developer is neither explicitly designs nor conscious about the existence of “loosely coupled” component. Each component is build by tightly coupling many Objects. If the component communicate with other parts, then it is implemented by coupling the Objects of both parts. Here it is often hard to trace the dependencies or coupling between the Objects. Therefore, to remove a component, he often needs to employee trail and error to trace dependencies for each of the Objects. By virtue of being referred in the same source files along with other Objects, each Object end up having unspecified dependence on those Objects, even though their respective components have no need to communicate with the component. All such dependencies, Pioneer-soft calls irrational dependencies, because, if two part do not communicate with each other, there must not have any dependency between them. If the Object is referred in more than one file, then the Object ends up with more irrational-dependencies. If one aggregates all the dependencies of all the Objects, one gets the total dependency of the component. This dependency grows exponentially, if the component has many subcomponents, and these subcomponents in turn have subcomponents of their own and so on. This explains why it is practically impossible to replace a large component in large systems. On the other hand, each "Loosely coupled" part would have dependency of about 5 lines of "readily & accurately identifiable" code. |
|
Essential-complexity Verses Accidental-complexity The filament in incandescent light bulb converts about 10% of the electric energy into useful light. Rest of the energy is wasted by converting into heat energy, which also increases air-conditioning costs and global warming. Isn't it a big waste? The 10% of the power consumption is 'essential' cost. Since it is essential to produce the Light, the physical laws says this 10% power consumption cannot be reduced. The 90% is producing unintentional heat, so it is 'accidental' cost. Hence, theoretically possible to eliminate the cost. This 90% is nothing compared to what developers waste in building and especially maintaining large software systems. They partition each 'part' into many devices (i.e. Objects, which often have tightly-coupled interfaces) to 'scatter' and bury each of them under million lines of spaghetti code. If we (the software engineers) need to make a modification today, we are forced to waste 9 to 70 times on avoidable error-prone tasks (if it is possible to avoid the spaghetti code and untraceable irrational dependencies by physical-encapsulation and building component-hierarchies). If we can avoided the spaghetti code (i.e. accidental cost) in the first place, which also reduces the initial development cost of the application by more than 50%. This is equivalent to inventing reliable, long lasting light bulb that consumes 5% to 9% of the power, and yet costs less than 50% to manufacture. |
|
Observations on the practice of Software Engineering About 80% of software engineering deals with changing existing software It is not the strongest of the species that survive, nor the most intelligent, but the ones most responsive to change -- Charles Darwin Time to market is an important competitive advantage: incorporate successful innovations quickly |
|
Why
making even a small change to software is many times more complex and prone to errors? |
|
This website demonstrates many 'loosely coupled' parts and also contains many examples to illustrate how one may create "Loosely coupled" parts. There are no missing pieces to alleviate the "software crisis" for building online GUI applications today. What else is needed to prove that there is a "Silver Bullet"? |
|
|||||||||
It is the 
Unfortunately, researchers think: solution is inventing even more complex
reusable parts. Aren't we been squeezing enough reuse already? The part must be more generic to be more
reusable. More generic parts need more customization or tight-coupling. Design changes to a reusable part
have impact on many applications that reuse the part. Doesn't it act as a deterrent
to change. The developer has to deal with all the stake holders of the reusable part and corporate politics. 
Don't
you agree the
