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 -- http://mail.python.org/mailman/listinfo/python-list
