DEBRIS.COMgood for a laugh, or possibly an aneurysm

Jason Fried of 37signals gave an eye-opening presentation at Web 2.0 today: less is more! This was the best, most directly useful presentation I’ve heard so far.

Less is a competitive advantage. Trying to one-up everyone else is a “Cold War” mentality. Instead, try to one-down the competition. Beat them with less.

There are five things software developers need less of:

1. Less money
2. Less people
3. Less time
4. Less abstractions
5. Less software

Less money
Taking on a big investment used to be the way businesses would get started. But all that investment gets you is debt. Debt doesn’t make you build better products. Debt doesn’t make your customers happy.

Money used to buy hardware, but now hardware is cheap. It used to buy software, but now software is cheap. Money could never buy time or passion, and passion is the one thing you need in quantity.

The one thing money could buy is salaries, meaning people. But maybe you don’t need those either…

Less people
You need only three: a designer, a programmer, and a “sweeper” to do everything else (including marketing).

Don’t scale the team up to fit the vision or the feature set. Instead, scale the vision down to fit the size of the team.

Less time
Having less time is a good thing, a huge competitive advantage. Most of the time spent in most companies is wasted: meetings, overbuilding, overanalysing. Having less time forces you to spend it smarter. Spend it only on the important things — building the software.

Less abstractions
Just build things. don’t write about them. Don’t draw pictures. And whatever you do, never never never make a “functional spec.” This is the biggest abstraction of all, and there is nothing functional about it. A long text document has nothing to do with a great piece of software.

Functional specs are political documents. They’re “yes documents” — every feature is a bullet point; it’s easy for people to say “yes, add that.” Worst of all, they create the illusion of agreement. You spend three months hammering out the functional spec, but three months later you find that everybody disagrees about what’s in the functional spec, and the finished product (if and when it is ever finished) looks nothing like the functional spec anyway.

Instead, just build the product. Build the UI first. Then wrap that with the technology. Have the technology fill in the back end. Work on the customer experience first; that’s the most important thing. Have the interface screens be the functional spec.

Building software is an iterative process. Iterate over the built product, not the abstractions.

Less software
Build less (complex) software. You’ll need less support… less help text… less documentation… less sales effort…

There are a million simple problems that need to be solved. Solve those first — but nail them. You won’t succeed at solving the complex problems anyway.

More of what?
The only thing you want more of is constraints. Less time, less money, fewer people, these are all constraints. They’ll squeeze you. But the result will be a higher-quality product.

Update: Jason’s notes are here. And Robert Kaye’s article is here.