Should I use "if" or "try" (as a matter of speed)?

[Peter Hansen]

Edvard Majakari wrote:
> "first make it work, then make it right, then make it fast"
> 
> Shouldn't one avoid doing it the wrong way from the very beginning? If you
> make it "just work" the first time, you'll probably use the old code later on
> because "functionality is already there" and temptatation to build on probably
> relatively bad architecture can be too strong.

The expression describes (most recently, if not originally) the practice 
in Test-Driven Development (TDD) of making your code pass the test as 
quickly as possible, without worrying about how nice it is.

The "right" part doesn't refer to correctness, but to structure, style, 
readability, and all those other nice things that an automated test 
can't check.  You aren't doing it "wrong" at first, just expediently.

And it really does make sense, because at that early stage, you aren't 
even absolutely certain that your test is entirely correct, so making 
your code a paragon of elegance is a potential waste of time, and 
distracting.  Once you've been able to pass that test (and all the 
others, since you have to make sure all previous tests still pass as 
well), then and only then is it sensible -- and required! -- to refactor 
the code to make it elegant, concise, clean, etc.

Of course, your point about temptation is sound.  Extreme Programming 
tries to avoid that problem partly by pairing programmers together, and 
it is the responsibility of both partners to encourage^H^H^H^H^H insist 
that the refactor "make it right" stage must occur _now_, before we 
check the code in.  If you skip this step, you're failing to be an agile 
programmer, and your code base will become a tar pit even more quickly 
than it would in a traditional (non-agile) project...

-Peter