The Mythical Man Month

The Mythical Man Month

Author

Fred Brooks

Year
1975
image

Review

This book is consistently referenced by people in the technology industry, but few have read it. It was written in 1975 - how we build software products has changed a lot since then. Some of the observations in this book are timeless, but equally if you’re a Product Manger there are many chapters and pages you should skip (unless you’re keen on understanding the memory management challenges of yesteryear).

I think a lot about what books and material to read, I’m aiming to read more timeless texts and reduce my recency bias. That said - reading books about software development written 50 years ago is a bit of an art in and of itself.

You Might Also Like…

image

Key Takeaways

The 20% that gave me 80% of the value.

  • Many large software projects have been swallowed. Some emerge with running systems, few meet goals, schedules and budgets.
  • No one thing seems to cause the difficulty. The accumulation of simultaneous and interacting factors brings slower and slower motion.
  • We hear and believe tales of a couple of programmers in a garage creating software faster than larger teams in offices.
  • Programming is fun because:
    • the sheer joy of making things
    • the pleasure of making things that useful to other people
    • fascination of fashioning complex puzzle-like objects
    • the joy of always learning
  • The woes of the craft:
    • One must perform perfectly (computers are strict)
    • One rarely controls the circumstance on ones work, or its goal
    • Dependence upon others and their programs
    • Designing grand concepts is fun, fixing bugs is just work
    • Closing out bugs is not linear, its quadratic approach that seems to take forever
  • Most software projects go awry due to lack of calendar time (vs all other causes combined)
    • We are bad at estimating
    • Our estimating techniques confuse effort with progress, hiding the assumption that men and months are interchangeable
    • Progress is poorly monitored
  • When we detect a delay, we add more people (which can make things worse not better)
  • Most programmers are optimists (probably because learning to program is so frustrating only the optimists remain). This time it will surely run.
  • The probability of a large programming project going well, with lots of tasks that depend on each other needing to go well is very small
  • The person-month as a unit for measuring the size of a job is dangerous and deceptive. It implies that men and months are interchangeable.
    • This would only be true if tasks can be perfectly divided and there be no communication overhead
    • This is true of reaping wheat but not systems programming
  • When a task can't be partitioned, more people don't help (it takes 9 months to make a baby)
  • When a task can be partitioned, but with communication overhead, you need to add the overhead to the work.
    • Theres both training and intercommunication. Intercommunication is tricky. The number of nodes increases exponentially (the power of network graphs in reverse). Dumbar's number style effect.
  • Since software construction is inherently a systems effort, an exercise in complex interrelationships communication effort is great, and dominates the effect of adding more people to the project.
  • We expect there to be no bugs.
  • Failure to allow enough time for testing is disastrous. Since the delay comes at the end of the schedule, no one is aware of schedule trouble until the delivery date. Cost per day is also normally at its highest at this point
  • Urgency may govern the scheduled completion of the task, but it cannot govern the completion. As with cooking an omelette. If its not ready, you have 2 choices. Eat it raw or wait.
  • Adding manpower to a late software project can make it later (training and repartitioning of the system)
  • People often prefer small teams of talented people. The number of people being coordinated has a communication cost (and correcting the mistakes made in communication - bugs)
    • Variance of productivity between the best and worst programmers is huge. 10:1 between the best and the worst . No correlation between experience and performance.
  • One therefore wants to build the system with as few people as possible?
    • If a 200 person project has 25 managers who are the most competent and experienced programmers, fire the 175 troops and put the managers back to programming
    • The small sharp team concept is just too slow for big projects.
    • The Team Size Dilemma: For efficiency and conceptual integrity, one prefers a few good minds doing design and construction. .Yet for large systems, one wants a way to bring considerable man power to bear, so that the product can make a timely appearance.
  • Mills's Proposal → Each segment of a large job can be tackled by a small surgical team
    • Instead of everyone cutting away at the problem, one does the cutting.
    • Everyone else gives him the support needed
    • Few minds involved in design and construction, many minds brought to bare…
    • Surgeon, copilot, administrator, editor, 2 secretaries, program clerk, toolsmith, tester, language lawyer
  • To build things that take 5k person years you need multiple surgeons who have to spend all of their time talking to each other about the system architecture.
  • Conceptual integrity is the most important consideration in system design. Cathedral design often changes in construction. It's hard to get generations of people to stick to the original design. Reims managed this.
    • Conceptual integrity in turn dictates that the design must proceed from one mind, or from a very small number of agreeing resonant minds.
    • BUT Schedule pressures dictate though that we need many builders. So we need either:
      • Careful division of labor between architecture and implementation
      • New way of structuring programming implementation teams discussed in the previous chapter
  • Implementers raise 3 objections to architects doing the design:
    • Specifications would be too rich in function and will not reflect practical cost considerations
    • Architects will get all the creative fun and shut out the inventiveness of the implementers
    • Many implementers will have to sit idly by while the specifications come through the narrow funnel that is the architecture team
  • The Second-System Effect: There's a tendency of architects to over design their second large system. Using all the frills and ideas that were cautiously sidetracked on the first one. Be wary of the special temptations of the second system
  • Written Specifications are necessary tool - although not sufficient. It describes and prescribes every detail of what the user sees. It is the chief product of the architect. Feedback cycle - from users and implementers allows you to iterate on the manual. Implementers need there to be strict versioning. The manual must describe what the user sees, and refrain from talking about what they don't see. That is the implementers business. His design freedom must be unconstrained. The style must be precise, full and accurately detailed.
  • Formal Definitions. Language is not naturally precise.Need a formal definition and a prose definition. A formal definition is an implementation and an implementation is a formal definition (ask the machine)
  • The purpose of the organisation is to reduce the amount of communication & coordination necessary. Division of labour and specialisation of function. Tree like structure reflects the need for diminishing need for detailed communication. A tree is a structure of authority and responsibility. The communication structure is should not be limited to single lines. The communication structure should be a network not a tree.
  • Thinkers are rare, doers are rarer and thinker-doers are rarest.
  • Data for building isolated small programs are not applicable to programming systems products.
    • The bigger the product the harder it is to build and test. You can't extrapolate 100m sprints to a 3 minute mile
    • Typically programs of half the size take a quarter of the time
    • Effort goes up as a power of size even when no communication is involved except that of a man with his memories.
  • Portman's Data found programming teams take 2x as long as they think. The miss was because the teams spent only 50% of the working week programming, the rest was debugging. Machine downtime. Other jobs meetings etc. We overestimate the amount of time we get to spend on programming. Aron’s data …the more interactions the fewer lines of code produced.
  • The reasons for writing decisions down:
    1. Gaps in your own logic appear
    2. Communicate to others
    3. Give you a database and checklist. You can review them to see where you are.
  • Plan to Throw One Away. With most complex systems, the first system built is rarely usable (performance flaws).You'll have to make some major changes and rebuild. The only question is whether to: plan in advance to build a throwaway OR promise to give a throwaway product to paying customers.
  • The only constant is change itself. Once you realise you need to build and throw away a pilot. It's clear you should embrace change. Accept change as a way of life. The threshold for changes must be raised overtime, otherwise no product ever emerges.
    • Plan the system for change… Modularisation etc
      • ‣
      Plan the organisation for change…
      • By documenting a design. You open yourself up for criticism
      • If you don't have phycological safety, then nothing is going to be documented
      • Make peoples skills as general as possible, so you can move them where needed
      • Keep a few in reserve, so you have flexibility to react to priorities
      • Keep managers interchangeable too
      • Keep managers in a position to code. Building surgical teams around them helps this
      • Minimal interfaces and interactions of surgical teams, make it easier to change things
  • Bugs are 40% of the cost of building a system. The more users you have, the more bugs they’ll find. There’s a delay to bugs being found after release. Every time that you fix a bug, theres a 20-50% chance you introduce one=
    • Repairs increase entropy and disorder of the system. Less and less effort is spent fixing original design flaws - more on fixing the fixes. Sooner or later, fixing ceases to gain any ground. Each forward step is matched by a backward one.
  • Systems program building is an entropy-decreasing process, hence inherently metastable.. Maintenance is entropy-increasing process = which leads to unfixable obsolescence.
  • The crucial task is to get the product defined. Many failures come from areas of the product that were not quite defined.
