(This is a snapshot of my old weblog. New posts and selected republished essays can be found at raganwald.com.)

Wednesday, April 09, 2008
  Design Matters

The recent hoo-haw over whether the Do-No-Evil Empire launched an Attack of the Clones gives us a great opportunity to think about design and its value:

[Some people are] more or less arguing that it’s ridiculous to claim that 37signals somehow owns the concept of web-based group chat. Which is stupid, because no one made that argument. (Does Artie MacStrawman have a web-app cousin?)

Consider, say, Movable Type and WordPress. WordPress came along with a free (beer and freedom) package that does the same basic thing as Movable Type and took a big chunk of the market away. But I’ve never seen anyone call WordPress a rip-off or clone of Movable Type. Why? Because it isn’t. It’s an original implementation of the same basic idea.

A new implementation of the same concept is competition; a clone of an existing implementation is a rip-off.
John Gruber

As is often the case, Gruber’s analysis of the difference between the concept and the implementation is spot-on. The distinction is important to John: he’s deeply involved in the design community, where people care very much about the value one can add by coming up with a better implementation of the same concept.

We saw a variation of this thinking when Rails was released: more than a few people claimed there was nothing new in Rails, it was “just” a framework for building CRUD applications, and a lightweight framework by the measure of how many new things you could do with it.

But the value in Rails is its design, in the way you put those CRUD applications together. Love it or hate it, Rails is an exercise in design, an exercise in user interfaces for programmers. At the time, it was a unique implementation of an existing and well-known concept.

Don’t we agree, for example, that Grails is a clone of Rails while Camping is not? One clones the implementation on a different platform, one does not.

People claim that certain ideas are “obvious” and therefore should be copied at will. I find it easy to think that something is obvious after you’ve looked at it and studied it. But the true test of “obviousness” is to go into a clean room, having never seen the original, and come up with what you imagine is an original design that does a good job of fulfilling the requirements of the concept.

If you arrive at the same design independently, you have a decent argument that the design is obvious.

What really matters

I’m going to change tacks here. If you are sitting down to make something, don’t clone an existing thing. Why? Because you can do better!

Before Rails was released, I’m quite certain that 999 out of 1,000 web developers would have told you that CRUD development was “mature” and “done.” If you wanted to create a new framework, most people would expect you to clone existing ideas.

But guess what? It wasn’t done, there was still value to be had doing the old thing in a new way. Likewise with music players and… must I make a list of 10,000 things where people thought the concept was mature and devoid of innovation, then someone found a new way to execute the existing concept, but their design was better and they reinvented the whole thing without adding new features?

You can do better. And that’s the point. Not whether the party of the first part should have done better, or whether the party of the second part should have complained about whether the party of the first part actually did better or not. I don’t care who did what, where it was hosted, when the concept was invented, and why it has generated so much debate. And in a few days, neither will you.

But what will always matter is what you and I choose to do with our very limited time while we are here. Not what they choose to do or not do with their time and their talents.

I hope you will alway choose to strive to create something new, to never take it for granted that we can’t do better with even the most allegedly mundane problems to solve. Like chat line, CRUD frameworks, design patterns, programming languages, choosing our team mates, or mobile telephones.

Comments on “Design Matters:
I'd agree with you if Campfire's UI was one of the more interesting or innovative aspects of its overall design. It's not, though, IMO.

What's interesting about Campfire is that it's on the web (linkable, persistent, a shared resource), that it's hosted by someone that's not you, and the underlying polling mechanism. The GAE-based clone is innovative in each of these respects.

If Toyota were to clone NASA's space shuttle and made it available to consumers, would people gasp when it was white with a black belly? The whole thing seems kind of silly to me.

That being said, the GAE folks should have started with a blank slate on the UI, if only because its the easiest part of the whole system.
Thanks for your perspective!

