Sliver Bullet to Software Crisis



Download 10.28 Kb.
Date conversion29.05.2017
Size10.28 Kb.

Sliver Bullet to Software Crisis


In a European folklore, sliver bullets are born for killing werewolf. “Silver is identified with the moon and thus has magic properties. A silver bullet offers the fastest, most powerful and safest way to slay the fast, powerful, and incredibly dangerous werewolf” [1].

In the domain of software engineering, for many years people have been seeking the “silver bullet” to tackle the software crisis, which was characterized by the high complexity, low productivity, high cost and poor reliability etc. of software systems. According to his own experiences, in 1986, Fred Brooks asserted a skeptical conclusion, if not a pessimistic one, that “Not only are there no silver bullets now in view, the very nature of software makes it unlikely that there will be any within a decade”[1].

In his well-known paper No Silver Bullet – Essence and Accidents of software Engineering, borrowing Aristitle’s terminology in philosophy domain, Brooks classified the software difficulties into two categories [1]. “The difficulties inherent in the nature of software are called essence”. Essences are at conceptual level, and they are irreducible. The inherent properties of essence of modern software systems include complexity, conformity, changeability and invisibility. “The difficulties that today attend its production but are not inherent are called accidents”. Accidents are difficulties on representation when converting a concept to code. Although people have made progresses to attack difficulties at accidental level, i.e., high-level languages, timing sharing and integrated program development environments, it is the essences that block people to produce the silver bullet to overcome the software crisis fast and powerfully [1].

As a software engineering master, Brooks addressed the problem at a philosophical level, instead of a merely technological one. Unfortunately, his prediction that “no silver bullet within 10 years” had been proved to be true. However, another question here is raised: will his prediction be valid for another decade?

In the way to answer this question, we may be interested in thinking about the relationship between bullet, silver, wolf and werewolf. It is silver bullet that is able to slay werewolf. Bullet does not. Bullet can kill a wolf, but not werewolf. Silver gives a bullet the magic to kill werewolf – a monster wolf. However, sometimes we may be confused at which one on earth slays the werewolf – the “silver” or the “bullet”?

Similar paradox exists when considering the relationship between essence and accidents. According to Brooks, if you know how to get rid of the essential difficulties, you found the silver bullet. Otherwise, even you try to kill wolves as many as you can you have not killed the werewolf yet. Do the essences and accidents really act so different?

Actually, it is not reasonable as well as feasible to classify essences and accidents arbitrarily into conceptual and concrete levels respectively. Sometimes, they are mixed up. In the evolution history of sciences and technologies, some revolutionary changes happened on one day. Before this remarkable change, however, there might have been a long and gradual evolution to prepare for the great change. From this point of view, the change of quantity can bring about the change of quality, and the solutions for accidents can also lead to the revolution on essence.

With the mention of brooks’ paper No Silver Bullet – Essence and Accidents of software Engineering, we cannot neglect to mention some articles of another soft-engineering master - Brad Cox’s. In his There Is a Silver Bullet in 1990 [2], Cox believed that the software crisis is not immovable. Because of the “cultural change” of the modern society, people are experiencing a paradigm shift on the idea of software. The integrated and re-applicable “standard components” of software are prevailing, and their market is coming into being. These lead to a ‘software industry revolution”. In his another paper in 1995 – almost ten years after Brooks’ first paper – Cox argued that the so-called essential difficulties, which include complexity, conformity, changeability and invisibility, are not really essential, but only the symptoms of a “cause” hidden in depth [3]. The cause is that, for the time being it lacks a favorable cultural environment that stimulates the industries to produce and deal software components – software IC [3].

Cox’s view is appreciated by providing a human-centric cause to cover both essence and accidents. This avoids a somehow arbitrarily division of essence and accidents according to Brooks. However, Brooks was never wrong – at least there has not appeared a silver bullet by now. In his response to Cox’s arguments, Brooks claimed that although software IC is a promising way, its progress would be very slow [4]. The silver bullet is still far away.

Will Brooks’ conclusion be still valid in the coming decade? Because of the lacking of my own experience and knowledge, I cannot draw any more extrapolations and conclusions at the end of this writing – and maybe it is too early to draw a conclusion for any people seeking silver bullet at time being. However, Brooks and Cox’s papers are references highly recommended to soft engineers who are interested in looking into this problem.



References:

[1] Fred. Brooks, “No Silver Bullet – Essence and Accidents of software Engineering”, IEEE Computer, April 1987, pp. 10-19

[2] Brad. Cox, “There Is a Silver Bullet”, Byte, Oct. 1990, pp. 209-218

[3] Brad. Cox, “’No Silver bullet’ Reconsidered”, American Programmer, Nov. 1995, pp.2-8



[4] Fred. Brooks, “’No Silver bullet’ Refired”, The Mythical Man-Month, MA: Addison-Wesley, 1995





The database is protected by copyright ©ininet.org 2016
send message

    Main page