‣
Top-down design (with step refinement)
  • Start with a rough sketch.
  • Rough task definition and solution
  • Make tweaks to get to what you want
  • From this process you define modules
    • Modules can be refined independently of other work
  • The degree of modularity determines the adaptability and changeability of the program

A good topdown design avoids bugs by:

  1. Clarity of structure and representation makes precise requirements for modules easier
  2. Partitioning and independence of modules avoids system bugs
  3. Suppression of detail makes flaws in structure more apparent.
  4. Design can be tested at each step of refinement. Testing can start earlier.
  • The Flow Chart Curse. Oversold piece of documentation. Keep to one page if you have to use them. Don't do every detail - its a really space hogging way to describe something
  • Using rapid prototyping as part of planned iteration in establishing requirements
  • Grow software organically, adding more and more function to systems as they are run, used and tested
  • The Essence = difficulties inherent in the nature of software
    • Specification, design and testing
    • Complexity: Software is complex - there is no repetition (that's all captured in the software itself). Often complexity is non-linear with size.
    • Conformity: Much complexity comes form conformity to other interfaces
    • Changeability: Pressures of change. Recalls are uncommon in hardware, but ubiquitous in software. All successful software gets changed. Once you get users, you get new requirements. Successful software also survives beyond the life of hardware or platforms, so it must adapt to survive
    • Invisibility: Software is not embedded in space, so it's hard to visualise.
image

Deep Summary

Longer form notes, typically condensed, reworded and de-duplicated.

Chapter 1: The Tar Pit

  • Analogy is dinosaurs struggling in a Tar Pit (like quick sand)
  • Many large software projects have been swallowed. Some emerge with running systems, few meet goals, schedules and budgets
  • No one thing seems to cause the difficulty. The accumulation of simultaneous and interacting factors brings slower and slower motion.
  • We hear and believe tales of a couple of programmers in a garage creating software faster than larger teams in offices.
  • A program is normally morphed into one of these two:
    • Break it into different interfaces with agreed syntax and test the combinations
    • Make a program so it can be run, tested and extended by anybody
  • Programming is fun because:
    • the sheer joy of making things
    • the pleasure of making things that useful to other people
    • fascination of fashioning complex puzzle-like objects
    • the joy of always learning
  • The woes of the craft:
    • One must perform perfectly (computers are strict)
    • One rarely controls the circumstance on ones work, or its goal
    • Dependence upon others and their programs
    • Designing grand concepts is fun, fixing bugs is just work
    • Closing out bugs is not linear, its quadratic approach that seems to take forever
    • Products can be obsolete before completion

Chapter 2: The Mythical Man-Month

  • Most software projects go awry due to lack of calendar time than all other causes combined
  • This is true because:
    • We are bad at estimating
    • Our estimating techniques confuse effort with progress, hiding the assumption that men and months are interchangeable
    • Progress is poorly monitored
    • When we detect a delay, we add more people (which can make things worse not better)
‣
Optimism:
  • Most programmers are optimists (probably because learning to program is so frustrating only the optimists remain). This time it will surely run.
  • The probability of a large programming project going well, with lots of tasks that depend on each other needing to go well is very small
‣
The Person month:
  • The person-month as a unit for measuring the size of a job is dangerous and deceptive. It implies that men and months are interchangeable.
    • This would only be true if tasks can be perfectly divided and there be no communication overhead
    • This is true of reaping wheat but not systems programming
  • When a task can't be partitioned, more people don't help (it takes 9 months to make a baby)
  • When a task can be partitioned, but with communication overhead, you need to add the overhead to the work.
    • Theres both training and intercommunication
    • Intercommunication is tricky. The number of nodes increases exponentially (the power of network graphs in reverse). Dumbar's number style effect.
  • Since software construction is inherently a systems effort, an exercise in complex interrelationships communication effort is great, and dominates the effect of adding more people to the project.
‣
Systems Test:
  • We expect there to be no bugs.
  • Rule of thumbs for scheduling a software task:
    • 1/3 planning
    • 1/6 coding
    • 1/4 test and early system test
    • 1/4 system teal, all components in hand
  • Failure to allow enough time for testing is disastrous. Since the delay comes at the end of the schedule, no one is aware of schedule trouble until the delivery date.
    • Cost per day is also normally at its highest
‣
Gutless Estimating
  • Urgency may govern the scheduled completion of the task, but it cannot govern the completion. As with cooking an omelette. If its not ready, you have 2 choices. Eat it raw or wait.
  • Adding manpower to a late software project make it later. (training and repartitioning of the system)

Chapter 3: The Surgical Team

  • People often prefer small teams of talented people

The Problem:

  • Variance of productivity between the best and worst programmers is huge
    • 10:1 between the best and the worst
    • There was no correlation between experience and performance
  • The number of people being coordinated has a communication cost (and correcting the mistakes made in communication - bugs)
  • One therefore wants to build the system with as few people as possible?
    • If a 200 person project has 25 managers who are the most competent and experienced programmers, fire the 175 troops and put the managers back to programming
    • The small sharp team concept is just too slow for big projects.
  • There is a dilemma.
    • For efficiency and conceptual integrity, one prefers a few good minds doing design and construction.
    • Yet for large systems, one wants a way to bring considerable man power to bear, so that the product can make a timely appearance.

Mills's Proposal:

  • Each segment of a large job can be tackled by a small surgical team
    • Instead of everyone cutting away at the problem, one does the cutting.
    • Everyone else gives him the support needed
    • Few minds involved in design and construction, many minds brought to bare
  • Surgeon, copilot, administrator, editor, 2 secretaries, program clerk, toolsmith, tester, language lawyer

Scaling up

  • The problem though, is how to build things that take 5000 person years
    • A 10 person team can be effective no matter how they're organised (if they're doing everything)
    • The surgical team concept scales, because the surgeon is doing the design. So you only need to get the surgeons to talk to each other. That's how you put 200 people on a problem and face the problem of only coordinating 20 minds (of the surgeons)
    • However, its still tricky to coordinate 20 people.
      • You need a system architect to ensure the system will function
      • The architect must confine himself to architecture.

