I was reflecting on a few “Laws” that I reference when I teach various Agile courses, and it made me wonder – how many of these “Laws” are there? I frequently reference Little’s Law, Brook’s Law, and Conway’s Law. But I thought – there has to be more! So, I started researching these highbrow, make-you-look-smart Laws, and it turns out there are quite a few of them. In fact, there are not only Laws, but there are also Principles or Theories – what a gift! In this post I’m going to pass along or summarize 14 such Laws, Principles, and Theories. All in the spirit of giving you the opportunity to be the smartest guy or gal in the room!
We’ll start with the ones I already mentioned:
Little’s Law
“Little’s Law” provides the foundation for queue theory and defines the relationship between Work in Progress (WIP), Throughput, and Lead Time. It is the reason why Kanban teams try to limit WIP.
Little proved the relationship between the average number of customers in a store, their arrival rate, and the average time in the store. Sounds pretty innocuous but as it turns out, it became the basis for Kanban.
The law is stated as a formula:
L = λ W Where L = average number of customers in the store λ = average arrival rate W = average time that a customer spends in the store
For example, assume customers arrive at the rate of 20 per hour (λ) and stay an average of 0.25 hour (W). This means we should find the average number of customers in the store at any time to be 5 (L).
L = 20 * 0.25 = 5
In a nutshell, if you want to reduce your lead time by half, you would have to either double your throughput or halve your inventory. Both would achieve the same result.
Brook’s Law
In 1975, Frederick Brooks, published a book on project management and software engineering called The Mythical Man-Month: Essays on Software Engineering. The key idea of the book was that adding manpower to a late software project makes it later. This idea later became known as Brook’s Law.
At first, the idea might seem counterintuitive, especially to project managers. It is often assumed that the more people work on a task, the faster it gets done, and that a late project can be put back on track by adding more people to it. However, based on his experience at IBM, Brooks suggested the opposite. In the title of his book, Brooks refers to a man-month – a popular concept in project management for software development, measuring the amount of work done by one person in one month. According to Brook’s Law, a man-month is not a valid measurement of effort.
When n people have to communicate among themselves, as n increases, their output decreases and when it becomes negative the project is delayed further with every person added.
Group intercommunication formula: n(n − 1) / 2
Example: 50 developers give 50 · (50 – 1) / 2 = 1225 channels of communication.
Conway’s Law
Conway’s law is an adage named after computer programmer Melvin Conway, who introduced the idea in 1967. It states that:
organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.
The law is based on the reasoning that in order for a software module to function, multiple authors must communicate frequently with each other. Therefore, the software interface structure of a system will reflect the social boundaries of the organization(s) that produced it, across which communication is more difficult. Conway’s law was intended as a valid sociological observation, although sometimes it’s used in a humorous context. It was dubbed Conway’s law by participants at the 1968 National Symposium on Modular Programming.
Postel’s Law
Be conservative in what you send, liberal in what you accept.
Jon Postel originally articulated this as a principle for making TCP implementations robust. This principle is also embodied by HTML which many attribute as a cause of its success and failure, depending on who you ask.
In today’s highly charged political environment, Postel’s law is a uniter.
Parkinson’s Law
Otherwise known as the law of bureaucracy, this law states that…
Work expands so as to fill the time available for its completion.
As contrasted to Haack’s Law which states that
Work expands so as to overflow the time available and spill on the floor leaving a very sticky mess.
Hofstadter’s Law
This one is great because it is so true. And I knew this law and still this post took longer than I expected.
A task always takes longer than you expect, even when you take into account Hofstadter’s Law.
The law is often cited by programmers in discussions of techniques to improve productivity, such as The Mythical Man-Month mentioned above.
Hofstadter introduced the law in connection with a discussion of chess-playing computers, which at the time were continually being beaten by top-level human players, despite outpacing humans in depth of recursive analysis. Conventional wisdom held that the strength of human players lay in their ability to focus on particular positions rather than follow every possible line of play to its ultimate conclusion.
Moore’s Law
Probably the most famous law in computing, this law states…
The power of computers per unit cost doubles every 24 month.
The more popular and well known version of Moore’s law states…
The number of transistors on an integrated circuit will double in about 18 months.
And we’ve been racing to keep up ever since.
Zawinski’s Law
This law addresses software bloat and states…
Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can.
Zawinski himself called it the “Law of Software Envelopment”. Eric S. Raymond commented that while this law goes against the minimalist philosophy of Unix (a set of “small, sharp tools”), it actually addresses the real need of end users to keep together tools for interrelated tasks, even though for a coder implementation of these tools clearly consists of independent jobs.
Fitt’s Law
This is a law related to usability which states…
Time = a + b log~2~ ( D / S + 1 )
Or in plain English,
The time to acquire a target is a function of the distance to and the size of the target.
A well known application of this law is placing the Start menu in the bottom left corner, thus making the target very large since the corner is constrained by the left and bottom edges of the screen.
Hick’s Law
Has nothing to do with people with bad mullets. I swear. Related to Fitt’s law, it states that…
The time to make a decision is a function of the possible choices he or she has.
Or in plain math,
Time = b log~2~(n + 1)
Seems to me this is also a function of the number of people making the decision, like when you and your significant other are trying to figure out where to go or what to have for dinner.
And then of course we have a principles:
The Peter Principle
One of the most depressing laws in this list, if you happen to have first-hand experience with this via working with incompetent managers.
In a hierarchy, every employee tends to rise to his level of incompetence.
Just read Dilbert (or watch The Office) to get some examples of this in action.
Pareto Principle
Also known as the 80-20 rule, the Pareto Principle states…
For many phenomena, 80% of consequences stem from 20% of the causes.
This is the principle behind the painful truth that 80% of the bugs in the code arise from 20% of the code. Likewise, 80% of the work done in a company is performed by 20% of the staff. The problem is you don’t always have a clear idea of which 20%.
And we have theories:
Theory of Constraints
Created by Dr Eliyahu Goldratt and published in 1984 in his book “The Goal”.
The Theory of Constraints says that every system, regardless of how well it works, has at least one constraint (a bottleneck) that limits performance.
The law allows us to deduce the response time and performance limits of a process – essential information for IT services and software development projects.
And Finally…
The Dunning-Kruger Effect
The Dunning-Kruger effect is a type of cognitive bias in which people believe that they are smarter and more capable than they really are. Essentially, low ability people do not possess the skills needed to recognize their own incompetence. The combination of poor self-awareness and low cognitive ability leads them to overestimate their own capabilities.
The term lends a scientific name and explanation to a problem that many people immediately recognize—that fools are blind to their own foolishness. As Charles Darwin wrote in his book The Descent of Man, “Ignorance more frequently begets confidence than does knowledge.”
So there you have it – 14 Laws, Theories and Principles – all primarily dedicated to the World of Software Development. In an industry based on deep thought and architecture – you’d expect these types of Laws would arise. I’m sure it won’t be long and we’ll have the Law of Agile Transformation, or the Theory of Agile – in fact, maybe we already do and I just didn’t Google hard enough!
Comments