You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Software projects often go awry for lack of calendar time compared to all other causes
Techniques of estimation are poorly developed -- often reflect unvoiced assumption that all will go well
Estimating techniques confuse effort with progress -- that men and months are interchangable
When uncertain of estimates, sw managers often lack courteous stubbornness to say "it takes the time it takes"
Schedule progress is poorly monitored -- routine practice in other eng domains are considered radical in sw
When schedule slips, natural (and traditional) response is to add manpower, which makes things worse
Optimism
All programmers are optimists
"All will go well" is the first false assumption
i.e. "each task will take only as long as it 'ought' to take"
however tractable the medium of programming is, programming ideas are faulty, bugs arise, making optimism unjustified
large programming efforts consist of many tasks, some chained
the probability that each will go well becomes vanishingly small.
The Man-Month
Effort/Cost does vary as a product of people x months, but progress does not
Men and months are only interchangeable commodities when a task can be partitioned among many workers with no communication among them
Generally not true of system programming
When tasks cannot be partitioned, the application of more people has no impact on schedule
When tasks can be partitioned but require communications, the effort of communication must be added to the amount of work to be done
communication effort is 2 parts:
training
intercommunication -- costly n(n -1)/2
Systems Test
component debugging and systems test are most depended on success of previous steps
time depends on number and subtlety of the errors encountered
optimism leads us to underestimate this time cost
Example breakdown:
⅓ planning
⅙ coding
¼ component test ad early system test
¼ system test, all components in hand
Gutless Estimating
When omlette is promised in 2 minutes, but isn't ready:
customer has 2 choices, wait or eat it raw
chef can also turn up the heat, likely ruining it
False scheduling/estimation to meet a patron's desired date is much more common
There is a need to develop and publixize productivity figures, bug-incidence figures, estimating rules, and so on
Util estimating is sounder, individual managers will need to stiffen their backbones and defend estimates
poor hunches on esitmation are better than wish-derived estimates
Regenerative Schedule Disaster
Situation: 12 person-months work estimated. 3 people assigned for 4 months.
The project is behind schedule 1 month, now what?
Assume task must be done on time, assume that only the first part of the task was misestimated. 9 person-months remain, will now need 4½ people to meet schedule.
Assume task must be done on time, assume uniformly misestimated. 18 person-months remain, so 9 people needed to meet deadline.
Reschedule. Re-analyze size of task, re-estimate effort. Ensure new estimate allows work to be done carefully/thoroughly so that rescheduling does not need to be done again.
Trim the task. (Often happens implicitly when schedule slippage noticed) When secondary costs of delay are very high -- either trim it formally and carefully or watch it get trimmed by hasty design and incomple testing.
Brooke's Law
Adding manpower to a late software project makes it later
Details an alternative team format in order to be able to organize large numbers of people to very large tasks
The problem
productivity variations exist between good programmers and poor ones.
Even within a group of experienced programmers, the ratios between the best and worst performances averaged about 10:1 on productivity and 5:1 on program speed and space measurements.
Small sharp teams are too slow for really big systems.
E.g. if a project is estimated at 5000 person-years
10 people working at a 7x efficiency with 7x gain for working in a small team
5000 / (10 x 7 x 7) =~ 10 years
Are people interested in working on this for 10 years? Is it relevant after 10 years?
In sum, need to find ways to break down large projects into team-sized problems which can then be coordinated/composed over teh scale of months rather than years
One of the most important consideration in system design
How much unity there is in the set of design ideas, rather than independent and uncoordinated ideas.
Achieving Conceptual Integrity
The purpose of programming system is to make a computer easy to use
Does so by furnishing languages and various facilities -- which are programs
But these facilities are bought at a price -- the external description of a programming system is 10-20x as large as the description of the computer system
Simplicity and straightforwardness proceed from conceptual integrity
Every part must even use the same techniques in syntax and analogous notions in semantics
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.
this is in opposition to scheduling demands which impose that system building needs many hands
two ways to resolve:
careful division of labor between architecture and implementation
second is new ways of structuring programming teams
separation of architectural effort from implementation is powerful
architecture -- cemplete and detailed specification of the user interface
implementation -- describes what goes on inside the case
so how to balance concerns of aristocracy of creativity by architects (few) and democratizing creativity to implementers (many)
unapologetic that there should only be a few people to control concepts making up the direction of conceptual integrity
with regards to creative work:
architects are creative with the setting of external specifications
implementers are creative with the design of the implementation to meet the architecture
cost-performance ratio depends on implementer
ease-of-use depends on the architect
form is liberating, and the sandbox provided by an rchitecture can enhance, not cramp, creativity
What does the implementer do while waiting?
concerns that if arch team is planning, implementers think:
the design will be too rich, ignoring cost of implementaiton (real risk)
the architects will get all of the fun work, leaving nothing for implementers (imagined risk)
implementation is a creative work in and of itself
the implementers will sit idle while plan comes (imagined risk)
matter of timing/phasing
flippant/quick answer: don't hire implementers too early
better answer:
total creative effort invovles 3 phases: architecture, implementation, realiziation -- Which can be parallelized
implementer can start as soon as there is vague assumptions about the manual (usage), clearer ideas about the tech, well-defined cost/performance objectives