Chapter 4: Aristocracy, Democracy, and System Design

‣
Conceptual Integrity:
  • Cathedral design often changes in construction. It's hard to get generations of people to stick to the original design. Reims managed this.
  • Systems design suffers from a similar problem, once you allocate tasks to different people.
  • Conceptual integrity. is the most important consideration in system design. You don't want to end up with many good but uncoordinated ideas.
‣
Achieving Conceptual Integrity:
  • Ease of use balance. Ratio of function to conceptual complexity. Neither function nor simplicity defines good design.
  • For a given level of function, specify things with the most simplicity and straightforwardness.
  • Simplicity and straightforwardness proceed from conceptual integrity. Ease of use dictates unity of design, conceptual integrity.
‣
Aristocracy and Democracy:
  • Conceptual integrity in turn dictates that the design must proceed from one mind, or from a very small number of agreeing resonant minds.
  • Schedule pressures dictate though that we need many builders. So we need either:
    • Careful division of labor between architecture and implementation
    • New way of structuring programming implementation teams discussed in the previous chapter
  • Architecture: complete and detailed specification of the user interface.
  • Architecture tells us what happens, implementation tells us how it is made to happen
  • Aristocracy vs Democracy:
    • The conceptual integrity of a system determines its ease of use
    • Good features and ideas that do not integrate with a systems basic concepts are best left out.
      • If there are too many of these ideas, you need to start again with different basic concepts
    • Yes there must be few architects.
    • Setting of external specifications is not more creative work than the designing of implementations. The cost / performance ratio will depend on the implementor
    • If you remove the architecture debate from the implementers, that saves them a huge amount of time.
