"Phlip" <phlip_cpp / yahoo.com> wrote in message
news:9tuvmc$6g7 / dispatch.concentric.net...

> > design. They will not find the major logical flaws anyway.
>
> For many, these big chunks add risk. A lifecycle that's more idiot-proof
> would alternate tiny sessions of design with tiny sessions of coding and

I know - it works for me, but I realize that not everyone can work that way.
I guess I adapt my testcycles to the sitation given. I often find myself in
sitations where I can't just write a decent test case because it would
require a lot of infrastructure that isn't in place. However, at later
stages I do test often, and I'm not afraid to change my design or code. I've
been advocating rewriting code long before I knew the letter X. I also
occasionally spend 90% of the coding time on test code so I'm not against
testing. I just don't like to let the testcode drive my design - it seems
like the robot finding the way in a maze by turning left each time it bumps
into a wall. I'd rather try to get a birds perspective.

> tiny ones of testing, repeating over and over again. Test code is easy to
> write, so write it first; and use it to help you write the production
code.
> Design is hard, so do it last. Engineers always try to defer the hard
> decisions as long as possible, until they become easy.

Not sure whether you're being serious or joking here ("design is hard so do
it last"). It sounds like speeding so you have less time on the road where
you can be exposed to an accident. That said, it is easy to try to
overdesign and never reach a conclusion. At some point you have to start
coding and learn from the experience.
Getting a complex indexing problem wrong is not funny. Which is exactly what
I have recently done because I chose to focus on read first and then
implement write later on. As it turns out write is much harder than read -
and I should have been thinking about that earlier on rather than just
hoping for the best. There is always a limit to how far you can see in the
design, but the time you spend thinking is well spend. And I know - then I
learned about a new problem, so I should just go back and rewrite my code -
which is exactly what I'll do.

Depending on your level of skill, it may be an issue with these tiny bugs
that amount to a whole population at the time the implementation is
complete. On the other hand I've seen some very skilled developers produce
very few bugs and yet come out with design flaws that had to be fixed at
later stage thus impacting code written by several other people. Such
problems are unavoidable but they are important to reduce. This is not the
kind of problems that a test first approach would have helped you to
eliminate. So there is nothing wrong with testing often, but the risc is
that it makes you believe you have a sound design because the test is
working.

MikkelFJ