Laws of Software Development (that all developers should recognize)

jobs Labels are so incredibly useful in life, but can also be quite dangerous.  (I’ll write more on the dangerous impact of labels later)

For now, I’d like to briefly discuss one type of label which I often find useful and sometimes entertaining.  They’re called “eponymous laws”.  That’s a strange name, but it’s simply the stating of some observation that is usually named after the person that observed it.


You’ve all heard of Murphy’s Law:

"Anything that can go wrong, will go wrong"

And you’ve surely witnessed the intentionally misspelled “Muphry’s Law” in action…

“If you write anything criticizing editing or proofreading, 
there will be a fault of some kind in what you have written.”

…but I especially like those eponymous laws involving software development (that’s what I do in my real job).  There are certainly more laws in play, but these are some of my favorites and the ones that I have observed in the real world (but not before someone else observed it first and got dibs on the name).  Once you are aware of the law, it gives you the power to get ahead of it before it causes you problems.

For good measure, I’ve added a few non-laws that seem to apply.  I have linked each name to my source (which may in turn link to you another source).

 

ConeOfUncertainty

 

Cone of Uncertainty

Not to be confused with the “Cone of Silence”, my own paraphrased version of this idea is:

“You won’t know how long it will take until it’s complete.”

Moore’s Law

(I mention here only as reference for Wirth’s Law and Gate’s Law below)

“The complexity of integrated circuits doubles every 24 months.”

Wirth’s Law

“Software gets slower faster than hardware gets faster.”

Gate’s Law

“The speed of commercial software generally slows by 50% every 18 months, thereby negating all the benefits of Moore’s law.”

Brook’s Law

“Adding manpower to a late software project makes it later.”

Ziv’s law

“Software development is inherently unpredictable. And specifications and requirements will never be fully understood.”

Parkinson’s Law

“Work expands so as to fill the time available for its completion.”

Al’s Law

“People will remember slipped dates but not slipped features.”

(Al, if you are listening… this is a great one.  Let’s get it out there.)

 

Wegner’s Lemma

“An interactive system can never be fully specified nor can it ever be fully tested.”

Conway’s Law

“Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.”

Mooer’s Law

“An information retrieval system will tend not to be used whenever it is more painful and troublesome for a customer to have information than for him not to have it.”

 

And the truth that I have observed all too often:

“…people don't know what they want until you show it to them.”
Steve Jobs

(this idea is sometimes referred to as “Humphrey’s Law”… though I prefer to keep “Humphrey’s Law” going as The Centipede’s Dilemma)

 

Project Management Triangle

And to round out the topic, I’ll leave you with the Time, Cost, Quality triangle which applies not only to software development, but to most any vocation.Pick2

One thought on “Laws of Software Development (that all developers should recognize)

  1. Al Noel

    Great collection of fundamental truths.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes:

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>