‣
What does the implementor do while waiting?
  • The architecture manager had 10 good men. They could write the specifications and do it right. It would take 10 months, 3 months more that the schedule allowed.
  • The control program manager had 150 men, he asserted that they could all write the specifications with the 10 architecture men coordinating it. He could do it on schedule. If the architecture men did it, his would be twiddling their thumbs
  • The architecture manager asserted that if the control manger did it, it would not arrive on time, and would be lower quality. He was right on both counts.
  • Schedule time, and the thought of putting 150 people to work swayed the decision.
  • The implementers raised 3 objections to architects doing the design:
    • Specifications would be too rich in function and will not reflect practical cost considerations
    • Architects will get all the creative fun and shut out the inventiveness of the implementers
    • Many implementers will have to sit idly by while the specifications come through the narrow funnel that is the architecture team
  • The creative effort has 3 phases: architecture, implementation and realization.
  • These can begin in parallel and proceed simultaneously.
  • The implementer can start with a vague assumption.
  • Long before the external specification is complete the implementer has plenty to do.
  • Conceptual integrity does require that a system reflect a single philosophy and that the specification as seen by the user flow from a few minds.

Chapter 5: The Second-System Effect

If you separate architecture from building responsibility. What stops the architect from enthusiastically inventing too much? Well - communication between the two.

