[dagw]

That's all well and good, but still "make it work" should always come before "make it fast". For example the code I'm writing right now in my other window is terribly inefficient, quite naive and may very well have to be re-written, but I don't care at the moment. All I care about right now is: Is what I'm trying to do actually practically possible in the general case. If so what approach will give the best/good enough results. And finally, if I manage to do what I'm trying to do, will this particular approach offer a better solution to the higher level problem I'm dealing with than my other approach.

Once I've answered "yes" to all those questions then I can think about heading back and trying to make it fast. Writing really high performance code that doesn't solve the problem you have or give you the results that you need is, of course, a waste of time.

[kasey_junk]

You misunderstand "make it work" includes performance goals. The difference is if you consider them upfront it includes the explicitly not implicitly.

You'd never say that the you've made the code "work" if you knew it would take 3x of your budget to get there. Similarly with performance, it doesn't "work" if it doesn't meet the perf goals of the project, no matter how relaxed they might be.

[dagw]

I guess we're arguing semantics at this point. For me "make it work" means that I'm able to write a piece of code that takes the input I want and returns the output I want eventually, doesn't matter if it takes a week instead of a minute to run. Before I get to that point then any optimization I do is probably not the best use of my time. Also if I can't get to that point then it means I really don't understand the underlying problem and I'm probably not in a position to start reasoning about making it fast.

Generally speaking I find it much easier to take slow, working code and making fast, as opposed to fast, broken code and making it work.

[kasey_junk]

Generally speaking I don't. The only way I've ever been able to be successful on the performance front is to conclude that code that is slow is broken, not that it is working before then.

Backing into acceptable performance after the fact just doesn't work for the problem domains I work in (which on first blush have not been exclusively performance based).

[oldmanjay]

If your attitude is shaped by narrow problem domains, why argue with people as if you were talking about the general case?