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 ofyesteryear).
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
Curious about how are these recommendations generated? Learn more.
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:
Gaps in your own logic appear
Communicate to others
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:
Clarity of structure and representation makes precise requirements for modules easier
Partitioning and independence of modules avoids system bugs
Suppression of detail makes flaws in structure more apparent.
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.
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.
‣
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:
Gaps in your own logic appear
Communicate to others
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
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
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
‣
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:
Clarity of structure and representation makes precise requirements for modules easier
Partitioning and independence of modules avoids system bugs
Suppression of detail makes flaws in structure more apparent.
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:
On-machine debugging
Memory dumps
Snapshots
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