‣
Interactive Discipline for the Architect:
  • The architect works against a budget.
  • Often, the bids exceed the budget (of the implementor)
  • The architect then revises the designs, they discuss with the implementor ways to cut back work
  • The architect can get bids quickly from the implementor. But there's only one implementor, and so they can raise or lower their bids as they to match their passion for the design.
  • The architect can either cut the design or challenge the estimate.
    • The architect can only suggest
    • Often the builder will counter with some changes to the design
‣
Self Discipline:
  • There's a tendency of architects to over design their second large system
  • Using all the frills and ideas that were cautiously sidetracked on the first one
  • Be wary of the special temptations of the second system

Chapter 6: Passing the Word

  • Assuming that you have great architects.
  • How can you make sure that everyone hears, understands and implements their decisions
‣
Written Specifications - The Manual
  • Is a necessary tool - although not sufficient
  • Describes and prescribes every detail of what the user sees
  • It is the chief product of the architect
  • Feedback cycle - from users and implementers allows you to iterate on the manual
  • Implementers need there to be strict versioning
  • The manual must describe what the user sees, and refrain from talking about what they don't see. That is the implementers business. His design freedom must be unconstrained.
  • The style must be precise, full and accurately detailed.
  • Manuals tend to be dull reading, but precision is more important than liveliness
‣
Formal Definitions
  • Language is not naturally precise.
  • Need a formal definition and a prose definition
  • One must be the standard, and the other must be derivative.
  • A formal definition is an implementation and an implementation is a formal definition (ask the machine)
‣
Meetings:
  • Meet weekly, for half a day. All architects, implementer representation, market planner representation.
    • Anyone can propose problems or changes. Usually circulated in writing before the meeting
      • The group tries to invent many solutions to the problem
      • Then a few solutions are passed to one or more of the architects for detailing
    • Why these meetings work
      • The same people - architects, users, implementers. Meet weekly for months, nobody has to be brought up to speed
      • The group is bright, resourceful, well versed in issues, deeply involved in the outcome.
      • When problems are raised, solutions are sought within and outside the obvious
      • Formality of written proposals focuses attention, forces decision, avoids committee-drafted inconsistencies
      • The clear vesting of decision making power to the chief architect avoids compromise and delay
    • Before a major freeze for the manual, clear the backlog of debates and disagreements.
‣
Multiple Implementations (Or modules)
  • Sometimes the machine and the manual will disagree
  • Often people choose to change the manual, as its cheaper than changing the machine
  • This isn't true though, when you have a complex system with lots of modules
‣
The telephone log
  • If an implementer is puzzled by the manual. They should call the architect and log the conversation.
‣
Product Test
  • The project managers best friend is his daily adversary - the independent testing bod
  • An independent technical auditing group keeps you honest

Chapter 7: Why did the Tower of Babel Fail? (Project Workbook etc)

