[ogreveins]

Here's a priority list that you should typically follow for making anything.

1. Make it work.

2. Make it not break.

3. Make it fast.

That's it really. Until the performance of something is blocking what you need to do somewhere else leave it the hell alone.

[rednab]

Per (as far as I can tell) the original: http://c2.com/cgi/wiki?MakeItWorkMakeItRightMakeItFast

1. Make it work.

2. Make it right.

3. Make it fast.

[ogreveins]

Wow, I honestly never read that. +1 for the link, I love old stuff like this.

[gohrt]

Make it run, right, rapidly.

[nickpsecurity]

Butler Lampson

http://research.microsoft.com/en-us/um/people/blampson/33-hi...

Unfortunately, his current employer chose a different order: 3, 1, 2. Sometimes they drop 1, 2, or 3 separately or in groups at random. Gotten much better at 2 and 3, though.

[koolba]

4. Throw it away and rebuild it now that you know how it really should work.

[6stringmerc]

In some cases this is excellent advice regarding a story or essay re-write as well.

[firebones]

Your coda is often forgotten, and sometimes "Make it Fast" is essential to making it work.

[1] http://c2.com/cgi/wiki?DesignForPerformance

[danieltillett]

1. Make it work.

2. Ship it before your competitor does.

[reefoctopus]

4. Make it manageable.

[ianstormtaylor]

I'd probably swap them:

1. Make it work.

2. Make it not break.

3. Make it manageable.

4. Make it fast.

Otherwise I find that trying to make something fast before making it manageable usually ends up in crazy hacks that are hard to undo later.

[billylindeman]

In hardware dev I've followed a similar paradigm from an old mentor:

1) Make it work

2) Make it work better

3) Make it work cheap

[blakeyrat]

Make it USABLE. USABLE. Study its USABILITY.

The world doesn't need more crummy unusable software.

[siliconc0w]

I use crummy unusable software all the time because it's good.

[eterm]

I've seen that as:

1. Make it

2. Make it work

3. Make it fast