Laws of Software Development

I ran across an new eponymous law while reading "Understanding Enterprise SOA" by Eric Pulier and Hugh Taylor.
Pulier's rule of reuse:

A programmer will look at another programmer's output, no matter how brilliant and declare it garbage

The best law's and rules are named by others who admire the author's work, but this one seemed pretty worthy to me. This got me reminiscing about some laws of software development that perhaps had the same rigour as Newton's Laws, Boyle's Law or Hooke's Law.

The rules I have admired during my career are:

Brooks's Law:

adding manpower to a late software project makes it later

Hofstadter's Law:

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

Codd's Rules of relational database management systems which I won't quote here because there are 13 of them.

Moore's Law:

The number of transistors that can be inexpensively placed on an integrated circuit is increasing exponentially, doubling approximately every two years.

This has a number of applications outside of transistors such as processing speed, memory and disk capacity.

Clarke's 3rd Law:

Any sufficiently advanced technology is indistinguishable from magic.

The reason I class this as a software development Law is that it points out the futility of trying to explain the technical details of software to Business users. If a technical decision does not have any business impact then it may as well be magic.

I thought I would check what other software development Laws there are on the net. Here is a good sample from some useful sources listed in the Bibliography below:

Amdahl’s Law

The speedup gained from running a program on a parallel computer is greatly limited by the fraction of that program that can’t be parallelized.

Asimov's laws (Yes its SF but one day a software developer might have to follow them):

1. A robot may not injure a human being or, through inaction, allow a human being to come to harm.
2. A robot must obey orders given to it by human beings, except where such orders would conflict with the First Law.
3. A robot must protect its own existence as long as such protection does not conflict with the First or Second Law.

Atwood’s Law:

Any application that can be written in JavaScript, will eventually be written in JavaScript

Bye's First Law of Model Railroading

Anytime you wish to demonstrate something, the number of faults is proportional to the number of viewers.

Clarke's 1st Law:

When a distinguished but elderly scientist states that something is possible, he is almost certainly right. When he states that something is impossible, he is very probably wrong.

Clarke's 2nd Law:

The only way of discovering the limits of the possible is to venture a little way past them into the impossible.

Clarke's 4th Law (He's not often credited with this one):

For every expert there is an equal and opposite expert.

Conway's Law:

Any piece of software reflects the organizational structure that produced it.

Edwards' law

You cannot apply a technological solution to a sociological problem.

Greenspun's Tenth Rule of Programming (There actually are no rules 1 to 9)

Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp

This can also be worded “Those who do not understand Lisp are doomed to reinvent it.”

Gustafson's Law (also known as Gustafson-Barsis' law)

Any sufficiently large problem can be efficiently parallelized

Kerckhoffs' law on secure cryptography

A cryptosystem should be secure even if everything about the system, except the key, is public knowledge

Lehmann's Laws

1. Systems that are used must change or automatically become less useful
2. Through changes the structure of a system becomes ever more complex and more resources are needed to simplify it

Linus's law — named for Linus Torvalds,

given enough eyeballs, all bugs are shallow

Lubarsky's law of Cybernetic Entomology:

There is always one more bug.

McLuhan's Law:

If it works it's obsolete.

Metcalfe's law

In communications and network theory, states that the value of a system grows as approximately the square of the number of users of the system.

Murphy's Law

If anything can go wrong, it will.

Occam's Razor:
There are many wordings for Occam's razor and debate about how it is interpreted but from software development I think the best wording is "The simplest solution is usually the best". This is very nearly the same as the KISS principal "Keep it simple stupid".

Putt’s Law:

Technology is dominated by two types of people: those who understand what they do not manage, and those who manage what they do not understand.

Sturgeon's Revelation (sometimes referred to as his second law):

Ninety percent of everything is crap

Weinberg’s Law:

If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization.

Wirth's law

Software gets slower faster than hardware gets faster.

Zawinski's law

Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can.

Here are still more great laws from Joey DeVilla's Blog posting.

