Deprecated: Function set_magic_quotes_runtime() is deprecated in /home/raedan/public_html/textpattern/lib/txplib_db.php on line 14
State of Flow: The Sum of Simple Things::journal

The Sum of Simple Things

Lance Walton - Tuesday September 13, 2005

The developer practice of ‘doing the simplest thing’ neither guarantees nor implies that the resulting code will be simple. In fact, those who are skilled in this practice will readily agree that the code thus produced is often not simple.

This article examines why this is, why the technique is still appropriate and the essential method by which the simplicity can be restored.

An oft heard cry in development teams these days is to ‘do the simplest thing’. The aspiration to simplicity is rooted in the old scientific and engineering Principle of Parsimony, which suggests that simplicity is to be preferred over complexity. The best known statement of this is attributed to William of Orange. Known as Occam’s Razor, it advises that ‘plurality should not be posited without necessity’.

This notion has been paraphrased and re-illuminated in many different ways. A few examples, but no more than necessary, are:

The developers’ admonition to ‘do the simplest thing’ is, however, these days most likely derived from the eXtreme Programming (XP) mantra that, as a first step, one should ‘Do The Simplest Thing That Could Possibly Work’ (the capitals are customary within the XP community). This phrase, like many others in the XP literature, is frequently misunderstood or misrepresented.

‘Do The Simplest Thing That Could Possibly Work’ is an exploratory technique conceived to reduce the number of options that might work to a single solution that does work, without getting trapped in analysis paralysis or modeling minutiae. The practice neither guarantees nor implies that the resulting code will be simple when apprehended in any context other than the very narrow one defining the particular task to be completed. In fact, those who are skilled in this practice will readily agree that the code thus produced is often not simple. However, simple code is not the point of this particular practice; it is simple action that is required.

The piece missing from the simplistic notion of simplicity is that these acts tend to produce artefacts of the solution that do not fit well with the existing code. These artefacts then combine with those of other solutions and the result is complexity.

The way that this is resolved is through another, and more subtle process known as ‘refactoring’. It is here that the narrow context, used to obtain a working solution to the particular problem, is reconciled with the wider context of the rest of the codebase. This can be thought of as an entropy reducing technique. To achieve this requires effort, a higher order of thought and a deeper notion of simplicity.

It is often unfortunately the case that when a developer moves to this second and essential phase of work, where engineering and craft truly begins, his or her team-mates will cry ‘You’re over complicating it. Just do the simplest thing’. This is an example of the Simpleton Pattern which results in accidental complexity, difficult to understand codebases, complex yet subtle bugs, and frustration for the whole team.