20th anniversary edition
by Fred Brook
Modifié le Wednesday, 13-Aug-2008 03:21:48 CEST
Fred Brook wrote this book in the mid 70's. The whole book is a reflexion on whether or not we can prevent software from being late. First he tries to illustrate that better practices exist . Then, he states there are no silver bullets , no methods, no technical tools able to make incertitudes disappear during the process of software development, because efficiency heavily rely on «peopleware».
Fred Brooks notice creative mind are few, and that creativity is independent of the diploma and of experience. He then shows that added value, and great increase in productivity in software development is mainly coming from a coherent conception. To illustrate his point of view you can consider that though computer technology is ruled by Moore's law (CPU power, size in storage ... double every years), then as power is increasing, tool's power should do so too. And you notice that they were no two fold improvement in productivity. Therefore productivity has nothing to do with tools, and is essential
In fact, software management is done in the same way as manufactured products (especially buildings). This is not revelant in software production because softwares are threatens by obsolence before the production is completed.
As a conclusion, peopleware are all the practices that :
- that empower the right people (it includes talent detection, and the surgical team ),
- that help everyone communicate efficiently
- helps managing project.
Biography
Fred Brooks has a strong experience of project management. He was involved in hardware architecture (1956-1963) while batch processing and high language compiler were being developed. In 1964, he became the manager of IBM OS/360 , whereas the previous changes were impacting the programming world. Some of the OS/360 technical innovations are nowadays widely spread, however some flaws in the design proved to be costly. It was all the more annoying that the project was late and did not fullfill its goal. Fred Brooks felt that these flaws ought to be laid to his charge.
After he left IBM, he became a teacher at the university of Chapel Hill, he decided to figure out how he did things wrongs, and to draw lessons concerning the management and the technical aspect of large project management. He build his reflexion with managers of jumbo programming projects. The no silver bullet part being his conclusions concerning his experience, and project management in general.
Hypothesis
Fred Brooks main hypothesis is software development takes place in a hierarchized environment so to say firms, or eventually universities.
Then he noticed firms, organisations, constraint the way people communicates, or their strength of proposal (due to their hierarchical positions). As creative time is rare, and because the creative minds produce clean concepts that are the only way to improve one's product, every thing should be done so that creative minds can be efficient, so to say, they should be freed from organisational constraints.
He makes the hypothesis postulate is constraint other creative minds are non productive, because these are rare, and because creativity is a job of a single mind, their should be given the means to work efficiently.
Postulates
The first postulate is software development is all about creativity, and that very few minds are able to be truly creative, therefore their time is precious, and should be used preciously. It implies that tools and technics are not revelant while speaking of productivity in software production.
The second postulates is organisations especially enterprises, are trying to be productive.
Resume
The Tar Pit
Efficient project management is not luxe; it is the ability of large software companies to survive their projects especially in system programming
.Occasionnaly, you can read in the newspaper, story of garage duos making programs surpassing the effort of great teams, and some are ready to believe it. System programming, is not only making a program, it is also the building the framework that come with : it is normally designed to run on several systems, it is shipped with test tools, full documentation so that it can be used... Therefore, regarding the size to produce it ought to be made by a whole team.
What is the craft of programming
The joy of programming, is to build, tools that are useful to others. The ludic joy of conceiving tricky things. And above all, the magical pleasure of creating from "pure air". The woes of the craft, is the painstaking labour that comes with creation. Programs have to be perfect (in the sense of computer understanding). And therefore, programming rarely converge, the latest bugs being the toughest. It is all the more difficult that your formal authority is rarely fitting with your responsibility, responsibilities coming when your product is finished. Therefore, you are bound to others good will in producing accurate piece of software or of information you rely on.
The latest woe is that your product will be threaten by obsolence before completion. Products are rarely shipped with the functionalities they were design for : either an adjustment is made regarding the available resources, or it is done in regard with other's similar products.
Teams have to find real solutions, within their environment. And, this book is design to help managers improving programmers' work.
The Mythical Man Month.
One of the main reason software projects nearly fail is usually they lack time for being achieved.
Mainly, the lack of time is due to poor estimations :
- project managers / developers are overly optimistic concerning the achievement of the project, it is the usual assumption that "all will go well"
- techniques confuse progress and effort (mythical month's theorem),
- Estimations are often precise, rarely accurate.
- There is few progress monitoring on projects.
For a single task, it is reasonable to assert thinks might go well, but when dealing with a large number of tasks which may be chained, the probability that all will go well is vanishing.
The Man Month
The man month is a dangerous and deceptive unit for measuring the size of a job
Cost can be expressed as men times months, progress cannot.
When task are partitionables, men and months are interchangeable. But, in the case of software development, because of the sequentiality of programming, there are unpartionables (sub) tasks, in the same way you will always need nine months to bear a child whatever the number of women you assign.
As tasks, have to be partitioned, the cost of intercommunication has to be taken into account. If the cost of training of newcomers is considered, you can poorly exchange men and month. When a task needs intercommunication and training you can consider the effort increase in nx(n-1)/2, 3 mens will need 3 times more pairwise communication as two.
Because of optimism software debugging is always underestimated, therefore it is always the most miscalculated part of scheduling. Fred brooks propose to devote more times than usual to both planning(1/3rd of the whole project), and debugging (1/2lf). Bad news often came with debugging, as there is generally few time to face slippage, this has often severe financial and psychological repercussions that can be lethal to a project. At this point there is hardly any turning back, among every departments the project is normally fully staffed, and the cost per day is at its maximum level.
The Mythical Man Month's theorem
What is usually done when a project is late ? More men are added consuming training, and intercommunication time that will do nothing more than latening the project even more. Then we can state Brook's law, or the man month's theorem that is
Adding manpower to a late software project make it later.
The Surgical team
This chapter concern the making of good development teams. Managers have always noticed great variation among programmers, statisticians have showed evidence of it
. (NB other more recent studies more recent are concordant to this one
). These
studies shows after two years experience, and with the same training
there is no correlation between productivity and
- the experience,
- the diploma.
However, to have this teams work, they have to be coordinated, you have to make them share the integrity of the conception. The next chapters are dedicated to this aspect
Aristocracy Democracy and system design
It was feasible to build cathedral, because up to eight generations of workers would follow the early conception without trying to improve the design. In system programming, to be able to have programmers to build a consistent piece of software, you need each separate teams to respect the conceptual integrity.
«Where Architecture tells what happens, implementation tells how it is made to happen ».
Implementation helps optimising
programs so that they can run faster, while architecture helps having
program that are easy to use. The easier to use a program is, the more
the architecture is detailed. Then to ensure consistency, it has to be
made by few minds cooperating, and this is really detached from
implementation. Conception is an aristocracy that needs no
apology. Some considers this denies all the fun creative part to
developers. This turns to be wrong : while conception aims the ease of
use of the product and bringing coherence to the interface, programming
creativity aims towards optimisation and better performance.The second system effect
This chapter is about the constraint an architect should keep in mind. By analysing that most of the time the second version of a good system might be overloaded with nice unuseless features, F. Brooks highlight some good practice to avoid this.
Interactive discipline
Often architectures tends to be too rich. And architects have two highly emotional choices to face :
either proposing cheaper implementation
or cut the design.
To do it successfully the architect ought, to interact with the shareholders of the process (programmers, and customers) quietly without dictating, and smoothly.
Self discipline
While doing a first implementation, architects use to think of improvement, and embellishment to bring to the next version. Therefore, there is a tendency to over design the second version. Though improvements might look nice in term of architecture, they may breach the conceptual integrity of the design, bringing useless costly features to the users.
There is only one way to avoid the second system effect:
- to be aware of it,
- to imply senior architect in conception.
Passing the word
Now that you have your programmers and an architecture, how do you make the teams access and share the informations in a way you can maintain your conceptual integrity, until the very end ? F. Brooks proposal consists of IBM organisation for the OS/360 project.
Writing a manual
You can write specifications in a manual so that others can access to the features you want to be created. A manual should be precise to help the implementation, it should describe not only what the users see, but also the API
. For a manual to be useful, it should also describes what is silent and
what level of precision is given so that one knows his degree of
liberty.To avoid consuming man to man communication, courts and conferences are powerful tools. F. Brooks proposes that developers and architect should meet often so that they can set issues which were not clearly treated in the specifications and that are arising during the implementation.
Frequently Asked Question
To keep track of the misunderstanding that have risen architects should keep track of the question brought by the developers. These should be kept in a log that could be edited periodically.
Product test
Because customers are unforgiving external auditors, an independent product organisation is needed. Its purpose is to discover flaws so that none or few comes to the costumer.
Communication : the very essence of Organisation
A quick audit of the Babel project shows :
- there was a clear mission,
- there was enough manpower, manpower, time
- there was adequate technology
Communication in large project
Teams should have good formal and informal means of communication. There should be also some regular meetings so that little misunderstandings among teams do not grow to major ones. And most of all the backbone of the communication among the team should be a project workbook.
This should be made raw documents that were generated by the project. Since tomorrow's manual are made not only from yesterday's specifications but also from adjustments, intermediate documents should be kept for the comprehension of every choices. Because, coherence is every one's job, the whole teams are to have access to it.
Organisation in large programming projects
If there are n teams, then there can be n.(n-1)/2 interfaces needed for communication. The purpose of organisation is to reduce the amount of communication, to avoid the noise generated by incessant broadcasting.
Fred Brooks proposes the teams should be structured so it reduces useless communication toward programmers, there role should also be to ensure they have the good work conditions.
So that producers' job is efficient, there are two major support functions that are needed :
- technical direction : a purely technical job aiming toward the reduction of production's complexity,
- management whose role is to ensure the respect of schedules, task division, and that is the teams' interface.
Estimation of project
Portman's Data
First, one should remember that the coding part of a project is only a sixth of it. Then the issue of estimating a job's length is also the issue of guessing the productivity of a programmer.
A major point is that programmers spend few time (less than 50%) in technical jobs (debugging and programming).
Aaron's, Harr's, OS360's Data
Then the productivity is directly related to the interactions between components. The more a program is complex in term of interdependence between components, the less a programmer will be efficient.
Corbato's Data
Productivity is constant, whatever the programming language, in terms of elementary statements of the language. Then, by choosing a proper language for development, productivity may be increased.
Ten pounds in a five-Pound Sack
This chapter seems to be a little outdated ; it treats of the cost of program size. At this time (mid 70s) you would rent means computer resources and disk capacities. And this was really expensive. However, this chapter is still up to date regarding embedded programming.
The first point is that size is not bad, unnecessary size is. A program cannot be criticised for its size in itself, as long as it provides features that worth it.
The success heavily depends on conception. To be able to achieve your goal, size target should bet set up for each components at the beginning of the project, and module's interfaces and specifications should be tightly defined. Programming with a size constraint implies to be able to trade functionality for size. These decision should be made at the conception, and dictate the architecture.
And, as constraint brings conflicts between members of the team the manager can make a decision in regard of the "conceptual integrity".
Programming have its technological culture, that can be brought to the programmers by the mean of notebook full of good subroutines describing either compact, or fast algorithms.
Representation of data
The essence of a program lies in the structure used to represent the data.
"Show me your [code] and conceal your [data structure] and I shall continue to be mystified. Show me your [data structure] and I won't usually need your [code]; it'll be obvious."
The Roadmap Hypothesis
There is a need in project management of early documents that help setting the roadmap. These documents should contain informations such as :
- the objectives,
- the budget,
- organisation chart,
- specific requirement (in size, space or whatever),
- estimate forecast.
It can be useful for newcomers to understand quickly the purpose of the project. These documents embody a part of the manager's work :
setting up a direction and try to keep the trail. If a manager review these documents often, it may be a tool of great use that help knowing in which direction inflecting the strategy.
Plan to throw one away : prototyping
In industry, before implementing a great plant, prototypes are often designed, to avoid great mistakes.
In software industry, where new concepts are often introduced for new products, this is mandatory :
Human beings rarely get it right the first time. Therefore to avoid the bad reputation due to redesigning a product that has already been shipped :
"Plan to throw one away; you will, anyhow"
The only constancy is change itself
By accepting to prototype, you fully accept change as a being normal in the lifecycle of your product. Change is unavoidable : as your product is being defined, customers feedbacks, or other reasons might compel you to change some of your product features.
Planning the methods for change
To be able to face the change, you have to have a design, and working methods suitable with it ; the use a modular conception, and the use of high-level language and auto documentation of code, powerfully helps change management.
Good versioning system and methods are also necessary.
Planning the organisation for change
The main reason why programs are poorly documented, is programmers are reluctant to document their codes. The main reason why programmers are reluctant to document their design is they are exposing themselves to criticism. Hence, if the organisation is threatening in anyway, programmers won't document until their design will be fully defensible.
Structuring an organisation for change is both more sensible and tricky than structuring a system for change.
To enforce the surgical team architecture you need to have technical members being respected, and managers that are legitimate. Social barriers are the strongest obstacle against an organisation suitable for change.
To be able to face change, you need to have available technical skillful members in backup. However, management is more prestigious than technical job, therefore to keep these people, you need to break this culture that exist in most company. For instance IBM, used to have two separates social ladders for both technical and managerial members of its teams. Technical and managerial members of the teams might be trained in both domain, so that they understand each other better. This drastically diminishes interfaces between teams, and increases reactivity.
Penelop's syndroma
Releasing a program does not mean freezing its development : the more eyeballs will meet your programs, the more bugs will be found. Then you enter the program maintenance lifecycle. Often the obvious is fixed, this method implies that in 20 to 50% of the case, a bug fix, will raise another bug. This happens because the bug fixer is not the one who wrote the code. We must then consider that the best method for reducing costly bug-fixing, is :
- a bug proof design
- an easy to understand modular design that prevent bug propagation, and facilitate deep level bug fixing.
A good workman is know by his tools
There is need for common tools so that people can communicate, but the need for personalised tools should be recognised. Therefore teams are to be implied in the tool building process.
Fred Brooks highlight the need for easy to access computer facilities. He highlights the fact that speed is not the point, but that reliability, and ease of use are. Therefore automated process and methods that help developing common practices should be use such as having access to two sets of libraries :
one that is releasable and that very few can change,
another one of libraries in development that should be usable by everyone.
Then, Fred Brooks re-highlights the fact that high level programming, and interactive debugging improve development speed in an order magnitude.
Hatching a catastrophe
" How does a project get to be a year late ... One day at a time"
However the day-by-day slippage is hard to recognise. One of the main method to avoid slippage is the use of :
Milestones
First one must have a schedule, then there is only one revelant rules:
milestones must be a 100% event. Milestones must be sharp-edged unambiguous event so that progress can be monitored precisely ; the worst moral killer is a chronic slippage. The best way to recover such a calamity, is then to meet the next milestones on time.
All one-day slippages are not the announce of a catastrophe, to recognise those who are revelant, a critical-path schedule that emphases the key milestones is a good tool.
It should identifies the dependencies, and the forces available so that each one's responsibility can be identified early.
Reducing conflicts between managers
Another classic cause of slippage, is first line managers underestimate slippage so that they do not face a negative decision of their boss. As in the documentation aspect, the feeling to face an oppressive hierarchy will diminished confidence and therefore the accuracy of informations that will be given back.
An up to date schedule estimacy is anyway necessary not only for releasing on time, but also because it has proven to have positive effects on the morale of the teams, and can points up critical elements that can be moral-killers.
The other face
The other face of a program is what is seen by other programmers or users : documentation. Without it, nothing can be done with any program. Therefore this chapter is here to describe some of the best practices concerning documentation.
First Fred Brooks notices that developers documentate their work only when their managers show them that :
- They do it,
- And how to do it.
- The goal of the program
- The environment that is needed to run the program.
- The domain of use and the valid input that can be filled in.
- A detailed description of the program's mechanism.
- The description of normal/abnormal ending, including if necessary error codes.
- The description of options: how to use them, and the way they work.
Self documented code is code written in such a way, it can be clearly understood by other programmers this includes :
- Separating independent functions in independent files.
- If a function should be described, the prose should be incorporated at the very beginning of the prototype.
- rather than documenting standard algorithms, it is better refer to standard literature: be confident in the reader's knowledge.
- Declare variables and functions with names that make sense.
- Always mark the initialisation procedure.
- try to name accordingly with the standard literature when implementing a standard algorithm.
- Use indentation to highlight your code structure.
- Use comment mechanism.
- A log of all changed : the revision history.
- An explanation of the layout of all files used.
- A description of the concept, and some of the choices of implementation.
- A description of the algorithm that are used.
No Silver Bullet: accident will happen
1975 edition
"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."
Software engineering is made of two parts: dealing with the essence and dealing with the accidents.
We can define the essential part of the job as the design, the specification, the testing of the conceptual construct. Fred Brooks believe this part is being the hardest, and that every gain on this domain have a great impact on the accidental one. The accidental part consists of mapping the concept to reality through all kind of artificial barriers that are not inherent to the conception. These barriers can be hardware constraints, inadequate programming language, inadequate structure ....
Werewolves are terrifying creatures that once familiar, become terrifying horrors. Software projects can slip to horror through usually innocent forms such as missed schedule and then blow your budget or become a flawed product. But, as we look at the technique available (in 1975) in both programming and management, we cannot figure a technique that will improve simplicity, reliability, or productivity in an order of magnitude.
Fred Brooks view is that through no road are evident, he thinks the only way to improve software engineering is through the propagation and the development of best practices .
Essential difficulties
The toughest part is building and testing. Compared to design flaws, syntax errors are a fuzz. Therefore, as this is not linked directly to computer technique, building software will always be hard, and there is inherently no silver bullet for it.
The very nature of software design is complexity : it is a an adjustment of several unique pieces together, and scaling up the product does not decrease it. The complexity is inherent to design, hence design that abstract the complexity of a concept, wash away part of its essence.
Complexity is a necessary because it is linked to functionality. However, it rises several unpleasant issues :
- size growth is non-linear to complexity,
- communication among members increase with complexity,
- the difficulty to understand the features of the product,
- back doors, ....
Accidental difficulties
Tools and technical environment
In software development, one of the major difficulties is to transcript an abstract concept in a peculiar -physical, computer understandable- representation without losing too much of the conceptual integrity. Therefore, languages are to be chosen carefully in respect with this point.
In respect with this aspect, high level object oriented programming can prove to be a breakthrough : object oriented language constraint programmers to follow standard design techniques by the means of their syntax (interface description is mandatory in Ada for instance).
Therefore, since these are high level languages, programmers can concentrate more on design and less on implementation (hardware dependent programming).
A coherent environment should also be interesting, that can help capitalising knowledge through system-programming common philosophy. This implies, there are common representation of concept such as file, process, among system and user programming. Then you can have unified tools, and coherent API can be used.
Powerful editing tools are interesting but bring marginal gain since they only impact accidental difficulties.
Freeing developers from non-thinking activities such as resource management is definitely interesting.
One of the main difficulty is also the wide gap between average practices and best. Therefore, one need a system that can help disseminating them. In the mid 70's, Fred Brooks' proposal in this context is the use of an expert system.
Future expected gain on conceptual difficulties
Do not build at all
Since developing a software product is really risky for a firm, why should one take that risk? With the development of software integrated such as database, business integrated, and the power that can be brought to user by a Personal Computer, is there still a need for developing a peculiar product? For most of the organisations equipping the front line workers and most of the teams with good generalised software should be sufficient for most of the need.
Do not building, grow your software
Complex software while being built, is always shifting. And, as redesigning a product can bring so much cost-full incoherences in the conceptual integrity, the management of the project should take it into account by two ways :
- Rapid Prototyping and Requirement refinement , in order to set up the real customers need a prototype should always be made, so that the customers can test the software consistency according to its needs,
- Incremental development , complex system adjust themselves in order to reach their attractor, why not doing it with complex softwares? Software project management should not be like managing the production of a manufactured good: all components are built separately, and then gathered together ; they should be assembled since the beginning.
The Human factor: great designers
Improving softwares implies de facto improving the development, and this can be done only through people. Good designs can be obtain by following good practices. Good practices can be taught, and spread through literature, and curses ...
Nevertheless, Fred Brooks do not believe in a strong breakthrough by doing this, he rather thinks that designing is a creative process , and that the only way to have good design is to have great designers. He then point out that great designs usually from few minds considering UNIX, APL, PASCAL, in contrast with COBOL, PL/I and MS-DOS.
As a consequence organisations should grow great designers. To do so some steps are obvious :
- identify them early, the best might not be the most experienced
- mentor their careers
- grow their competence and responsibility through a career plan
- provide a stimulating environment that helps designers to interact with each others
No Silver Bullet refired : 10 years later
1986
Essentially, these refinements are brought through answers made to NSB.
Lars Sodhal
"In my experience most of the complexities which are encountered in system work are symptoms of organizatiional malfunctions. Trying to model this reality with equally complex program is actually to conserve the mess instead of solving the problems"
Fred Brooks answer is that most of the complexity, however, is not due to external world. And that progress can be made by adding a few complexity while building :
- Hierarchically, by layered modules, or objects,
- Incrementally, so that the system always work.
Harel's candidate for silver bullets
Harel's view is that conception will evolve toward diagram : software is by essence topological in nature and this can have natural counterpart in spatial graphical representations. building software.
Jone's Point
Focus on quality, productivity will automatically follow.
NSB 10 years after : so what?
First, Fred Brooks points that there are no easy way of measuring productivity and therefore, the gain cannot be measured, so he makes a balance of his assertions on a point to point basis.
Buy don't build?
It has proven to be correct, the mass market grew and brought generalised applications to most of the workers.
Corrolar: the birth of power users
Fred Brooks noticed he underestimated the customisation of software packages, that can make affordable computer powerful enabling users to create set of powerful personnalized sharp tools.
OO-programmation: will a brass bullet do?
First, Object Oriented programming had a strong growth during the decade, through C++ development for instance. Fred Brooks highlight the master quality of OO programming :
- modularity
- encapsulation
- inheritance, (and therefore hierarchy)
- strong abstract data typing
Fred Brooks sees in this a severe case of the management malady concerning methodological improvement. No prevision as been made on the expected return on the investment. Therefore, managers were expecting short term returns, while designing methods are long term investments. He also notices that, for instance, people wanted to reuse without noticing that it doubles the overall time for building software due to additional components testing, documentation and so long. Reusable components, cannot be done ex nihilo users and developers should share common notations, concepts and so long. He emphases his point of view with Jones report that shows that 10% at most of programmers and customers reuse components, and that in most of cases this is due to organisational factors.
A native speaker routinely uses 10000 words. With component reusing, the vocabulary grows in such a gigantic way, that without having reflection on the way to extend the language, people will be unable to use components, and anyway increasing the complexity in a language will result of additional accidental difficulties.
1986 Conclusion
Due to the inherent nature of software, the position is unchanged, the SB bullet search being in many aspect the quest for the philosophical stone.
No Silver Bullet refired : 20 years later
1995
At first, there is a NSB 20 years later, because this topic is still revelant, one explanation is that the Mythical Man Month is not about software, but is about people, teams, and project management, and therefore, its obsolence should be low.
Conceptual integrity
By behaving coherently, the product will be perceived as easy to use by the users. Therefore, it should be design by few minds. However, for big projects implying many minds cooperating together, keeping the conceptual integrity represents a great difficulty. To achieve it some important action must be undertaken.
The architect
There ought to be on each project very few people that have a mental representation of the whole project, and that have an idea of the detailed specifications of each components.
A dedicated necessary architect
There should be a clear boundary between implementation and architecture : these are two separates tasks and there is a lot of (creativity|work) on each side.
Recursive architects if needed
If a system is so big, you cannot figure how to have only one architect, then you can design subsystems for which an architect is necessary and that will report to the master architect, this can be done recursively.
The second system effect
With the development of software packages made of general tools such as business integrated, there is a risk for the second system effect : with a general tool one has to assign priorities to each features to be implemented.
Balancing features and performance
For generalised products it is more trickier to define a set of useful functions in regard with the customer needs.
It is all the more difficult that the variety of functions impacts both performance, and conceptual integrity (and therefore the ease of use). For mass market products that survive long enough, the temptation is very strong, the pressure for evolving coming from customers being relayed by the marketing staff. Often, the architect is gone, and the products get overloaded with marginal features ( MS Word 6.0 effect).
Avoiding the second system effect
With a product full of features, there is a need for many designers. However, each one designing in respect with his mental representation of what a user is : by having different assumptions on the behaviour of user, they will have different assumptions on what they need and feel. Therefore, there is a need for the definition of a consistent mental representation of the user that should be defined at the beginning of the conception. One should know
- who are the users
- what they need
- what they think they need
- what they want
The WIMP interface
Windows, Icons, Menu, Pointing interface
This has been the major breakdown between 1975-95. One of the main reason of this success is the conceptual integrity ensured via the metaphor of the « desktop ». However, commands in this environment are made two components : a verb chosen with a menu, and complement that is selected, therefore the unique mouse tends two travel from menu two workplace, and vice versa, making the pointer do the job of two. The brilliant solution found by apple designer was too implement keyboard shortcuts for all high frequencies operations being located at lower left corner of the keyboard, thus users can both use the normal intuitive coherent interface, and also the « power user » mode. The ground of such a success is that this standard was built in the computer. Therefore, performance was incentive for programmers. Direct incorporation is more efficient than software specification for standard enforcement.
Spiral development model : Don't plan to throw one away!
« The plan too throw one away » is valid if ever you are using a classical water fall model. However to avoid it you can directly use an incremental model.
This plan is a solution to the waterfall model, the waterfall is the problem. It denies the possibility of feedbacks while conceiving and implementing the product. In fact the philosophy maybe grow the product, don't build it. Software engineering is not building engineering : the plan of the product must change while being built. Fred Brooks preconisations are
- the system must compile very early
- release early, so that feedbacks can came fast,
- adopt a build-to-budget strategy.
Prototyping or incremental models
Prototype are (Harel's definition):
« A version of a program that only reflects conceptual concerns, and not implementations »
For interfaces, you can do a prototype to test user reaction to the ergonomy, while the prototype is just an empty shell without any functionality.
Information hiding
At first, F. Brooks conception is that every programmers should have automatically access to the whole documentation. Then he recognise the validity of David Parnass' point of view : a programmer should have access only to the informations that concerns him so that communication is more effective. This can be done through the mechanic of object programming : you specify to each programmers his roles in implementation through abstract data type and they can use other chunk of programs through the use of inheritance.
Brooks' Law validity
Through data, one can notice that the trade off between men and months is far from linear. But it has also given hints concerning project scheduling :
- There is a cost-optimum schedule shipment.
- If a project schedule is over estimated, it will take longer : people with more time take more times. But over cost are low.
- If a project schedule is underestimated, over cost will be strong.
- Hardly any process succeed in less than 3/4 of the calculated optimum schedule regardless of the number of men applied.
Mythical Men : Peolpeware
The central theme of this book is software are made by men, and the raw material for success is creativity. Therefore the quality of people their organisation and management structure is much more important than the tools or methods they are using. Brooks enforces its intuition with Boehm's study : the quality of a team is the largest factor for success in software development.
Then, management's attributions is not to make people work, but to give them the mean to work. For instance De Marco and Lister show a positive correlation between quiet workspaces and quality, and defect level. And anyway, does it really matters whether the effect is due to the place or whether this is due to the fact this people like to be cared : it helps you keeping them, and attracting the better ones.
Subsidiarity : giving up power
Creativity has to be unleashed, this is the managerial staff's job. The lesser the social authority is, the more creative will people be. To enforce the social contract, organisation has to be efficient, but it will more efficient if it can give up small part of authority to semi-autonomous teams. The Empowerment of such teams strengthen entrepreneurship, and creativity adding value to the whole organisation. By delegating, the authority will be happier and more prosperous. (Pope Pius IX).
Evolution of the computer industry
First, microcomputer has changed the face of software. Each one can have a decent computing power at home ; people can then experiment interact with new fields of creativity. It has also changed software conception : the WIMP interface has sprung everywhere.
But above all it has changed the software industry. The market has been segmented in two folders: on one hand due to OS coalescence there is the possibility to product software packages for a mass market, and there is also the need for custom applications. Software industry has split in «niche».
Programming evolution
They are a lot of new products embedding programming facilities such as excel, hyperstack. Therefore one can notice the emergence of a new culture of meta-programming ; advanced user can make dedicated program easily.
Strategic evolution
Because of the software evolution, enterprise can buy software packages, and now more than ever they can have software made outside of their society. Therefore it implies a new way of conceiving software engineering : to enforce the integrity of a product made of bricks made by different societies, to design such system, and to keep control other the product a new role needs to be defined in societies.
As complexity is still rising, the Tar Pit will still be an issue for long, and this can be achieved if we learn to compose in larger units, to adapt ourselves to proven engineering managements methods, to use liberally of common sense, and if above all we keep the humility to recognise our fallibility and limitations.
Comment : creativity and organisations.
This book is very dense, quite well organised. However the pit, is some really interesting ideas are hidden in the chapters, such as data and code
, therefore it needs a very careful reading. Punctual striking ideas
being mixed with interesting thesis.However, it is interesting to notice that by changing the postulate concerning the place where software development takes places you can easily have the same effects but totally different conclusions.
Fred Brooks thesis that men and their creativity is the wealth of the enterprise fits the actual trend of focusing on human beings. Fred Brooks thesis are surprisingly still up to date.
Today's reference in software management is Steve Cownel's Complete Coding . In this book he refers to most of Fred Brooks assertions and bibliography.
If Fred Brooks proposal are still up to date, it first means that he was right, then it also means that is proposals were hardly adopted in firms.
The first point I would rise is that the Mythical-Man Month diagnoses «peopleware» as the strength of enterprises, but that it did not take into account the behaviour of men interacting in an organisation : Fred Brooks proposal of focusing on «low ranked» workers skills in the organisations rather than on «high level» one (such as managers or top executive) infringes the normal social convention.
The point of view defended by L'acteur et le système (Michel Crosier and Erhard Friedberg) is that in organisations, actors are neither fully submitted to the rules nor totally free; there are playing a game to express their own freedom of choice. This freedom is expressed by a role playing game which issue is the increase of the «uncertainty zone». As a result, in actual organisations, some major actors can be identified :
- the expert, relying on his exclusive excellence in a field of competence to be recognised,
- the communicants, relying on his domination over the flux of information to ensure his position,
- the rule maker, relying on its capacity to edict contradicting rules so that he has a mean of pressure on its team members
- the wise men, whose experience are valuable in order to avoid the second system effect,
- the creatives, who core value makers that should be freed from almost any usual constraints proper to organisations (cf the surgical team).
But, then : why is this book so successful? I would say Fred Brooks proposal his playing the right note that resonates among developers, and software team leaders especially: they would like to be recognised in their role for their uniqueness (or creativity) in the organisations, the motto being : I have something unique, I am a creator. These proposals have all the more resonance that they look reasonable and feasible that it is the dream come true at a hand's grasp. However, one reason why Fred Brooks is still up to date seems it is unrealistic.
However I would propose to have a look on Free Software and Open Source organisations and practices ( The Cathedral and The Bazaar ). Free software practices can be illustrated by the development of the linux kernel. At first, there was a brilliant creative mind whose motto was release early, release often. This is very close to the spiral development model.
Then there was the systematical use of mailing list.
Mailing lists
- permits that all users access equally to informations,
- hide the difference in terms of experience and diploma,
- permits that all user can identify the co-workers they need on a project.
Then I would point at the most incentive reward that was used by this project : recognition. Each coders that contribute in ensured is name will be known from all because the licence implies is name cannot be taken away from the code, and that no one can use the code, redistribute the program without respecting this point.
Then Linus Torvald chooses to develop a free implementation of the Unix standard, this implying a strong conceptual integrity.
Then one of the most audacious statement of this project who was able have over thousand people work together for at least 7 years (until today at least) was that no management was needed because :
- if several programmers are implementing the same functionality it does not matter ; they would merge, the community choosing the best idea,
- leader are rising because of their natural authority,
- the project split in new sub-project naturally as soon as new leader is emerging, therefore the size of teams is always efficient
This «success story» was only feasible because men were freed from organisational constraints and of the Role Playing Games that take place in the enterprise. Essentially, linux development was made by coders (creatives) without any other functions interfering with their job.
Now, the success of Linux inspire firms even in the organisational field. They focus on tools and methods, to be successful, I would give as an advice that they should not forget that «peopleware» is the ground of these improvement.
Notes
System programming is programming independently from any operating system (such as Mac OS, windows, Unix... ) and of it is also the development of the tools that comes with (development tools, system tools, documentation ...).
A mailing list is a community of user that receives mail broadcasted to all the users that have willingly subscribed it. It enables people to chat on a common subject of interest.