Blue Flavor

Tunnels by Jeff Croft

The Immutable Laws of Web Design and Development

February 7th, 2008 at 5:15 p.m.

Occasionally smart people say pretty smart things. The computing world likes to call these pearls of wisdom laws. They also like to name each law after the person who coined it. Take, for instance, the most well-known of all the computing world’s laws, Moore’s Law, which is named after Intel founder Gordan E. Moore.

In the web industry we have no such laws. While computer software and engineering is a science, web work isn’t. I view web work as an amalgamation of a variety of crafts and disciplines, like behavioral psychology, art and design, information sciences – and, since the end medium depends on technology, part computer science.

Given that last bit, it makes sense that some computing laws would apply to the world of the web. Since I have an awful time remembering them, I figured I’d write down the ones that have been helpful to me in my career in the web industry.

Brooks’ Law

Adding manpower to a late software project makes it even later.

Probably the law I quote the most. I can’t tell you how many times a client has asked, ” Can’t we just throw another guy at the problem?”

Parkinson’s Law

Work expands so as to fill the time available for its completion.

In other words, we’re talking about ‘scope creep’. Keep projects short and sweet—Otherwise, they tend to become unmanageable beasts.

Hoare’s Law of Large Programs

Inside every large problem is a small problem struggling to get out.

A perfect reminder that we often create larger problems from small ones. Always remember to focus on the goal or need. Everything else is secondary.

Lister’s Law

People under time pressure don’t think faster.

Tell this to any startup and they will probably show you to the door, but it’s very true. The only result you get from putting people under pressure is unnecessary stress. Take a deep breath and avoid letting your stress become someone else’s.

Pareto Principle

For many phenomena, 80% of consequences stem from 20% of the causes.

This is also known as the “80/20 Rule,” though most people seem to use it incorrectly. I don’t know if I fully believe in this principle. I think we often have a false perception that this is true, and therefore tend to focus on 20% of the problem. Or, in other words, the dreaded ‘edge case’.

The Peter Principle

In a hierarchy, every employee tends to rise to his level of incompetence.

This principle comes in to play when dealing with the opinions of overzealous stakeholders. It can be difficult as an employee to publicly admit that you know more about this web stuff than your boss, but it must be done.

Otherwise you run into…

Conway’s Law

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

This law is absolutely true of websites as well. Organizations that have bad communication or poorly defined roles invariably have websites that take more time and cost way more then they should.

Fitts’ Law

The time taken to acquire a target is a function of the distance to and the size of the target.

This one seems to be a favorite with speakers at web conferences, and is a handy reminder of the principals behind information and visual design.

Tesler’s Law of Conservation as Complexity

You cannot reduce the complexity of a given task beyond a certain point. Once you’ve reached that point, you can only shift the burden around.

A good principle of information architecture. Complex tasks tend to be broken up and can often become more confusing in the process. Identify the hard stuff early on and treat it differently than everything else.

Occam’s Razor

The explanation requiring the fewest assumptions is most likely to be correct.

This principle is helpful when you are trying to understand human behavior. Sometimes things just work. You may not think this is right, and you may not understand why, but when something works you should just go with it.

Hofstadter’s Law

A task always takes longer than you expect, even when you take into account Hofstadter’s Law.

Isn’t that the truth. The best trick here is to record your time, so you always have a record to refer to. This gives you a good starting point for estimating how long the next task will take.

Ninety-ninety Law

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.

The law is absolutely true. Once the end is in sight, the finish line tends to drift into the distance. Keeping development milestones short and sweet tends to help. It allows developers to feel like they’ve accomplished something, so they’re not wallowing in a pit of despair.

Hartree’s Law

Whatever the state of a project, the time a project-leader will estimate for completion is constant.

This law always reminds me of the movie Money Pit. Whenever the contractors were asked when the job would be done they’d say, “oh… in about two weeks,” but in reality the project took a year. Trying to set the right completion expectation is always hard. I find just being totally honest with the client goes a long way toward not setting false hopes.

Jakob’s Law of the Internet User Experience

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.

Coined by Jakob Nielsen, the King of Sameness. While this statement may read like BS, there is some truth it. People adapt to what they know, and they have certain assumptions about the way things work that cannot be ignored.

Which could also be said this way…

Fisher’s Fundamental Theorem

The more highly adapted an organism becomes, the less adaptable it is to any new change.

But…

Clarke’s Second Law

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

This one was coined by Author C. Clarke. I think his laws are both keen observations and powerful reminders that we should seek out the unknown, question the assumed truth and constantly push for new discovery and invention.

These are some of my favorite laws, but what are yours?

(For more on computing laws checkout this post and this post.)

Brian Fling

More Information