Hello Habitants! Few books on project management are as significant as The Mythical Man-Month. A mixture of real software development examples, opinions and thoughts creates a vivid picture of managing complex projects. These essays draw on Brooks' fifty years of experience as a project manager for IBM System / 360 and then OS / 360. The first edition of the book was published 45 years ago, the second 25 years ago. New methodologies are emerging, new programming languages are emerging, the number of processors is growing, but this book continues to be relevant. Why? Half a century later, we continue to repeat the mistakes that Brooks described. Some of the topics discussed in the book seem outdated, but this is only an appearance. The fundamental problems behind them are still relevant today. It is important to know your past in order to understandwhere the software development industry is developing. Therefore, 45 years later, we read Brooks. Much has changed in the world, but nine women still cannot bear a baby in one month.
An excerpt. Aristocracy, Democracy and Systems Design
This magnificent church is an outstanding work of art. There is no dryness or confusion in the dogmas she manifests ...
This is the zenith of style, the work of artists who understood and assimilated all the successes of their predecessors, who perfectly mastered the technique of their time, but used it without immodest demonstration or absurd display of skills.
Undoubtedly, the idea of the general plan of the building belongs to Jean d'Orbet, who was respected, at least in its essential elements, by his successors. This is one of the reasons for the extraordinary consistency and unity of the building.
Reims Cathedral guide
Conceptual integrity
Most of the European cathedrals were built gradually, and the parts built by builders of different generations differ in terms of architectural style. Subsequent builders were tempted to “refine” the design of earlier ones, focusing on changes in architectural “fashion” and personal taste. Therefore, the peaceful Norman transept * abuts and contradicts the soaring Gothic nave, and the result is as much to praise the glory of God as it does to the pride of the builders.
Against their background, the architectural unity of Reims is in great contrast. The delight that excites the viewer comes from both the integrity of the design and from any individual merits. As stated in the guide, this integrity was achieved by the self-denial of eight generations of builders, each of whom sacrificed some of their ideas for the sake of the purity of the overall design. The result proclaims not only the glory of the Lord, but also His power to save sinful people from their pride.
While most programming systems did not take centuries to build, they exhibit far worse conceptual disunity than cathedrals. This usually happens not because of a change of designers, but because of the division of the project into numerous tasks performed by many people.
I insist that conceptual integrity is the most important consideration in a systems design. It is better to have a system that lacks some features and improvements, but reflects one set of design ideas, than to have a system that contains many good but independent and inconsistent ideas. In this chapter and in the next two we will look at the implications of this topic for the design of programming systems:
- How to achieve conceptual integrity?
- Isn't this argument justifying the elitism or aristocracy of architects in front of a horde of plebeian implementators, whose creative talents and ideas are suppressed?
- How to keep architects from drifting into the blue with unimplemented or expensive specifications?
- How to ensure that every minor detail of the architectural specification is brought to the attention of the implementer, understood correctly and accurately embedded in the product?
Achieving conceptual integrity
The purpose of the programming system is to make the computer easy to use. To do this, it supplies languages and various support tools, which are actually programs called and driven by language capabilities. But these tools come with a price: the external description of the programming system is 10–20 times larger than the external description of the computer system itself. It is much easier for the user to set any single function, but their choice is vast, and there are many more options and formats to keep in mind.
Usage is only simplified if the time gained in the functional specification exceeds the time lost in assimilating, memorizing, and searching the reference manual. In modern programming systems, this gain does exceed cost, but in recent years, the gain-to-cost ratio seems to have dropped as more and more complex features are added. I am haunted by the memory of the ease of use of the IBM 650, even without assembly language or any other software at all.
Since ease of use is the goal, this relationship of functionality to conceptual integrity is the ultimate test of system design. Functionality and simplicity alone do not define good design.
This thesis is widely misunderstood. The OS / 360 operating system is hailed by its creators as the finest ever designed because it is undeniably the most functional. It is functionality, not simplicity, that has always been the measure of excellence for its designers. On the other hand, the PDP-10's time sharing system is hailed by its creators as the best because of the simplicity and restraint of concepts. However, by any measure, its functionality does not even belong to the same class as that of OS / 360. Once ease of use is taken as a criterion, each of these approaches becomes unbalanced, only half way to the goal.
However, for a given level of functionality, the best system is one in which things can be specified with the greatest simplicity and straightforwardness. Simplicity alone is not enough. The languages TRAC Mooers and Algol 68 achieve simplicity, measured by the number of distinct elementary concepts. Immediacy, however, is not characteristic of them. Expressing your intentions often requires combining basic tools in complex and unexpected ways. It is not enough to study the elements and the rules for their combination; it is also necessary to study the idiomatic use, to assimilate a whole body of knowledge about how the elements are combined in reality. Simplicity and straightforwardness come from conceptual integrity. Each piece should reflect the same philosophy and the same balancing act.Each part must use even the same technique in syntax and similar concepts in semantics. Thus, ease of use dictates design unity, conceptual integrity.
Aristocracy and Democracy
Conceptual integrity, in turn, requires that the project come from one developer or a small number of them, acting in concert and in unison.
The pressure of the schedule, in turn, requires the involvement of more workers. There are two methods to solve this problem. The first is the careful division of labor between architecture and implementation. The second is a new way of structuring programming implementation instructions, discussed in the previous chapter.
Separating architectural effort from implementation is a powerful way to achieve conceptual integrity in large projects. I myself have seen it used with great success on the IBM Stretch and System / 360 product line of computers. And I witnessed how it didn't work in the development of Operating System / 360 because it wasn't used enough.
By system architecture, I mean a complete and detailed specification of the user interface. For the computer, it is embodied in the programming reference manual. For the compiler - in the language reference manual. For a control program, the reference manual for the language or languages used to call its functions. For the entire system, it is a collection of reference guides to help the user achieve their goal.
The system architect, like the building architect, is the user agent. Its responsibilities include the use of professional and technical knowledge in the interests of the consumer, and not in the interests of the seller, manufacturer, etc. The
architecture should be clearly distinguished from the implementation. As Blaauw noted, "Where architecture talks about what happens, implementation talks about how it's done to make it happen." As a simple example, he cites a watch whose architecture consists of a dial, hands and crown. When a child learns this architecture, he will be able to tell the time with the same ease both by his wristwatch and by the clock on the church tower. Implementation and its implementation describe what happens internally: the transfer of effort and the control of precision by each of the many mechanisms.
For example, in System / 360, a separate computer architecture is implemented very differently in each of the nine models. In turn, the separate implementation, data stream, memory and microcode of the Model 30 system at different times serve four different architectures: the System / 360 computer, the multiplexed channel with 224 logically independent subchannels, the selector channel, and the 1401 computer.
The same distinction applies equally to programming systems. The US has adopted the Fortran IV standard. It is the architecture for many compilers. Within this architecture, different implementations are possible: in-memory text or compiler, fast or optimizing, syntactic or ad hoc. Likewise, any assembly or job control language allows many assembly or scheduler implementations. Now we can tackle the deeply emotional issue of aristocracy and democracy. Aren't architects the new aristocracy, the intellectual elite, set up to tell poor, brainless implementers what to do? Hasn't this elite taken over all creative activity, making the performers only cogs in the mechanism? Can't you get a better productimplementing good ideas from the whole team, following a democratic philosophy, instead of limiting the development of specifications to a select few?
As for the last question, it is the simplest one. I am not suggesting that only architects have good architectural ideas. Often, a new concept comes from the implementer or from the user. However, all my experience convinces me, and I tried to show this, that the conceptual integrity of a system determines its ease of use. Good features and ideas that don't integrate with the underlying concepts of the system are best left aside. If there are many such important but incompatible ideas, then the whole system is discarded as a whole and work begins again on an integrated system with other basic concepts.
As for the accusation of aristocracy, the answer must be “yes” and “no”. Yes, in the sense that there should be few architects, their product should last longer than the product of the implementer, and the architect is at the center of the forces that he should ultimately direct in the interests of the user. If the system is to have conceptual integrity, then one person must take the lead. This is aristocracy that does not need an apology.
Developing external specifications is as creative work as designing implementations. It's creativity, just a different kind. An architecture-aware implementation design requires and allows as much design creativity, as much new ideas, and as much technical brilliance as the design of external specifications. Indeed, the cost-to-performance ratio of a product will be most dependent on the implementer, just as ease of use is most dependent on the architect.
There are many examples from the arts and crafts that lead to the belief that discipline improves craftsmanship. Indeed, the artist's aphorism states: "the form liberates." The worst structures are those whose budget was too large for the service to be served. Bach's creative activity was hardly suppressed by the need to publish a weekly cantata limited in form. I am sure that the Stretch computer would have a better architecture if it were more restrictive; the budget constraints of the System / 360 Model 30 have, in my opinion, been beneficial to the Model 75 architecture in all respects.
Similarly, I find that outsourcing the architecture enhances, rather than negates, the creative style of the implementation team. They immediately focus on the part of the task that no one solved, and inventions begin to flow like a river. In an unrestricted implementation group, most of the thought and discussion goes into architectural solutions, with short implementation deadlines.
This effect, which I have seen many times, is confirmed by RW Conway, whose group at Cornell built a PL / C compiler for the PL / 1 language. He notes the following: "In the end, we decided to implement the language without changes and improvements, since the discussion of the language would take all our energy."
What should the implementer do while waiting?
It’s humiliating to make a million dollar mistake, but it’s so memorable. I vividly remember the night we decided how to organize the actual writing of external specifications for OS / 360. The architecture manager and the manager of the control program and I worked out the plan, schedule and assignment of responsibilities.
The architecture manager had 10 talented people. He argued that they can write specifications and do it right. It will take 10 months, three more than the schedule allows.
The manager for the implementation of the control program had 150 people. He argued that they could prepare specifications in coordination with the architecture team; it would be well done and practical, and it would fit into the schedule. Plus, if the architecture team were to do it, its 150 people would sit idly by for 10 months.
To this, the architecture manager replied that if I transfer responsibility to the control program team, then in fact the result will be received 3 months later and of much lower quality. I handed over responsibility to the control program implementation team, and it turned out as he said. He was right in both cases. Moreover, the lack of conceptual integrity made the system much more expensive to build and change, and I estimate that it delayed debugging by a year.
Of course, many factors influenced this erroneous decision; but the overwhelming ones were time constraints on the schedule and an appeal to bring all these 150 implementers to work. It is this singing of sirens, fraught with mortal dangers, that I will now make visible.
To the proposal that a small architecture team will actually write all the external specifications for a computer or programming system, the implementers raise three objections:
- The specs will be too feature-rich and will not reflect practical cost.
- Architects will have all the creative pleasure and will give up the ingenuity of the implementers.
- Numerous performers will have to sit idly by while specifications go through the bottleneck of the architectural team.
The first is a real danger, and we will look at it in the next chapter. The other two are illusions, pure and simple. As we saw above, implementation is also a first-order creative activity. The ability to be creative and inventive in design is marginally limited by the need to work within given external specifications, and this discipline can even enhance creativity. This is undoubtedly true for the project as a whole.
The last objection concerns timing and phases. The quick answer is not to hire implementers until the specs are complete. In construction, they operate on the same principle.
In the computer systems business, however, the pace is faster, and everyone wants to squeeze the schedule as much as possible. To what extent can specification and development overlap?
As Blaau points out, the overall creative effort includes three distinct phases: architecture, implementation, and implementation. It turns out that they can indeed start in parallel and continue at the same time.
For example, in computer design, the implementer can get started as soon as he has relatively vague assumptions about the reference manual, more or less clear ideas about the technology, and well-defined targets for cost and performance. He can design data streams, control sequences, rough packaging concepts, etc. He develops or adapts the tools that he needs, especially an accounting system, including a design automation system.
At the same time, at the implementation level, the designs of circuits, cards, cables, frames, power supplies and memory should be drawn up, improved and documented. This work goes in parallel with the architecture and implementation.
The same is true for the design of programming systems. Long before the external specifications are finalized, the implementer has a lot to do. With some gross oversimplifications of the functionality of the system, which will eventually be embodied in external specifications, he can continue to work. It should have clearly defined spatial and temporal targeting criteria. He must know the configuration of the system on which his product is to run. Then he can start designing module boundaries, table structures, pass and phase breakdowns, algorithms, and all sorts of tools. Some time should also be spent communicating with the architect.
There is still a lot of work to be done at the implementation level. Programming also has technology. If the machine is new, there is much to be done about subroutine calling conventions, supervisor technology, search and sorting algorithms.
Conceptual integrity requires that the system reflects a single philosophy and that a user-visible specification is written by multiple people. However, due to the real division of labor into architecture, implementation and implementation, it does not at all follow from this that the assembly of a system planned in this way will take longer. Experience shows the opposite: that the whole system converges faster and faster and takes less time to test. In fact, the widespread horizontal division of labor was drastically curtailed by the vertical division of labor, and the result was a radical simplification of communication and improved conceptual integrity.
»More details about the book can be found on the website of the publishing house
» Table of Contents
» Excerpt
For Habitants a 25% discount on coupon - Brooks
Upon payment for the paper version of the book, an e-book is sent by e-mail.