The 80/20 principle

(Part of my collection of Universal Principles of Software System Design)

Also known as the Pareto principle.

A well know formula, applicable to many areas. Probably primarily known in the form: 20% of the effort produces 80% of the job to be do done (or: the last 20% will take 80% of the effort).

In IT, the principle applies also to requirements versus functionality: 20% of the requirements determine 80 percent of the architecture. 20% of the requirements are the important ones for the core construction of a solution.

Focusing on the 20% important requirements in determining the architecture lets you shrink the options you need to consider seriously and helps you prioritize options. It is up to the experience of the architect to determine which of the set of the requirements are the important ones.

Literature: The 80/20 Principle by Richard Koch.

An example – airline reservation system.

The first time I (unconsciously) applied the 80/20 rule was in my early days as an architect. I was working with a team of architects on application infrastructure for completely new web applications. A wide variety of applications were planned to run on this infrastructure. But it was not clear yet what were the characteristics of all of these applications, what things to cater for in this generic hosting solution.

So we decided to walk through the known use cases for the different applications.

We worked our way through the main use cases for four of the tens of applications. During the fourth we somehow could not come up with additional requirements for the application infrastructure. We realized that the rest of the set of applications would be a variety of one of the ones we looked at. We had our 80% from looking at 20%.

Proximity

The principle of proximity aims to ensure that related design elements are placed together. Unrelated items, should be placed separately. Close proximity means items are connected or have a relationship to each other, to help organize or give structure to a layout.

In the organisation of software system the principle of proximity relates very much to cohesion. Proximity in that sense is the visual design counterpart of cohesion in software design.

See Cohesion.

Cohesion

Cohesion is a notion in software construction that represents the strength of the dependencies within a component. Cohesion indicates how well the pieces in a component hang together.

Ideally there is a high cohesion within the component. Responsibilities assigned to a component typically use typically the same data and operate in the same specific set of business or technical activities.

If pieces in a component do not have a strong dependency or relationship, this may be an indication to separate functionality out into a new component.

Cohesion can play on various levels of our software design: on the components level (probably the lowest level), but also on subsystem and system level.

The principle of cohesion goes hand in hand with the principle of loose coupling. On the one hand you want to make sure you separate concerns into components, define neat interfaces, you make there no unnecessary inter-component communication. At the same time you club parts of a component because they all contribute to a single well-defined task.

Cohesion not loose coupling are very recent concepts in software construction. Cohesion was probably first extensively discussed in Page-Jones, Meiler. The Practical Guide to Structured Systems Design publication in 1988!Afbeeldingsresultaat voor pae jones Practical Guide to Structured Systems Design"

Recovery

Design for recovery means you take explicit measures in your software systems for unexpected situations.

Recovery plays at every levels of our software system, from user interface to backend software components, and from our functional parts to our infrastructure components.

In your code you make sure to catch as many possible error situations as possible – meaning you catch any possible error that can occur, and handle errors as locally as possible – where they occur. You apply Forgiveness and correct errors or mitigate their consequences. Then, when issues occur, you make sure you have have designed for recovery.

Wirfs-Brock  identifies the following options for recovery:

  • Ignore the request. Yes in some cases, you can recover by ignoring a request. If for example you know your client will retry, you could choose to ignore a failing request. Or, somewhat better, you could log log an error and ignore the request.
  • Admit failure. You signal an exception, try to clean up residuals and give up the opreration.
  • Retry. When the failure is likely to be caused by some temporary condition, a retry may be the best option. You see this applied in databases, where the rows you want to access are locked by another thread; you want to wait, for some limited time, for the lock to be released.
  • Perform an alternative action: in agreement with your clients, you may wish to design for an alternative action. Alternatives are usually less perfect, less efficient, but preferable over a total failure.
  • Appeal to a higher authority. Sometimes you can not do more than inform a higher authority about the error. The higher authority may be your business owner who then can contact end customers to inform them about a process that is stuck, and keep them informed about a resolution.

In designing for recovery we have to weigh how much effort and cost we spend on designing recovery actions.

See also Error handling, Foregiveness.

Noise reduction

The principle of noise reduction in software systems makes software systems better by removing inessential parts and options, and/or making them invisible or only visible to selected users.

Reducing the options in a software solution increases usability. This goes for user interfaces as well as technical interfaces. We decide what an interface looks like, and stick to it. All too famous examples of noise reduction are the Apple iPod and the Google search page.

Adding features for selected users means adding features, and under-the-hood complexities for all clients.

Reducing options also makes software more robust. If we build less interfaces, we can make them better. We can focus on really doing well at the limited set of interfaces.Afbeeldingsresultaat voor noise reduction

In practice we see hardware and software tools have many many options and features. That is not because software suppliers so desperately want to give their customers all the options, but that is because we, their customers, are requesting these options. Software supplier may more critically view all these requests. Some are.

I believe we should aim to settle for less. Every time we can do with less, we shouldn’t build more, just because we can. Also, we shouldn’t ask our suppliers to build features that are nice to haves.

There are always more options, but let’s limit the options to 4, or better: 1.

See also simplicity.

Close Menu