The Mythical ManMonth by Fred Brooks I Published

The Mythical Man-Month by Fred Brooks (I) Published 1975, Republished 1995 n Experience managing the development of OS/360 in 1964 -65 n Central Argument n – Large programming projects suffer management problems different in kind than small ones, due to division of labor. – Critical need is the preservation of the conceptual integrity of the product itself.

The Mythical Man-Month by Fred Brooks (II) n Central Conclusions – Conceptual integrity achieved through exceptional designer – Implementation achieved through wellmanaged effort – Brooks’s Law: Adding personnel to a late project makes it later

No Silver Bullet by Fred Brooks (1987) n “There is no single development, in either technology or management technique, which by itself promises even one order-of-magnitude improvement within a decade in productivity, in reliability, in simplicity. ”

Why Is This a Safe Bet? n “All software construction involves essential tasks, the fashioning of the complex conceptual structures that compose the abstract software entity, and accidental tasks, the representation of these abstract entities in programming languages within space and speed constraints. … How much of what software engineers now do is still devoted to the accidental, as opposed to the essential? Unless it is more than 9/10 of all effort, shrinking all accidental activities to zero time will not give an order of magnitude improvement. ”

Essence v. Accident n Essence: the difficulties inherent in the nature of the software n Accidents: those difficulties that today attend its production but that are not inherent

Accidental Difficulties n Solutions potentially exist n Past productivity increases result of overcoming prior accidental difficulties – Inadequate programming constructs & abstractions • Remedied by high-level programming languages • Increased productivity by factor of five • Complexity was never inherent in program at all

Accidental Difficulties (cont’d) n Past productivity increases result of overcoming (cont’d) – Viewing results of programming decisions took long time • Remedied by time–sharing • Turnaround time approaching limit of human perception – Difficulty of using heterogeneous programs • Addressed by integrated software development environments • Support task that was conceptually always possible

Essential Difficulties n Only partial solutions exist for them, if any n Cannot be abstracted away – Complexity – Conformity – Changeability – Intangibility

Complexity n No two software parts are alike – If they are, they are abstracted away into one n Complexity grows non-linearly with size – E. g. , it is impossible to enumerate all states of program (Except perhaps toy programs)

Conformity n Software is required to conform to its – Operating environment – Hardware n Often “last kid on block” n Perceived as most conformable

Changeability n Change originates with – New applications, users, machines, standards, laws – Hardware problems n Software is viewed as infinitely malleable

Intangibility n Software is not embedded in space – Often no constraining physical laws n No obvious representation – E. g. , familiar geometric shapes

Pewter Bullets n n n n Ada, C++, Java and other high–level languages Object-oriented design/analysis/programming Artificial Intelligence Automatic Programming Graphical Programming Program Verification Environments & tools Workstations

Promising Attacks On Complexity (In 1987) n Buy vs. Build n Requirements refinement & rapid prototyping – Hardest part is deciding what to build (or buy? ) – Must show product to customer to get complete specification – Need for iterative feedback

Promising Attacks On Complexity (cont’d) n Incremental/Evolutionary/Spiral Development – – n Grow systems, don’t build them Good for morale Easy backtracking Early prototypes Great designers – Good design can be taught; great design cannot – Bottom line: Nurture great designers

Software Architecture (and Architects) n Software Engineers have always employed software architectures – Very often without realizing it! n Address issues identified by researchers and practitioners – Essential software engineering difficulties – Unique characteristics of programming-in-the-large – Need for software reuse n Many ideas originated in other (noncomputing) domains

Primacy of Design Software engineers collect requirements, code, test, integrate, configure, etc. n An architecture-centric approach to software engineering places an emphasis on design n – Design pervades the engineering activity from the very beginning n But how do we go about the task of architectural design?