A programming language is a tool for handling design complexity. That’s what all of computer science is, really — languages, libraries, type systems, garbage collectors, everything you learn about programming. They’re ways to build more and more complex designs without losing your grip.

The way you manage complexity is to be able to ignore it. A good programming tool lets you forget about some part of the problem, so that you can focus on some other part. And it ensures that when you return to the parts you forgot, you haven’t accidentally broken them.

–Andrew Potkin

Years ago, When I was taking to programmers about what college I wanted to attend, I had in interesting conversation about how Computer Science education is an utter failure at preparing students for real-world programming. Outside of Software Development, no technical field accepts (sometimes prefers) candidates with “N years of experience” in place of a degree. I’m not sure I know why CS education fails so badly and universally. But my current best guess is that it’s because school never exposes you to enough complexity. Projects have to end in a semester. You never have to deal with a multimillion-line program, written by hundreds of co-workers, dozens of which you need to collaborate with, at unexpected times, for surprising reasons.

…control interfaces must not be intelligent. Briefly, intelligent user interfaces should be limited to applications in which the user does not expect to control the behavior of the product. If the product is used as a tool, its interface should be as unintelligent as possible. Stupid is predictable; predictable is learnable; learnable is usable.

–Mencius Molbug

Jeff Raskin calls this principle it monotony, and explains it comprehensively in The Humane Interface.

I’ve always felt a little uneasy about the idea. Computers are supposed to free us from tedium and repetition, by doing things for us. A fluid interface is unnatural yes, but the goal of computing should be to exceed what’s possible in the corporal word, not to copy it imperfectly.

But fundamentally, I think Raskin and Molbug are more right than wrong. Paradoxically, dumb interfaces beat smart interfaces most of the time.

One of the oldest canards in the interface business is the one that says “Maximizing functionality and maintaining simplicity work against each other in the interface” (Microsoft 1995, p.8). What is true is that adding ad hoc features works against simplicity. But that’s just bad design. It is often, but not always, possible to increase functionality without increasing difficulty at a greater rate. Often, added functionality can be had without any added interface complexity; note the difference between interface complexity and task complexity. If the added functionality unifies what had previously been disparate features, the interface can get simpler.

– Jeff Raskin, The Humane Interface (page 201)

Examples of this are the exception, not the rule. Usually, more features means more complexity.

The best example I can think of is Coda, an award-winning web development IDE.

text editor + file transfer + svn + css + terminal + books + more = whoah.

The story of Coda.

So, we code web sites by hand. And one day, it hit us: our web workflow was wonky. We’d have our text editor open, with Transmit open to save files to the server. We’d be previewing in Safari, adjusting SQL in a Terminal, using a CSS editor and reading references on the web. “This could be easier,” we declared. “And much cooler.”

(To really get a sense of Coda you should check out the website, or try it for free).

Even though Coda’s interface is more complicated because it does more then just edit code, it simplifies the task of web-design, by unifying tasks that used to be done in different applications with different interfaces.

What other examples of things becoming simpler through added functionality can you think of? Please share in the comments below.

Even if we had the fast computers we have today in the 1960′s, and even if we had the internet, we could not have built a modern web-browser, because we did not understand enough about building programs of that complexity.

It’s amazing how young software development is as a discipline.

Complexity is the worst enemy of security; as systems become more complex, they get less secure.

–Bruce Schneier

There are a lot of problems that are, in theory, incredibly difficult – but because the difficult cases are very rare and rather contrived, they’re actually very easy to solve. Two examples of this that I find particularly interesting are both NP complete. Type checking in Haskell is one of them: in fact, the general type inference in Haskell is worse that NP complete: the type validation is NP-complete; type inference is NP-hard. But on real code, it’s effectively approximately linear. The other one is a logic problem called 3-SAT. I once attended a great talk by a guy named Daniel Jackson, talking about a formal specification language he’d designed called Alloy. Alloy reduces its specification checking to 3-SAT. Dan explained this saying: “The bad news is, analyzing Alloy specifications is 3-SAT, so it’s exponential and NP-complete. But the good news is that analyzing Alloy specifications is 3-SAT, so we can solve it really quickly

–Mark Chu-Carroll (aka MarkCC