“Brooks's Law: Adding manpower to a late software project makes it later.”

— Fred Brooks

Page 25 (italics in source, bold added).
The Mythical Man-Month: Essays on Software Engineering (1975, 1995)

Adopted from Wikiquote. Last update June 3, 2021. History

Help us to complete the source, original and additional information

Do you have more details about the quote "Brooks's Law: Adding manpower to a late software project makes it later." by Fred Brooks?

Fred Brooks photo

Fred Brooks20

American computer scientist 1931

Related quotes

“Like many fields in their early stages, the software field has had its share of project disasters: the software equivalents of Beauvais Cathedral, the S. S. Titanic, and the "Galloping Gertie" Tacoma Narrows Bridge. The frequency of these disaster projects is a serious concern: a recent survey of 600 firms indicated that 35% of them had at least one "runaway' software project.”

Barry Boehm (1935) American software engineer

Source: Software risk management: principles and practices (1991), p. 32

“Most post-mortems of these software disaster projects have indicated that their problems would have been avoided or strongly reduced if there had been an explicit early concern with identifying and resolving their high-risk elements. Frequently, these projects were swept along by a tide of optimistic enthusiasm during their early phases, which caused them to miss some clear signals of high risk issues which proved to be the project's downfall later.
Enthusiasm for new software capabilities is a good thing. But it needs to be tempered with a concern for early identification and resolution of a project's high-risk elements, so that people can get these resolved early and then focus their enthusiasm and energy on the positive aspects of their software product.”

Barry Boehm (1935) American software engineer

Source: Software risk management: principles and practices (1991), p. 32

“Success in all types of organization depends increasingly on the development of customized software solutions, yet more than half of software projects now in the works will exceed both their schedules and their budgets by more than 50%.”

Barry Boehm (1935) American software engineer

Abstract.
Software Cost Estimation with Cocomo II with Cdrom (2000)

“How does a project get to be a year late? … One day at a time.”

Fred Brooks (1931) American computer scientist

Page 153 (italics and ellipsis in source).
The Mythical Man-Month: Essays on Software Engineering (1975, 1995)

“Poor management can increase software costs more rapidly than any other factor. Particularly on large projects, each of the following mismanagement actions has often been responsible for doubling software development costs.”

Barry Boehm (1935) American software engineer

Barry Boehm (1981) as cited in: Tyson Gill (2002) Planning Smarter: Creating Blueprint-Quality Software Specifications. p. 14

“Software Engineering Economics is an invaluable guide to determining software costs, applying the fundamental concepts of microeconomics to software engineering, and utilizing economic analysis in software engineering decision making.”

Barry Boehm (1935) American software engineer

Barry W. Boehm (1981) Software engineering economics. Abstract.

“God's ways seem dark, but, soon or late,
They touch the shining hills of day;
The evil cannot brook delay,
The good can well afford to wait.”

John Greenleaf Whittier (1807–1892) American Quaker poet and advocate of the abolition of slavery

Source: Dictionary of Burning Words of Brilliant Writers (1895), P. 282

“A little retrospection shows that although many fine, useful software systems have been designed by committees and built as part of multipart projects, those software systems that have excited passionate fans are those that are the products of one or a few designing minds, great designers.”

Fred Brooks No Silver Bullet

Page 202.
No Silver Bullet (1986)

“Refactoring (noun) : a change made to the internal structure of software to make it easier to understand and cheaper to modify without changing the observable behavior of the software.
To refactor (verb) : to restructure software by applying a series of refactorings without changing the observable behavior of the software.”

Kent Beck (1961) software engineer

Source: Refactoring: Improving the Design of Existing Code, 1999, p. 33-43 as cited in: Militiadis Lytras, Patricia Ordóñez de Pablos, Ernesto Damiani (2011) Semantic Web Personalization and Context Awareness. p. 111

“Refactoring (noun) : a change made to the internal structure of software to make it easier to understand and cheaper to modify without changing the observable behavior of the software.
To refactor (verb) : to restructure software by applying a series of refactorings without changing the observable behavior of the software.”

Martin Fowler (1963) British programmer

Source: Refactoring: Improving the Design of Existing Code, 1999, p. 33-43 as cited in: Militiadis Lytras, Patricia Ordóñez de Pablos, Ernesto Damiani (2011) Semantic Web Personalization and Context Awareness. p. 111

Related topics