Posts tagged as:

Simplicity

Simple versus easy

by John on November 11, 2011

Rich Hickey argued in a recent talk that simplicity is objective but easiness is subjective. Something is simple if it is singular: it does one thing, it is made of one thing, etc. Something is easy if it is close at hand, i.e. familiar.

I think this is a useful distinction, though simplicity is a little harder to pin down than the talk implies. Simplicity is relative and requires context. Rich Hickey’s context is programming languages, and in that context it may be fairly objective to say one construction is simpler than another because it does less.

For example, Hickey says one complication of Lisp is that it uses parentheses for function calls and for grouping. It would be simpler if one symbol did one thing. Mathematica does something like this. Parentheses are for grouping only. Function calls are delimited by square brackets. The square brackets are inconsistent with standard mathematical notation, so they’re not as easy (i.e. familiar), but they are simpler.

Mnemonics often complicate things to make them easier. For example, consider this mnemonic for pi:

How I want a drink, alcoholic of course, after the heavy lectures involving quantum mechanics.

This sentence is easier for most people to remember than 3.14159265358979.  But the sentence is also more complex. A computer can represent the number in 8 bytes but the sentence takes 94 bytes of ASCII, more in Unicode.

Sometimes complex is better than simple, better in some context. It’s easier to memorize coherent sentences than numbers. But imagine if we got so excited by this mnemonic that we decided to represent all numbers by sentences. This would be amusing for a little while but would quickly become painful.

Some things are objectively simple but inhuman. Counting seconds since some event (e.g. Unix time) is much simpler than our system of keeping time with days, weeks, months, and years. But our human experience is profoundly influenced by the rotations and revolutions of our planet. Even weeks, which have no astronomical significance, seem to be aligned with human nature. So we keep our complex calendars while our computers count seconds.

I believe Hickey’s main point is that we need to reevaluate what we believe is simple. Maybe what we think is simple is complex but familiar. Maybe there is something new that is objectively simpler would become even easier once we’re used to it. (In particular, Hickey would like for us to try his programming language.) Once you practice thinking this way, you’ll see that many familiar things could be made simpler.

Related post:

A little simplicity goes a long way

{ 9 comments }

Several people have asked me whether studying math changed my view of the world, and if so how.

I see applications of math everywhere. But more fundamentally, studying math has led me to believe that complex problems often have simple solutions.

Simple solutions may be hard or impossible to find. But you’re more likely to find a simple solution if you believe it exists because you’ll keep looking longer.

Related posts:

Forced to be simple
Rewarding complexity
Adding simplicity

{ 11 comments }

Third-system effect

by John on April 18, 2011

The third-system effect describes a simple system rising like a phoenix out of the ashes of a system that collapsed under its own complexity.

A notorious ’second-system effect’ often afflicts the successors of small experimental prototypes. The urge to add everything that was left out the first time around all too frequently leads to huge and overcomplicated design. Less well known, because less common, is the ‘third-system effect’: sometimes, after the second system has collapsed of its own weight, there is a chance to go back to simplicity and get it right.

From The Art of Unix Programming by Eric S. Raymond. Available online here.

Raymond says that Unix was such a third system. What are other examples of the third-system effect?

Related posts:

Simple legacy
Where the Unix philosophy breaks down

{ 9 comments }

Forced to be simple

by John on April 8, 2011

From Paul Graham:

When you’re forced to be simple, you’re forced to face the real problem. When you can’t deliver ornament, you have to deliver substance.

Related posts:

Confusing familiar with simple
Rewarding complexity
A little simplicity goes a long way

{ 6 comments }

Demand for simplicity?

by John on January 11, 2011

From Donald Norman’s latest book Living with Complexity:

… the so-called demand for simplicity is a myth whose time has passed, if it ever existed.

Make it simple and people won’t buy. Given a choice, they will take the item that does more. Features win over simplicity, even when people realize that features mean more complexity. You do too, I’ll bet. Haven’t you ever compared two products side by side, feature by feature, and preferred the one that did more? …

Would you pay more money for a washing machine with fewer controls? In the abstract, maybe. At the store, probably not.

Donald Norman’s assessment sounds wrong at first. Don’t we all like things to be simple? Not if by “simple” we mean “fewer features.”

A general theme in Living with Complexity is that complexity is inevitable and often desirable, but it can be managed. We say we want things that are simple, but we really want things that are easy to use. The book gives several examples to illustrate how different those two ideas are.

If something is complex but familiar and well designed, it’s easy to use. If something is simple but unfamiliar or poorly designed, it’s hard to use.

Related posts:

Confusing familiar with simple
Adding simplicity
A little simplicity goes a long way

{ 9 comments }

A dozen posts on simplicity and complexity

by John on September 15, 2010

Here are a dozen previous posts on simplicity and complexity.

  1. Obscuring complexity
  2. Three quotes on simplicity
  3. Complexity and unity
  4. A little simplicity goes a long way
  5. Simple legacy
  6. Simplicity in old age
  7. Software that gets used
  8. Conservation of complexity
  9. Confusing familiar with simple
  10. Four mechanical devices
  11. Rewarding complexity
  12. Stupidity scales

