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

[Edvard Majakari]

Peter Hansen <peter at engcorp.com> writes:

>> "first make it work, then make it right, then make it fast"
...

> 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.

Ack(nowledged).

> 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.

Yes, that I understood; if the first version worked, it had to be correct
already. But as I said, if you want to make ideas easy to remember, you have
to make them short enough, and you can probably assume the reader understands
more than what is explicitly stated. I didn't know the expression originates
from TDD, that puts it in a bit different light - and makes it more
understandable IMO.

> 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,
  ^^^^^^^^^^^^^^^^^^^

:-D

Which is a seductive trap, that.. really, I mean, how many times you've
polished a module so much that you would want to publish it in every single
article you write about computing as an ideal example, one you care about and
nurture like it was your own child (or your fancy-schmancy, model '74
V12-engine, chrome-plated, mean monster-of-a-vehicle car, if you are one of
those types)? Then you report your progress to your superior and feel ashamed
because the only thing you've worked with in last 3 weeks is that (my)
precious(!) module.. hum. But I digress.

> 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.

Yep. And thats one of the reasons I really like TDD and unit testing - you
know when to stop working with a piece of code. When all the tests pass, stop.

> 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...

Yup. Too bad I've had the opportunity to work that way (pair programming) only
few times, and even then it wasn't XP-style in any other way. It is too often
considered waste of labour, I guess.

-- 
# Edvard Majakari		Software Engineer
# PGP PUBLIC KEY available    	Soli Deo Gloria!

"Debugging is twice as hard as writing the code in the firstplace. Therefore,
 if you write the code as cleverly as possible, you are, by definition,
 not smart enough to debug it."  -- Brian W. Kernighan