There’s a lot to consider when it comes to developing software, unlike most people think. This article is meant to give you an insight to the few things you might have missed out on along the way.
Some of these laws might only relate to coding practices, and others will provide a wider view of product development.
Here we go;
** 1. Brooks’ law **
“Adding manpower to a late project makes it later.”
This originates from Fred Brooks’ 1975 book The Mythical Man Month which deals with the assumption that team members and months needed are interchangeable, no, this is not the case most especially when it comes to software development. It takes some time to bring new team members up to speed with the project.
** 2. Conway’s law **
“Any piece of software reflects the organisational communication structure that produced it.”
An up-tight team with a lot of coordinated behaviour creates confusing software, while a calm, decentralised team creates modular software. Yes, Conway’s Law relates to product design, and it’s real
** 3. Murphy’s law **
“If something can go wrong, it will.”
You can’t hope to stop the innevitable. This law applies the most because you’ll find it in software development and product management.
** 4. Hofstadter’s law **
“It always takes longer than you expect. (Even when you factor in Hofstadter’s law.)”
Besides the money or the product, the client is mostly concerned with how long it will take to build the product. 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.
** 5. Linus’ law **
“Given enough eyeballs, all bugs are shallow.”
Linus’ law is a reminder of the value of teamwork on the development floor. Often, two heads are better than one when solving problems.
** 6. Goodhart’s law **
“When a measure becomes a target, it ceases to be a good measure.”
A good example 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.
** 7. 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.”
Gall’s Law is a rule of thumb for systems design from Gall’s book Systemantics: How Systems Really Work and How They Fail. So, what do you do?
** 8. Zawinski’s Law **
“Every program attempts to expand until it can read mail. Those programs which cannot expand are replaced by ones that can.”
This reflects the pressure of programs to expand and evolve into platforms. Bloated programs soon get dropped for more streamlined options.
** 9. 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.”
Six months might seem much, but 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.
** 10. Lubarsky’s law **
“There’s always one more bug.”
Finally, a programmers work is never done. So, remember, when it comes to software development, done is better than perfect.