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.

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

c2 is a great wiki. Start googling languages and programming phrases with site:c2.com at beginning. You'll find some good stuff. Unfortunately, its commenting got shut down shortly after I discovered it. I think I read all the debates and stuff. Too many haha.

Note: The debates over LISP, OOP, Cleanroom, Smalltalk, and so on are all especially interesting.

Make it run, right, rapidly.

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.

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

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

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

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

1. Make it work.

2. Ship it before your competitor does.

4. Make it manageable.

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.

3.5 Profile it to see whether or not it needs to be faster

If you profile it on a fast machine, your results might lie to you.

Or on a machine on a fast network, or SSD vs spinning-rust, or any number of varying factors.

I'd agree with this. My last couple of projects did have a couple of hacks that bordered on spaghetti code until they were sufficiently cleaned up.

It's less likely to break if it's manageable first.

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

Make it USABLE. USABLE. Study its USABILITY.

The world doesn't need more crummy unusable software.

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

I've seen that as:

1. Make it

2. Make it work

3. Make it fast