{ 2 comments }

Is helpful software really helpful?

by John on August 24, 2010

In his new book The Shallows, Nicholas Carr relates an experiment by Christof van Nimwegen on computer-human interaction. Users were asked to solve a puzzle using software. Some users were given software designed to be very helpful, highlighting permissible moves etc. Other users were given bare-bones software.

In the early stages of solving the puzzle, the group using the helpful software made correct moves more quickly than the other group, as would be expected. But as the test proceeded, the proficiency of the group using the bare-bones software increased more rapidly. In the end, those using the unhelpful program were able to solve the puzzle more quickly and with fewer wrong moves.

I immediately thought of the debate over fancy software development tools versus simple tools. Then I read the conclusion:

… those using the unhelpful software were better able to plan ahead and plot strategy, while those using the helpful software tending to rely on simple trial and error. Often, in fact, those with the helpful software were found “to aimlessly click around” as they tried to crack the puzzle.

That really sounds like software development.

Christof van Nimwegen did variations on his experiment and got similar results. For example, he had two groups schedule a complicated series of meetings. One group had plain calendar software and one had software designed to help people schedule complicated meetings. The folks with the simple software won.

The debate over whether to use fancy software development tools (e.g. integrated development environments, wizards, etc.) or simple tools (editors and make files) is a Ford-Chevy argument that won’t go away. I could imagine many valid objections to the applicability of the van Nimwegen studies to the software tools debate, but I’d say they score a point for the simple tools side.

A rebuttal to the van Nimwegan studies is that he has only shown that particular helpful software wasn’t particularly helpful. Maybe the specific puzzle-solving software didn’t help in the long run, but someone could have written software that was ultimately more helpful than the bare-bones software. Maybe someone could have written scheduling software that allows people to schedule tasks faster than using simple calendar software.

A rebuttal to the rebuttal is that someone might indeed write software that allows users get the job done more quickly than they would using simpler software. It may even be inevitable that someone will write such software eventually. However, most attempts fail. It’s hard to write genuinely helpful software. Attempts to help a user too much may interfere with the user’s ability to form a good mental model of the problem.

Related post:

Would you rather have a chauffeur or a Ferrari?

{ 16 comments }

Defining minimalism

by John on August 20, 2010

I stirred up some controversy yesterday with an article critical of extreme minimalism. Some people took my article as an attack on minimalism in general. I wanted to clarify a few thoughts on minimalism.

I’m attracted to the general idea of minimalism, though I don’t like the name. “Minimal” literally means an extreme. I appreciate moderate minimalists, though strictly speaking “moderate minimalist” is a contradiction in terms. A more accurate but unwieldy name for minimalists might be “people who are keenly aware of the indirect costs of owning stuff.” Possessions have to be dusted, oiled, upgraded, insured, etc. Eliminating unnecessary things frees up physical and mental space.

Minimalists want to pare down their possessions to a minimum. But an absolute minimum would be to own nothing. Instead, minimalists want to eliminate non-essentials. So you could define a minimalist as someone who wants to eliminate non-essential possessions (or more generally non-essential intangibles as well). But by that definition, Donald Trump would be a minimalist if he believes everything he owns is essential. The essence of minimalism is an aesthetic for what constitutes “essential.”

One final complaint about the term “minimalism” is that it implies that a minimalist’s goal in life is to minimize possessions. I imagine most people who call themselves minimalists do not want to be obsessed with eliminating stuff any more than they want to be obsessed with acquiring stuff. They just want to think about their stuff less.

Related posts:

Adding simplicity
You pay for what you don’t use

{ 9 comments }

Stupidity scales

by John on July 19, 2010

I’m fed up with conversations that end something like this.

Yes, that would be the smart thing to do, but it won’t scale. The stupid approach is better because it scales.

We can’t use common sense because it doesn’t fit on a form.

We can’t treat people like people because that doesn’t scale well.

We can’t use a simple approach to solve the problem in front of us unless the same approach would also work on a problem 100x larger that we may never have.

If the smart thing to do doesn’t scale, maybe we shouldn’t scale.

Related posts:

Organizational scar tissue
Rewarding complexity
What’s wrong with paper?

{ 14 comments }

Rewarding complexity

by John on April 5, 2010

Clay Shirky wrote an insightful article recently entitled The Collapse of Complex Business Models. The last line of the article contains the observation

… when the ecosystem stops rewarding complexity, it is the people who figure out how to work simply in the present, rather than the people who mastered the complexities of the past, who get to say what happens in the future.

It’s interesting to think how ecosystems reward complexity or simplicity.

Academia certainly rewards complexity. Coming up with ever more complex models is the safest road to tenure and fame. Simplification is hard work and isn’t good for your paper count.

Political pundits are rewarded for complex analysis, though politicians are rewarded for oversimplification.

The software market has rewarded complexity, but that may be changing. There’s a growing demand for simpler products, and software vendors are responding. For example, no one has ever accused Microsoft of having a minimalist aesthetic, but Window Phone 7 looks like a bold departure from Microsoft’s bloatware past.

