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 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"


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