The Law	Who Said It	What it Says
Ellison’s Law of Cryptography and Usability	Carl Ellison	The user base for strong cryptography declines by half with every additional keystroke or mouse click required to make it work.
Ellison’s Law of Data	Larry Ellison	Once the business data have been centralized and integrated, the value of the database is greater than the sum of the preexisting parts.
Flon’s Axiom	Lawrence Flon	There does not now, nor will there ever, exist a programming language in which it is the least bit hard to write bad programs.
Gilder’s Law	George Gilder	Bandwidth grows at least three times faster than computer power.
Grosch’s Law	Herb Grosch	The cost of computing systems increases as the square root of the computational power of the systems.
Hartree’s Law	Douglas Hartree	Whatever the state of a project, the time a project-leader will estimate for completion is constant.
Heisenbug Uncertainty Principle (restated)	Jim Gray	Most production software bugs are soft: they go away when you look at them.
Hoare’s Law of Large Programs	C. A. R. Hoare	Inside every large problem is a small problem struggling to get out.
Jakob’s Law of the Internet User Experience	Jakob Nielsen	Users spend most of their time on other sites. This means that users prefer your site to work the same way as all the other sites they already know.
Joy’s Law	Bill Joy	smart(employees) = log(employees), or “No matter who you are, most of the smartest people work for someone else.”
Lister’s Law	Timothy Lister	People under time pressure don’t think faster.
Nathan’s First Law	Nathan Myhrvold	Software is a gas; it expands to fill its container.
Ninety-ninety Law	Tom Cargill	The first 90% of the code accounts for the first 90% of the development time. The remaining 10% of the code accounts for the other 90% of the development time.
Pesticide Paradox	Bruce Beizer	Every method you use to prevent or find bugs leaves a residue of subtler bugs against which those methods are ineffectual.
Reed’s Law	David P. Reed	The utility of large networks, particularly social networks, scales exponentially with the size of the network.
Sixty-sixty Rule	Robert Glass	Sixty percent of software’s dollar is spent on maintenance, and sixty percent of that maintenance is enhancement.
Spector’s Law	Lincoln Spector	The time it takes your favorite application to complete a given task doubles with each new revision.
Spafford’s Adoption Rule	George Spafford	For just about any technology, be it an operating system, application or network, when a sufficient level of adoption is reached, that technology then becomes a threat vector.

Some unattributed "laws" that are worth mentioning:

• Build a system that even a fool can use, and only a fool would want to use it.
• Any program over 100 instructions can be simplified by 3 instructions (without losing any functionality).
• Any idiot can learn to use computers, and many do
• There’s never time to do it right in the first place, but there’s always time to do it over when it doesn’t work.

This posting started with Pulier's Law: "A programmer will look at another programmer's output, no matter how brilliant and declare it garbage". At the risk of repeating Pulier's conceit of naming law about himself I propose:
Kimber's Corollary:

No amount of documentation is ever sufficient to completely understand a system

Bibliography
http://en.wikipedia.org/wiki/Adages_named_after_people

"Moore's Law is Dead", http://www.techworld.com/opsys/news/index.cfm?newsid=3477

http://en.wikipedia.org/wiki/Change_management_(engineering), This includes the reference to Lehmann's Laws siting Hinley, D.S. (1996). Software evolution management: a process-oriented perspective. Information and Software Technology, 38, 723-730

http://en.wikipedia.org/wiki/Moore

http://en.wikipedia.org/wiki/Occam

http://www.webopedia.com/TERM/C/Codds_Rules.html

Joey de Villa, http://globalnerdy.com/2007/07/18/laws-of-software-development/

Phil Haack, 19 Eponymous Laws Of Software Development, http://haacked.com/archive/2007/07/17/the-eponymous-laws-of-software-development.aspx

Eric Pulier and Hugh Taylor, "Understanding Enterprise SOA", Manning Publications, 2006

Book Review: J2EE and Weblogic

I was drawn to reading the book "J2EE Web Services on BEA Weblogic" by Anjali Anagol-Subbarao because my organization has purchased the Weblogic platform and I wanted more detail about how to make the best use of the tools available in this suite. General books on SOA can tell you about the principals and standards but without actually talking about specific tools there is a big gap between theory and practice.

"J2EE Web Services on BEA Weblogic" was published as part of the Hewlett-Packard Professional Book Series. While the Weblogic content the descriptions of some of the management functions of HP Openview were a bit alienating as I have not used this product. However it did also talk about some useful utilities and open source products that were not provided by either BEA or HP.

While the description of the tools were fairly high level and probably could be translated into similar functions in other suites I do not expect this book attract users of other SOA platforms suites.

The book style is fairly easy to read with some good diagrams and examples. The SOA standards and principles are covered well with a focus on the WS-*, SOAP and WSDL standards.

The basics of J2EE and EJBs are explained and some fundamentals of the Weblogic platform. This is not an evangelistic book about SOA or Web Services but goes into a bit about the technology of how to bring it about. The SOA benefits are there but the SOA story gets a bit lost amongst the instruction on how to use the BEA tools.

Some of the material reads like BEA marketing literature. I would have liked more practical tips on what to use and what not to use. In a book like this we need information that we can't glean from the manuals. This provided the high level overview with out some of the more practical "dos and don'ts".

There is good information on versioning and a good section on evaluating WS management tools. Also the book provides some practical approaches to performance issues.

This book has limited readership and will date quickly. Your best technical advice will always come from the product manuals but this book explains a bit about the suite is used as a whole. Published in 2004 this book is nearing its "use by" date but there is still some relevance to what it describes. Be quick though, with the acquisition of BEA by Oracle we can expect some changes to the BEA product suite.