Reading

BROOKS JR., F. P. (1987) NO SILVER BULLET ESSENCE AND ACCIDENTS OF SOFTWARE ENGINEERING.



This article discusses the state of the software industry, claiming that there are many theories regarding lack of software productivity. The artcile examines Brooks' ideas as they appeared in his "Computer Magazine" article, "No Silver Bullet", as well as the opinions of Cox and others. The paper contends that these theories and others, all help to shed light on barriers to software productivity.




Brooks argues that "there is no single development, in either technology or management technique, which by itself promises even one order of magnitudeimprovement within a decade in productivity, in reliability, in simplicity." He also states that "we cannot expect ever to see two-fold gains every two years" in software development, like there is in hardware development (Moore's law).



Brooks makes a distinction between accidental complexity and essential complexity, and asserts that most of what software engineers now do is devoted to the essential, so shrinking all the accidental activities to zero will not give an order-of-magnitude improvement. Brooks advocates addressing the essential parts of the software process. While Brooks insists that there is no one silver bullet, he believes that a series of innovations attacking essential complexity could lead to significant (perhaps greater than tenfold in a ten-year period) improvements.



Brooks advocates "growing" software organically through incremental development. He suggests devising and implementing the main and subprograms right at the beginning, filling in the working sub-sections later. He believes that programming this way excites the engineers and provides a working system at every stage of development.



Brooks goes on to argue that there is a difference between "good" designers and "great" designers. He postulates that as programming is a creative process, some designers are inherently better than others. He suggests that there is as much as a tenfold difference between an ordinary designer and a great one. He then advocates treating star designers equally well as star managers, providing them not just with equal remuneration, but also all the perks of higher status: large office, staff, travel funds, etc.



"THE CHAOS MODEL AND THE CHAOS CYCLE" INTRODUCED BY RACCOON IN 1994



To truly understand software development, one must not only understand the flow of an entire project and how to write each line of code, must also understand how one line of code relates to the whole project. many development models discuss management-level issues, such as phases and deadlines, rather than how to write one line of code or fix one bug.Programming methodologies show us how to solve technical problems, rather than how to solve users' problems or to meet deadlines



In the article Racoon uses the principles of chaos (or fractals) as a metaphor to bridge the gap in our understanding of the relationship between one line of code and the entire project.Author describes software development from the developer's point of view.



Most software development methodologies today focus on communication and detail development process. This approach creates a transparency between the high level management desires and the development team understanding of the issues and priorities. The chaos model defines a necessary lower level of interpretation and attempts to address software development from a linear problem solving process, which is fundamental in all software development.

Agile frameworks require customers to prioritize business functionality for implementation. The chaos model seeks to resolve the most important issues first from the top-level program to the lowest level code generation. This full program view of a software application highlights the critical need to include the single code level design that must be accomplished to meet the program level requirements.

This model accounts for the humanistic side of a development effort. The development team is made of individuals who must design and configure the modules within the software application. Each team member must make critical decisions in the code that could impact the entire program. The chaos model accounts for the interaction among the team members when making coding changes.
Full Post