The door was unlocked

From the dedication of C. S. Lewis’ A Preface to Paradise Lost:

Apparently the door of the prison was really unlocked all the time; but it was only you who thought of trying the handle.

In context he was saying that Charles Williams had recovered a clear understanding of Milton that had been obfuscated for over a century.

That line made me think of a quote from Alexander Grothendieck (that I haven’t been able to find this morning) to the effect that progress in mathematics has often waited for someone to be bold enough to ask a simple question or introduce a simple concept.

Update: Thanks to Roland Elliot for providing the quote I was missing. Ronald Brown says that Grothendieck said in a letter to him in 1982:

The introduction of the cipher 0 or the group concept was general nonsense too, and mathematics was more or less stagnating for thousands of years because nobody was around to take such childish steps …

Complex for whom?

From Out of the Tar Pit:

… the type of complexity we are discussing in this paper is that which makes large systems hard to understand. It is this that causes us to expend huge resources in creating and maintaining such systems. This type of complexity has nothing to do with complexity theory — the branch of computer science which studies the resources consumed by a machine executing a program. The two are completely unrelated — it is a straightforward matter to write a small program in a few lines which is incredibly simple (in our sense) and yet is of the highest complexity class (in the complexity theory sense).

Related posts:

Simplicity is hard to sell

People say they want simple things, but they don’t. Not always.

Donald Norman argues in Living with Complexity that people really want things that are easy to use, not things that are simple. They want things that are familiar, even if the familiar is complex.

People also want all the features they can handle. If you’re competing with a product that is overwhelmingly complex, then simplicity sells. Otherwise simplicity is perceived as weakness. The more features the better. People may enjoy using simpler products, but they buy complex ones.

It’s hard to remove even vestigial features. If people are in the habit of doing something that is no longer necessary (or never did add much value), you’ll have a lot of work to do to convince them that it’s OK to let go of it.

Related post: Simple versus easy

Simple versus easy

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

How has math changed your view of the world?

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 sometimes 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:

Third-system effect

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:

Demand for simplicity?

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:

Is helpful software really helpful?

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?

Defining minimalism

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:

Stupidity scales

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 treat people like people because that doesn’t scale well.

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

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:

Rewarding complexity

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.

Related posts:

Confusing familiar with simple

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.