Silicon Investor (SI) -- The First Internet Community

STOCKTALK

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor. We ask that you disable ad blocking while on Silicon Investor in the best interests of our community. If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.

Technology Stocks : Discuss Year 2000 Issues -- Ignore unavailable to you. Want to Upgrade?

To: John Mansfield who wrote (580)	11/29/1997 6:05:00 PM
From: John Mansfield	Read Replies (2) \| Respond to of 9818

The Mythical Man-Month - "More software projects have gone awry for lack of calendar time than for all other causes combined - Why is this cause of disaster so common?" Famous Software engineering book by Frederick P. Brooks; ISBN 0-201-83595-9; 1995 edition; original edition 1975. Frederick P. Brooks was the leader of the IBM OS/360 development in the sixties. From chapter two - the mythical man-month (written in 1997): (part quotation; part summary by me). Some causes for delays that are relevant to large scale Y2K remediation efforts: "the man-month as a unit for measuring the size of a job is a dangerous and deceptive myth Men and months are interchangeable commodities only when a task can be partioned among many workers with no communication among them. When a task cannot be partitioned because of sequential constraints, the application of more effort has no effect on the schedule. The bearing of a child takes nine months, no matter how many women are assigned. Many software tasks have this characteristic because of the sequential nature of debugging" (i.e. especially during Y2K integration testing this may hit the schedule - JM). "In tasks that can be partioned but which require communication, the effort of communication must be added to the amount of work to be done." ... "Failure to allow enough time for system test, in particular, is peculiarly disastrous. Since the delay comes at the end of the schedule, no one is aware of schedule trouble until almost the delivery date." ... "What does one do when an essential software project is behind schedule? Add manpower, naturally. This may or may not help. (example with figures...) Suppose a task is estimated at 12 man-months and assigned to 3 men for 4 months, and that there are measurable mileposts. Now suppose the first milepost is not reached... <several alternatives are discussed; the best way would be to trim the task> But, insisting that the unaltered task be completed in 4 months is disastrous. Two new man have to be added. They will require training; that is not productive work. Furthermore the task now has to be partitioned in 5; not in 3 people. Additional coordination is necessary.... Oversimplifying outrageously, we state Brooks's Law: adding manpower to a late software project makes it later This then is the demythologiging of the man-month." ------- Chapter 19 - The Myhical man-month after 20 years: "How true is Brooks's Law?" <here follows discussion about pro / contra this law.> "On balance, I stand by the bald statement as the best zeroth-order approximation to the truth, a rule of thumb to warm managers against blindly making the instinctive fix to a late project."