‣
A management audit of the babel project
  • A clear mission
  • Manpower
  • Materials
  • TIme
  • Adequate technology

They failed in communication and organisation.

How should teams communicate?

Informally - make hundreds of cals

Meetings - Regular project meetings, technical briefings, Workbook - A formal project workbook must be started at the beginning. This deserves a section by itself

‣
The Project Workbook
‣
What:
  • A structure imposed on the documents that the project will be producing anyway
  • All the documents need to be part of this structure. Objectives, external spec, interface spec, technical standards, internal spec and admin memorabilia
‣
Why:
  • Technical prose is almost immortal.
  • Control of the distribution of information - so that information gets to the people who need it
  • Number all the memoranda
  • There should be a tree structure, allowing distribution lists to be maintained by sub-trees
‣
Mechanics:
  • Gets worse non-linearly as size increases
  • The need for a structured workbook increases as the size of the workbook increases

2 schools of thought. See everything and all the changes, or only what you need to see

The purpose of the organisation is to reduce the amount of communication & coordination necessary

  • division of labour and specialisation of function
  • tree like structure reflects the need for diminishing need for detailed communication
  • tree is a structure of authority and responsibility
  • the communication structure is not limited to single lines. The communication structure should be a network not a tree
‣
Each tree would need
  • A mission, a producer, an architect, a schedule, a division of labour, interface definition
    • A producer assembles the team, divides the work, established the schedule . Acquires the resources needed. Communication upwards, sideways and within the team. Establishes the pattern of communication and reporting within the team. Makes sure the schedule is met, shifting resources and organisation to respond to change
    • An architect conceives the system to be built, identifies sub parts, how it will look from outside, sketches internal structure. He provides unity and conceptual integrity. As technical problems arise, he invents solutions for them or shifts the system design as required. Inside-man at the skunk works.
    • They can be the same person. Rare to find someone with technical and management talent.
    • Thinkers are rare, doers are rarer and thinker-doers are rarest.
    • On a larger project, the roles are full-time jobs.
    • The producer might be the boss, the director his right hand man

Chapter 8. Calling the shot

  • The coding is only one sixth of the problem
    • Planning time, coding, component test, system test.
  • Data for building isolated small programs are not applicable to programming systems products.
    • The bigger the product the harder it is to build and test
    • You can't extrapolate 100m sprints to a 3 minute mile
    • Typically programs of half the size take a quarter of the time
  • Effort goes up as a power of size even when no communication is involved except that of a man with his memories.
image
‣
Portman's Data:
  • Found programming teams take 2x as long as they think
  • Found the miss was because the teams spent only 50% of the working week programming
    • the rest was debugging. Machine downtime. Other jobs meetings etc.
  • We overestimate the amount of time we get to spend on programming
‣
Aron's Data:
  • Very few interactions: 10,000 instructions per man-year
  • Some interactions: 5,000
  • Many interactions: 1,500

The more interactions the fewer lines of code produced.

Chapter 9: Ten Pounds in a five-pound stack

  • Not really relevant. Talking about the cost of storage.

Chapter 10: The documentary hypothesis

  • Examines the documents needed on different projects to see if there is a theme.
    • What: Objectives + Product Specifications
    • When: Schedule
    • How much: Budget
    • Where: space allocation
    • Who: org chart
  • The reasons for writing decisions down:
    1. Gaps in your own logic appear
    2. Communicate to others
    3. Give you a database and checklist. You can review them to see where you are.

Chapter 11: Building tips, planning tips

‣
Plan to Throw One Away
  • With most complex systems, the first system built is rarely usable (performance flaws).
  • You'll have to make some major changes and rebuild.
  • The management decision is not whether to build a pilot system and throw it away (that will happen anyway)
  • The only question is whether to:
    • plan in advance to build a throwaway
    • or promise to give a throwaway product to customers
‣
The only constant is change itself
  • Once you realise you need to build and throw away a pilot.
  • It's clear you should embrace change
  1. Accept change as a way of life
  2. The threshold for changes must be raised overtime, otherwise no product ever emerges