Related posts:

Organizational scar tissue
Good, fast, or cheap: Can you really pick two?
Maybe NASA could use some buggy software

{ 7 comments }

Confusing familiar with simple

by John on March 25, 2010

Is Spanish simpler than Chinese? Most English speakers would think so, though that may not be true. Spanish is more familiar than Chinese if you’re an English speaker, but that does not mean the language is objectively simpler. In fact, linguists have a theory that all human languages are about equally complex, though they allocate their complexity in different areas. For example, Chinese has a complex tonal system, but I’ve been told its grammar is relatively simple.

We often confuse familiar with simple. Rich Hickey makes this observation in the context of programming languages, though the principle applies much more generally.

I think programmers have become inured to incidental complexity, in particular by confusing familiar or concise with simple. And when they encounter complexity, they consider it a challenge to overcome, rather than an obstacle to remove. Overcoming complexity isn’t work, it’s waste.

In some sense the familiar is simple. Familiar things have less perceived complexity, and sometimes perceived complexity is all that counts. But perceived complexity is personal. We can forget that familiarity clouds our judgment about complexity. We may recommend something familiar but complex to someone else who finds it unfamiliar and complex. Teachers have to keep in mind what students find complex. Programmers have to keep in mind what users find complex. Doctors have to keep in mind what patients find complex.

However, familiarity and perceived complexity can be deceiving even though no one else is involved. You may find something familiar and not realize how much effort you’re devoting to fighting its complexity. It’s easy to assume that things must be as complex as they are. I didn’t realize how complex clarinet was until I learned to play saxophone. I didn’t realize how complex C++ was until I had some experience with other programming languages. I didn’t realize how complex some desktop software was until I tried online alternatives.

The complexity of the familiar may not be apparent until you look closer. Nothing could be more familiar than the experience that the sun and planets go around the earth. That is a simple explanation until you look at orbits more carefully. Then you start introducing epicycles on top of epicycles to preserve the earth-centric model.  You may find that what you thought was simple was only familiar, and that what you dismissed as more complex was only less familiar.

{ 5 comments }

A dozen posts on simplicity

by John on March 23, 2010

Here are a dozen posts I’ve written about simplicity.

  1. Adding simplicity
  2. Simplicity in old age
  3. Three quotes on simplicity
  4. Simple legacy
  5. Software that gets used
  6. Conservation of complexity
  7. Perlis on complexity
  8. Abstractions are never perfect
  9. Conflicting ideas of simplicity
  10. Manual devices better than motored devices
  11. Try the simplest thing that could possibly work
  12. A little simplicity goes a long way

{ 1 comment }

Here are four mechanical devices I prefer to their modern counterparts.

French press. It makes better coffee than a typical coffee machine. Also, a French press work without electricity. Next time a hurricane comes through Houston and knocks out our power, I can still make my coffee.

Reel mower. I had gasoline powered lawn mowers until last year. Sometimes they’d start, sometimes they wouldn’t. My reel mower always starts. And it’s quiet.

Rake. I had a leaf blower once. It was obnoxiously loud and a nuisance to my neighbors. I much prefer raking leaves even though it takes longer.

Pencil sharpener. With four children, we sharpen a fair number of pencils. We have owned a couple electric pencil sharpeners. They were noisy, hard to use, and soon wore out. Our mechanical pencil sharpener is cheaper and far more reliable.

I’m no Luddite, but I firmly believe that newer isn’t necessarily better.

Related posts:

Selective use of technology
Tim Bray’s high-tech monastic cell
Software bloat
What’s wrong with paper?

{ 16 comments }

Adding simplicity

by John on March 15, 2010

Simplicity is costly. You have to give up something to achieve it. You can’t just add it on top. William Bridges illustrates this in his book The Way of Transition where he describes his moving out to the country.

… I had been infatuated with Thoreau’s Walden and its story of living a basic life, close to nature. The heart of that undertaking, he had written, was to simplify your life. … In retrospect, I can see that although I thought that this was what I was doing, I was really just trying to add simplicity to my life. In addition to all the old things I had been doing … Of course, my life grew more and more complicated in the process.

A simplification has to remove or replace something else. You can’t just add on simplicity.

There may be an exception to this. Sometimes you can add a few missing pieces to make something more symmetric. In that case, the additions simplify the whole. (Mendeleev did something like this when he drew his periodic table.) Even then, I suppose you could say you’re removing the asymmetry. In any case, achieving simplicity usually requires more subtraction than addition.

Related posts:

Simplicity in old age
Simple legacy
A little simplicity goes a long way

{ 4 comments }

Abstractions are never perfect

by John on January 11, 2010

Better to have a simple system than a complex system with a simple abstraction on top.

Abstractions are never perfect. Every new layer creates failure points, interoperability hassles, and scalability problems. New tools can hide complexity, but they can’t justify it … The more complex the system, the more difficult it is to fix when something goes wrong.

From the preface to RESTful Web Services.

Related posts:

Obscuring complexity
Baklava code
Leaky abstractions
Less isn’t more; just enough is more

{ 0 comments }