Eight Laws Rule Technology World

Why do we need to know?

Every single problem/opportunity that we run into in our daily life, it does not only exist because of you, your organization and your industry. It connects to the bigger system that everyone is in.

The laws is impacting at an invisible global level, steering our direction. In most cases, the quality of your decision making would benefit from simply understanding those laws.

There is no judges when you break those laws :)

Moore’s Law

In 1965, Gordon E. Moore (Co-funder of Intel) made this observation then later became known as Moore’s law.

The number of transistors on a microchip doubles every two years, though the cost of computers is halved.

Moore’s Law states that we can expect the speed and capability of our computers to increase every couple of years, and we will pay less for them.

It’s predicted that computer should reach the physical limit of Moore’s law sometime in 2020, let’s see.

Wirth’s Law

In 1995, Niklaus Wirth mentioned this in the article “A Plea for Lean software”, saying that

Software is getting slowed more rapidly than hardware is becoming faster.

Larry Page (founder of Google) restated this in 2009, referred as “Page’s law”.

The tendency of software to get twice as slow every 18 months.

Wirth’s law is compensating Moore’s law.

Murphy’s Law

There are many different saying about the origination of Murphy’s law, the earlist can be back tracked to1866. The contemporary form of Murphy’s law goes back as far as 1952 by John Sack, was described as an “ancient moutaineering adage”

Anything that can possibly go wrong, does.

One variation of this is coined by Peter Drucker, also called “Drucker’s Law” with complexity in management

If one thing goes wrong, everything else will, and at the same time

Cunningham’s Law

The concept is named after Ward Cunningham, father of the wiki.

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

This is interestingly related to how can we get people engaged at this internet age, or marketing.

Conway’s Law

In 1967, Melvin Conway introduceed the idea stating that organizations design systems that mirror their own communication structure.

Any organaization that designs a system (defined broadly) will produce a design whole structure is a copy of the organization’s communication culture.

If the parts of an organization (e.g., teams, departments, or subdivisions) do not closely reflect the essential parts of the product, or if the relationship between organizations do not reflect the relationships between product parts, then the project will be in trouble … Therefore: Make sure the organization is compatible with the product architecture.

Not surprisingly, after an organization restructure, some services are becoming orphan.

Sowa’s Law of Standards

In 1991, John F. Sowa shared his insight regarding to standard:

Whenever a major organization develops a new system as an official standard for X, the primary result is the widespread adoption of some simpler system as a de facto standard for X.

Thinking about all the standardization effort everywhere and the result. The failure of these attempts to establish new standards does not mean that all standardization efforts are doomed to failure. On the contrary, many successful standards have been established for computer systems as well as everything from screw threads to grain sizes for wheat. But the overwhelming majority of successful standards are clarifications and revisions of interfaces that have proved to be effective without the support of a major standards body. What has consistently failed are the “proactive” attempts to design new systems from scratch that are declared to be standard before anyone has had a chance to implement them, test them, use them, and live with them. Some new systems succeed, but most fail, and even the most successful go through several iterations before the best configuration is found. Such design iterations are best done in small research projects, not in large public committees.

Goodhart’s Law

In 1975, Charles Goodhart introduced originally as:

Any observed statistical regularity will tend to collaps once pressure is placed upon it for control purpose

Then later has been phased by Marilyn Strathern as:

When a measure becomes a target, it ceased to be a good measure

Thinking of this when we introduce metrics/KPI to organization, why sometimes it is not successful

Brook’s Law

In 1975, Fred Brooks coined this in his book “The Mytical Man-Month”.

Adding manpower to a late software project makes it later.

The law is stated primarily considering:

• Ramp up time, take time for people added to become productive;
• Commmunication overhead increases as the number of people increases
• Tasks in software projects are less divisible. Famous example “nine women can’t make a baby in one month”

There are definitly ways to help late software project, some time adding people helps as well, but it’s about where do you add them, when do you add them and how do you do it.

Takeaway

While sumarizes this all together, here is my relization:

• We had many great thinkers in late 1960 and 1975
• Be aware of these, not to blindly follow
• Things are connected

Stay safe, keep learning and improving!