blatherskite: (Default)
[personal profile] blatherskite
Today I'm posting a rare "guest column" from one of those folks fortunate enough to have had their musings become modern proverbs. "Brasington's laws" of project management have appeared in a great many places around the Internet, but rarely in their complete form. Recently, I had an oportunity to chat with him about his laws (having quoted several of them in my book on onscreen editing), and he graciously gave me permission to post the complete (to the best of his recollection) version of the laws.

Brasington's 10 laws of software project management



  1. No major project is ever installed on time, within budget, or with the staff that started it. Yours will not be the first.

  2. Projects progress quickly until they become 90% complete, then they remain at 90% complete forever.

  3. One advantage of fuzzy project objectives is that they let you avoid the embarrassment of estimating the corresponding costs.

  4. When things are going well, something will go wrong. When things just can't get any worse, they will. When things appear to be going better you have overlooked something.

  5. If project content is allowed to change freely, the rate of change will exceed the rate of progress.

  6. No system is ever completely debugged. Attempts to debug a system inevitably introduce new bugs that are even harder to find.

  7. A carelessly planned project will take three times longer to complete than expected; a carefully planned project will take only twice as long.

  8. Project teams detest progress reporting because it vividly manifests their lack of progress.

  9. Project teams are happy to scrap work, but only after it has been planned, designed and partially implemented.

  10. See Law 2.


[In a variant of these laws, Brasington sometimes omitted item number 10 to see whether anyone was paying attention.—GH]

Brasington's laws of computer programming



  1. Any given program, if running, is obsolete.

  2. Any given program costs more, and takes longer than spec'ed.

  3. If a program is useful, it will have to be changed.

  4. If a program is useless, it will have to be documented.

  5. Any program will expand and fill all of available memory—plus one byte.

  6. The value of a program is inversely proportional to the weight of its output.

  7. Program complexity grows until it exceeds the capability of the programmer who must maintain it.

  8. No program is so simple that it can't be issued with bugs in it.



W.A. "Bil" Brasington first put his "laws" to paper about 1977 or 1978, when he was an EDP auditor working for a large Texas bank holding company. They were intended to serve as a lighter moment during a training sesssion for other EDP auditors on auditor participation in major computer software projects. Though intended primarily as humor, the laws also contain significant home truths familiar to anyone who has participated in such projects, making them a classic example of how the judicious use of humor can make a lesson "sticky". Notwithstanding the tongue in cheek attitude, Brasington notes that project management is important.

(no subject)

Date: 2010-08-10 09:24 am (UTC)
bientot: Umbrella hat (Umbrella hat)
From: [personal profile] bientot
Many years ago a friend (EE at Boeing) reported seeing this on a cubicle wall at work (it's been a long time so I may have fudged the details, but the gist is correct).

The Six Stages of a Project

1. Inspiration
2. Enthusiasm
3. Progress
4. Search for the guilty
5. Punishment of the innocent
6. Praise and honors to the non-participants

I have no idea of the origin, but it still rings true!

(no subject)

Date: 2015-01-11 07:39 am (UTC)
zirconium: photo of squeezy Buddha on cell phone, next to a coffee mug (buddha and cocoa)
From: [personal profile] zirconium
I have long wondered who the Brasington of "Brasington's Ninth Law" (here listed as #7) was -- thank you for providing the answer!

Profile

blatherskite: (Default)
blatherskite

Expand Cut Tags

No cut tags