Software Laws

Some “laws” that are particularly relevant in software development…

Parkinson’s law

Work expands to fill the time available for its completion.

See: Wikipedia

 

Goodhart’s law

When a measure becomes a target, it ceases to be a good measure.

See: Wikipedia

For example, demanding 100% of code coverage may result in developers writing more tests but of lesser quality (or even tests without asserts), just to meet the goal. 

 

Hofstadter’s Law

It always takes longer than you expect, even when you take into account Hofstadter’s Law.

See: Wikipedia

 

Conway’s Law

Any organization that designs a system will produce a design whose structure is a copy of the organization’s communication structure.

See: Wikipedia

In plain English, I would describe it as: Software architecture reflects team organization.

Or: You ship your org chart.

 

Gall’s Law

A complex system that works is invariably found to have evolved from a simple system that worked.

See: Wikipedia

 

Cunningham’s Law

Finally, a law written by a well known Software Engineer, Howard G. Cunningham, co-author of the Agile Manifesto. 

The best way to get the right answer on the Internet is not to ask a question; it’s to post the wrong answer.

See: Wikipedia

I do like quoting this before throwing out ideas I know to be bad. It always starts the conversation. It’s also why I sometimes start writing documentation that perhaps someone else should have written. That person clearly wasn’t going to start, but they may be quick to correct.

 

With an obligatory XKCD reference:

 

 

 

Tags: conwayslaw, cunninghamslaw, goodhartslaw, hofstadterslaw, laws, parkinsonslaw, xkcd