Re: Do you still Write Tests First on code that is churning hard?

On 19 February 2010 08:59, Erik P. [email protected] wrote:

creating more debugging time for myself than I’m saving without
I think you can consider writing a completely separate spike to explore
bar etc. or perhaps you need to go more granular and create some tools to
simplify your calculations. Finally if you have any long methods in your
calculations (> than 5 lines) refactor them. Decomposing them into smaller
methods could reveal alot about the structure of your problem



I’m a bit with Andrew on this. I think you are not asking the right

In TDD/BDD I view writing the tests/spec as PART of writing the code, so
you are questioning the value of spending the time to write the specs,
lamenting that you feel this is wasted effort, I have to ask why are you
questioning the value of even writing code when the target is changing
frequently? Why don’t you feel that the code itself that you’ve had to
discard/rewrite/refactor so much has not also been wasted effort? How
what you are doing going to deliver value to the end user?

If this is a case where someone else can’t make up their minds what they
want, then potentially it might be a situation where writing the code
is just a waste of time, much less writing the specs, and you need to
your effort elsewhere until what is needed is better known.

OTOH, if this is a situation where you are doing a lot of
and discovery, and the writing of the code is necessary to figure out
will work’, then the writing of tests might not add value and just being
slowing you down. I’d base that judgement on the degree to which the
itself is considered disposable and the likelyhood that it won’t ever
it into production ‘as is’. In that case, then there may not be much
to fleshing out anything but the high level spec definitions (just as a
means of keeping straight what you are trying to do this iteration, and
potentially a type of documentation to others of what ‘approach number
is supposed to take for inputs and produce for outputs.

Kent Beck touches on this in his ‘flight of the startup’ blog post and a followup
for the flight of the startup’ and he makes some good
points about when it pays to be dogmatic about some agile practices such
TDD, and when it’s better to put some of those practices aside depending
what it is that you are trying to deliver to the customer at a
point in the project.

If you are currently in the phases Kent describes as Taxi and Takeoff,
you could very well be right to dispense with a majority of tests and
practices that are needed for maintainable high quality code. (because
you’re not trying to deliver highly maintainable code.) OTOH if you are
the Climb or Cruise stages, then I’d be greatly concerned that ‘what we
building’ is in such a constant state of flux, and I’d suggest something
a smell that’s ungood.

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs