Ten laws of software development
Software development brings with it its fair share of paradigms, patterns and principals. Many of these take the form of software development laws.
Some software development laws relate only to coding practices. Others provide insight into the wider aspects of product development and design. And some reach past these borders, informing us of patterns that apply to life as we know it.
Here are ten interesting software development laws.
Brooks’ law
“Adding manpower to a late project makes it later.”
Brooks’ law comes from Fred Brooks’ 1975 book The Mythical Man Month. It deals with the assumption that team members and months needed are interchangeable.
This is not the case — particularly in software development (or any product development, for that matter). Why? Because of the time it takes to bring and keep people up to date with the project.
Conway’s law
“Any piece of software reflects the organisational communication structure that produced it.”
Melvin Conway articulated this law of software development in 1967. Conway’s law relates to product design. It’s the observed phenomenon that sees communication structures impact software output.
So, a tight-knit group with coordinated behaviour creates software with entwined features and code. A more relaxed, decentralised team, meanwhile, creates more modular software.
Murphy’s law
“If something can go wrong, it will.”
This is the most well-known and universally applicable law on this list. Murphy’s law is visible in all realms of project management, software development and life in general.
In software development, Murphy’s law highlights a key point: computers do what you tell them to do, not what you want them to do.
Hofstadter’s law
“It always takes longer than you expect. (Even when you factor in Hofstadter’s law.)”
‘How long will it take?’ is one of the most dreaded questions in software development. Hofstadter’s law provides the reason why. This relates to another law: Parkinson’s law, which posits that work expands to fill the time available for its completion.
Between Hofstadter’s law and Parkinson’s law, it’s near impossible to give an accurate estimate of completion time.
Linus’ law
“Given enough eyeballs, all bugs are shallow.”
This law is a bit ‘shallow’ in its wording. Bugs are only rendered shallow if the extra eyeballs belong to people with the skills to solve the problem. A layman’s eyes would not ease a tricky bug.
However, the principle still holds. Linus’ law is a reminder of the value of teamwork on the development floor. Often, two heads are better than one when solving problems.
Goodhart’s law
“When a measure becomes a target, it ceases to be a good measure.”
An example of Goodhart’s law in software development is lines of code. Lines of code provide a way to measure the size of a software product. But, when used as a target, code quality drops.
Lines that should need refining or cutting from the software are instead built on, creating a messy plate of spaghetti code.
Gall’s law
“A complex system that works has evolved from a simple system that worked. A complex system built from scratch won’t work.”
We see it in many of life’s complex systems, life itself started simple with single-cell organisms, for example. Software development is no different.
Gall’s law, if it holds true (which it seems to do), is a good reason to start software product development with a minimum viable product (MVP).
Zawinski’s Law
“Every program attempts to expand until it can read mail. Those programs which cannot expand are replaced by ones that can.”
Speaking of complexity, Zawinski’s law suggests that, once built, products continue to expand. They add more areas of functionality until they cannot expand any more.
Instances of feature creep illustrate Zawinski’s law in software development. Bloated programs soon get dropped for more streamlined options.
Eagleson’s law
“Any code of your own that you haven’t looked at for six or more months might as well have been written by someone else.”
Many think Eagleson an optimist — suggesting that six months is a generous timeframe. Either way, Eagleson’s law highlights the need for clear, effective commenting and clear coding standards. After all, not even the original programmer could decipher messy code later down the line.
Lubarsky’s law
“There’s always one more bug.”
Finally, for all your programming best practices, updates, and maintenance, there is always one more bug to fix. Or one more thing to tweak, or add, or learn. A programmer’s work is never done, after all.
So, remember, when it comes to software development, done is better than perfect.
The many laws of software development
No matter the law, principle, or pattern, each software development law holds something different. It might be an entertaining insight, a helpful lesson, or a simple point of interest.
These are just some of the patterns and paradigms that inform and occur within software development.