‣
Plan the system for change
  • Modularisation
  • Sub-routining
  • precise definition of interfaces and documentation of them
  • High level languages. Self document techniques.
  • Numbered versions.
  • Schedule - freeze date, after which changes go into the next versoin
‣
Plan the organisation for change
  • By documenting a design. You open yourself up for criticism
  • If you don't have phycological safety, then nothing is going to be documented
  • Make peoples skills as general as possible, so you can move them where needed
  • Keep a few in reserve, so you have flexibility to react to priorities
  • Keep managers interchangeable too
  • Keep managers in a position to code. Building surgical teams around them helps this
  • Minimal interfaces and interactions of surgical teams, make it easier to change things
‣
Two steps forward, one step back
  • A program doesn't stop changing when delivered to a customer for use
  • Allow for maintenance
  • The maintenance cost is usually about 40% the cost of building it
  • Strongly affected by the number of users. More users find more bugs.
  • Theres a delay to bugs being found after release
  • Every time that you fix a bug, theres a 20-50% chance you introduce one
image
‣
One step forward and one step back
  • Number of modules increases linearly with release number
  • Number of modules affected increases exponentially with release number
  • Repairs increase entropy and disorder of the system
  • Less and less effort is spent fixing original design flaws - more on fixing the fixes
  • Overtime the system becomes less well ordered.
  • Sooner or later, fixing ceases to gain any ground. Each forward step is matched by a backward one.
  • Things are always at their best at the beginning.
  • Systems program building is an entropy-decreasing process, hence inherently metastable.
  • Maintenance is entropy-increasing process = which leads to unfixable obsolescence

Chapter 12: Sharp tools

  • The principal problem is communication. Individual tools hamper rather than aid communication.
  • Technology changes, so tool lifetime is short.
  • More efficient to have common development and maintenance tools
  • The manager of a project needs to set aside time for building common tools

Chapter 13: The whole and the parts

  • How do you build a program that works?
  • How do you test a program?
  • How do you test a program as part of a larger system?
  • The crucial task is to get the product defined. Many failures come from areas of the product that were not quite defined.
    • Function definitions. Specifications. Exorcism of frills of function all reduce the number of bugs

      • Testing the spec

    • Before code exists you can test a spec. Developers won't tell you they don't understand it so you can get a 3rd party involved
      • ‣
      Top-down design (with step refinement)
      • Start with a rough sketch.
      • Rough task definition and solution
      • Make tweaks to get to what you want
      • From this process you define modules
        • Modules can be refined independently of other work
      • The degree of modularity determines the adaptability and changeability of the program

      A good topdown design avoids bugs by:

      1. Clarity of structure and representation makes precise requirements for modules easier
      2. Partitioning and independence of modules avoids system bugs
      3. Suppression of detail makes flaws in structure more apparent.
      4. Design can be tested at each step of refinement. Testing can start earlier.

Structured programming: didn't understand this.

‣
Component debugging
  • There's been an evolution overtime:
    1. On-machine debugging
    2. Memory dumps
    3. Snapshots
    4. Interactive debugging