As I said when closing the post, my real interest is in encouraging us (and by us, I definitely mean this as a reminder to myself) to never think smething is “obvious” and therefore done, but to always look for a way to add value through good design.
The distinction seems to whoosh right on by people who care deeply about the concepts and think of design as something that gets slapped onto an application by an intern with photo shop skills a few days before it goes live.

I think this is one reason why a lot of software features don't get used.

I'm a programmer currently working as a graphic designer, and I finally realized how implementation-specific graphic design solutions actually are. If I follow you correctly, I think this is sort of what you are getting at.
"...must I make a list of 10,000 things where people thought the concept was mature and devoid of innovation, then someone found a new way to execute the existing concept, but their design was better and they reinvented the whole thing without adding new features?"

In case anyone is looking for more examples, you could do worse that Henry Petroski's The Evolution of Useful Things. Its basic idea is that many things (paperclips, zippers, forks) were invented by modifying existing designs, by people who were unsatisfied with them.
Thank you!

This is exactly where I was going. Imagine how cool it will be when someone rolls out their own chat application but it recombines the existing feature set in some really wild new way!
The lamest thing about the unnamed-not-sure-if-they-are-evil empire's new offering is the lock in to one language.

On that note, what is new and original is often recycled or rediscovered. In the example of music, there is a Beatles song that you can stylistically link to nearly every modern genre.

For Rails, there are examples of code generation and CRUD before, but putting them together in a new context pushed web app frameworks forward to new possibilities.

Take home messages: new isn't always new, the past can teach you a lot and the unnamed empire inexplicable alienated many developers on several levels.
I really enjoyed this post.
Thanks, Mike!

<< Home
Reg Braithwaite

Recent Writing
Homoiconic Technical Writing / raganwald.posterous.com

What I‘ve Learned From Failure / Kestrels, Quirky Birds, and Hopeless Egocentricity

rewrite_rails / andand / unfold.rb / string_to_proc.rb / dsl_and_let.rb / comprehension.rb / lazy_lists.rb

IS-STRICTLY-EQUIVALENT-TO-A / Spaghetti-Western Coding / Golf is a good program spoiled / Programming conventions as signals / Not all functions should be object methods

The Not So Big Software Design / Writing programs for people to read / Why Why Functional Programming Matters Matters / But Y would I want to do a thing like this?

The single most important thing you must do to improve your programming career / The Naïve Approach to Hiring People / No Disrespect / Take control of your interview / Three tips for getting a job through a recruiter / My favourite interview question

Exception Handling in Software Development / What if powerful languages and idioms only work for small teams? / Bricks / Which theory fits the evidence? / Still failing, still learning / What I’ve learned from failure

The unary ampersand in Ruby / (1..100).inject(&:+) / The challenge of teaching yourself a programming language / The significance of the meta-circular interpreter / Block-Structured Javascript / Haskell, Ruby and Infinity / Closures and Higher-Order Functions

Why Apple is more expensive than Amazon / Why we are the biggest obstacles to our own growth / Is software the documentation of business process mistakes? / We have lost control of the apparatus / What I’ve Learned From Sales I, II, III

The Narcissism of Small Code Differences / Billy Martin’s Technique for Managing his Manager / Three stories about The Tao / Programming Language Stories / Why You Need a Degree to Work For BigCo

06/04 / 07/04 / 08/04 / 09/04 / 10/04 / 11/04 / 12/04 / 01/05 / 02/05 / 03/05 / 04/05 / 06/05 / 07/05 / 08/05 / 09/05 / 10/05 / 11/05 / 01/06 / 02/06 / 03/06 / 04/06 / 05/06 / 06/06 / 07/06 / 08/06 / 09/06 / 10/06 / 11/06 / 12/06 / 01/07 / 02/07 / 03/07 / 04/07 / 05/07 / 06/07 / 07/07 / 08/07 / 09/07 / 10/07 / 11/07 / 12/07 / 01/08 / 02/08 / 03/08 / 04/08 / 05/08 / 06/08 / 07/08 /