‣
System Debugging
  • The unexpectedly hard part of building a programming system is system test
    • Bolt-it-together and try approach
      • There will always be interface bugs and component bugs
      • The sooner you put them together the sooner the bugs will emerge
      • Use the pieces to test each other - avoids building testing infrastructure
    • Documented bug approach
      • Test and identify the compents first
      • Once you know the bugs, put the system together
      • So you know the expected behaviour of the system because you know the bugs
    • Build plenty of scaffolding
      • Programs and data for debugging
      • You could have half as much code for in scaffolding as there is in product
      • Dummy component, miniature file, dummy file, aux programs
    • Control stages
      • Tight control during test is important
      • Somebody must be in charge - they authorise changes
      • Controlled copies of the system.
      • Logging changes.
    • Add one component at a time
      • Optimism and laziness mean that we don't do this
    • Quantize updates
      • As the system comes up, the component builders will from time to time appear
      • The replacement of an old component should be tested as thoroughly as a new component

      Chapter 14: Hatching a Catastrophe

    • Schedule slippage is often down to small issues, not major calamities
    • Day to day slippage is harder to recognise - harder to present - harder to make up
      • A person being sick. The machines going down for a day.
      • Postponing an activity by a day or a half day is what kills projects
      • The schedule slips one day at a time

      How to control a big project on a tight schedule?

    • Have a schedule.
    • Milestones with dates.
    • Milestones must be concrete, specific, measurable events
    • Coding is 90% finished for half the time
    • Debugging is 99% done for most the time
    • Milestones are 100% events - signed off specifications
    • It is more important that the milestones be concrete, specific, measurable than understood by the boss
    • Sharp milestones are in service to the team. Fuzzy milestones grind down morale.

      • The other piece is late anyway

    • Hustle is important. It provides the cushion, the reserve capacity.
    • One must get excited about a one-day slip. Such are the elements of catastrophe
    • Know the PERT chart. Critical path schedule. Not all one day slips are equal.
    • Shows the hustle you need to keep your part off the critical path

      • Under the rug

    • Be careful of a manager not passing on information for the fear that the boss will act on it
      • Reduce the role of conflict: the boss must distinguish between action information and status information.
        • He must not act on problems his managers can solve
        • Status-review meetings vs problem-action meetings
      • Yanking the rug off
        • Looking at the status of all the milestones
        • A small team is needed to keep all the information up to date on a big project
        • The boss should allow for that
        • The investment in a modest amount of skilled effort in a plans and controls function is very rewarding

      Chapter 15: The other face

    • A program is a message from man to machine
    • A program also tells its story to the user

      • What documentation is required?

    • Purpose
    • Environment
    • Domain and range
    • Functions
    • Input-output formats
    • Operating instructions
    • Options
    • Running time
    • Accuracy and checking
‣
You also need something to know that it is working. Test cases

Mainline cases that are common

Barely legitimate cases that probe the edge

Barely illegitimate cases that probe the boundary

‣
Modifying a program required more information:
  • A flow chart or subprogram structure graph
  • Complete descriptions of algorithms used
  • Explanation of layout of all files used
  • Overview of the pass structure
  • A discussion of modifications to the original design
‣
The Flow Chart Curse:
  • Oversold piece of documentation
  • They show decision structure
  • Breaks down over multiple pages though. Keep to one page.
  • Don't do every detail - its a really space hogging way to describe something

Chapter 16 - No silver bullet - essence and accident in software engineering

  • Exploiting the mass market to avoid constructing what can be bought
  • Using rapid prototyping as part of planned iteration in establishing requirements
  • Growing software organicallying, adding more and more function to systems as they are run, used and tested
  • Identifying and developing conceptual designers of the rising generation
‣
Essence = difficulties inherent in the nature of software
  • Specification, design and testing
  • Complexity: Software is complex - there is no repetition (that's all captured in the software itself). Often complexity is non-linear with size.
  • Conformity: Much complexity comes form conformity to other interfaces
  • Changeability: Pressures of change. Recalls are uncommon in hardware, but ubiquitous in software. All successful software gets changed. Once you get users, you get new requirements. Successful software also survives beyond the life of hardware or platforms, so it must adapt to survive
  • Invisibility: Software is not embedded in space, so it's hard to visualise.
‣
Accidents = those difficulties that today attend its production but that are not inherent
  • High level languages: 5x productivity increase
  • Time-sharing: allows more complexity - batch programming interrupted flow
  • Unified programming environments - enable testing of the whole and using libraries etc
‣
Hopes for silver bullets:
  • Object-oriented programming
  • Artificial Intelligence
  • Expert Systems
  • Automatic programming
  • Graphical programming
  • Program verification
  • Environments and tools
  • Workstations
‣
Promising Attacks on the Conceptual Essence
  • Time of task = Frequency * Time
  • Buy versus build
  • Requirements refinement and rapid prototyping
    • Designing what to build is the hardest part
    • The most important part is the iterative extraction and refinement of requirements
  • Incremental development - grow, not build, software
  • Great designers - Getting good designs by following good practices instead of bad ones