rspec users - Feb 2010 - Do you still Write Tests First on code that is churning hard?

Hello Specmeisters!

I have a bit of a philosophical question for the TDD witches and
wizards out there.  I''m working on some code that is really
churning... It''s doing complicated calculations, but the actual
desired results are a moving target. The acceptable values, and even
the structure of the software''s output are changing constantly.  The
internal architecture is changing rapidly, and I''m constantly throwing
away methods I no longer need.

This has resulted in me no longer writing specs on this part of my
codebase.  They just become obsolete very very fast.  Changing the
specs constantly feels like a pointless doubling of my effort.  Specs
seem to help with debugging and verification that the software is
performing as expected.  But I''m spending most of my time trying to
figure out what I should be expecting.  I verify that things are
working quickly and informally, because it''s likely the definition of
"working" will change before the week is up.

Am I being stupid?  Is it really a pointless doubling, or am I
creating more debugging time for myself than I''m saving without
writing specs?  Should I be more religious about Test First?

Thanks in advance for the insights,
Erik

Testing should answer this question for you, regularly:  How do you
know it works?



Courtenay


On Fri, Feb 19, 2010 at 12:59 AM, Erik Pukinskis
<erikpukinskis at gmail.com> wrote:
> Hello Specmeisters!
>
> I have a bit of a philosophical question for the TDD witches and
> wizards out there. ?I''m working on some code that is really
> churning... It''s doing complicated calculations, but the actual
> desired results are a moving target. The acceptable values, and even
> the structure of the software''s output are changing constantly.
?The
> internal architecture is changing rapidly, and I''m constantly
throwing
> away methods I no longer need.
>
> This has resulted in me no longer writing specs on this part of my
> codebase. ?They just become obsolete very very fast. ?Changing the
> specs constantly feels like a pointless doubling of my effort. ?Specs
> seem to help with debugging and verification that the software is
> performing as expected. ?But I''m spending most of my time trying
to
> figure out what I should be expecting. ?I verify that things are
> working quickly and informally, because it''s likely the definition
of
> "working" will change before the week is up.
>
> Am I being stupid? ?Is it really a pointless doubling, or am I
> creating more debugging time for myself than I''m saving without
> writing specs? ?Should I be more religious about Test First?
>
> Thanks in advance for the insights,
> Erik
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

hi there,
well I''m not a meister myself, but spec-ing something you
don''t know the
outside result is a bit hard for me.

I normally work in two modes:
* hacking mode: that''s when I''m trying to "see" if I
can do something, if
the result will run, getting to know the problem and such. In these mode I
"only" write specs that keep me going further, but those look more
like test
units. This specs or test-units-specs are something I see as tests that
later are a kind of code history  ("residual tests" keeps coming to
the top
of my head) and keep them as long as they don''t start becoming a PITA
and of
course are still valid :-)

after I know my hack will do, and know the problem better I switch to
typical outside in
* bdd developing mode

so the thing is outside in only works if you know the outside. And also try
to spec only the "right" amount. But for  maths calculations I would
for
sure TEST

some thougts, hth
joaquin


2010/2/19 Erik Pukinskis <erikpukinskis at gmail.com>
> Hello Specmeisters!
>
> I have a bit of a philosophical question for the TDD witches and
> wizards out there.  I''m working on some code that is really
> churning... It''s doing complicated calculations, but the actual
> desired results are a moving target. The acceptable values, and even
> the structure of the software''s output are changing constantly. 
The
> internal architecture is changing rapidly, and I''m constantly
throwing
> away methods I no longer need.
>
> This has resulted in me no longer writing specs on this part of my
> codebase.  They just become obsolete very very fast.  Changing the
> specs constantly feels like a pointless doubling of my effort.  Specs
> seem to help with debugging and verification that the software is
> performing as expected.  But I''m spending most of my time trying
to
> figure out what I should be expecting.  I verify that things are
> working quickly and informally, because it''s likely the definition
of
> "working" will change before the week is up.
>
> Am I being stupid?  Is it really a pointless doubling, or am I
> creating more debugging time for myself than I''m saving without
> writing specs?  Should I be more religious about Test First?
>
> Thanks in advance for the insights,
> Erik
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>


-- 
www.least-significant-bit.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/rspec-users/attachments/20100219/21276c80/attachment.html>

On 19 Feb 2010, at 08:59, Erik Pukinskis wrote:
> Hello Specmeisters!
>
> I have a bit of a philosophical question for the TDD witches and
> wizards out there.  I''m working on some code that is really
> churning... It''s doing complicated calculations, but the actual
> desired results are a moving target. The acceptable values, and even
> the structure of the software''s output are changing constantly. 
The
> internal architecture is changing rapidly, and I''m constantly
throwing
> away methods I no longer need.
>
> This has resulted in me no longer writing specs on this part of my
> codebase.  They just become obsolete very very fast.  Changing the
> specs constantly feels like a pointless doubling of my effort.  Specs
> seem to help with debugging and verification that the software is
> performing as expected.  But I''m spending most of my time trying
to
> figure out what I should be expecting.  I verify that things are
> working quickly and informally, because it''s likely the definition
of
> "working" will change before the week is up.
>
> Am I being stupid?  Is it really a pointless doubling, or am I
> creating more debugging time for myself than I''m saving without
> writing specs?  Should I be more religious about Test First?
>
> Thanks in advance for the insights,
> Erik
Here are some rules of thumb I would use:

If requirements are churning, I would try to use high-level acceptance  
tests (e.g. with Cucumber) to firm them up.

If I can''t firm up my requirements, it''s because
we''re still going
though a discovery process - we don''t understand what the problem is,  
let alone the solution - and that means it''s too early to write any  
production code. I would happily write code without tests at this  
point, but I''m going to be loud and clear about the fact that the code
I''m writing is a spike, and will have to be thrown away and re-written
before we go live. This kind of code is much more valuable than you  
think - most of the value is in the learning that goes into your heads  
as you do it, rather than in the cobbled-together, un-tested code you  
write. Writing code like this can be fun, but never be tempted to  
check it in!

Once the requirements start to stabilise (but are still changing) I  
often go through a process where the design is still churning as I try  
to work out how I best want to solve the problem. At this point I  
would rely on those high-level acceptance tests to cover me and only  
write specs for parts of the design as it started to stabilise.

The thing you have to remember is the point of TDD/BDD is to surface  
uncertainly and misunderstanding early. Once you get past the  
discovery stage, having the discipline to write tests first will  
reduce churn, because you ask more questions (and make more decisions)  
before you actually sit down and write code. If you don''t have enough  
information to make those decisions though, don''t be afraid or ashamed
to write a spike, but make sure everyone on your team understands the  
distinction between that and production code.

cheers,
Matt

http://mattwynne.net
+447974 430184

I kind of follow a similar principle here. Many times I will write app  
code because in not sure how to pull of the functionality I''m try to  
do. Once I can confirm that I''m getting the expected results, I take a
mental note of what I did, remove the code, and drive it out again  
with the spec.

I like this method a lot because the repetition helps me to lock in  
the logic. Kinda like how people say you really know a topic if you  
can teach it to someone else. The spec almost because that someone  
else I''m teaching.

So in short, I think you''re safe in your approach, but don''t
leave the
code-first spec-second code in production.

--------------
Frank Lakatos
Catchon Media
frank at catchonmedia.com
http://www.catchonmedia.com

On Feb 19, 2010, at 7:21 AM, Matt Wynne <matt at mattwynne.net> wrote:

On 19 February 2010 08:59, Erik Pukinskis <erikpukinskis at gmail.com>
wrote:
> Hello Specmeisters!
>
> I have a bit of a philosophical question for the TDD witches and
> wizards out there.  I''m working on some code that is really
> churning... It''s doing complicated calculations, but the actual
> desired results are a moving target. The acceptable values, and even
> the structure of the software''s output are changing constantly. 
The
> internal architecture is changing rapidly, and I''m constantly
throwing
> away methods I no longer need.
>
> This has resulted in me no longer writing specs on this part of my
> codebase.  They just become obsolete very very fast.  Changing the
> specs constantly feels like a pointless doubling of my effort.  Specs
> seem to help with debugging and verification that the software is
> performing as expected.  But I''m spending most of my time trying
to
> figure out what I should be expecting.  I verify that things are
> working quickly and informally, because it''s likely the definition
of
> "working" will change before the week is up.
>
> Am I being stupid?  Is it really a pointless doubling, or am I
> creating more debugging time for myself than I''m saving without
> writing specs?  Should I be more religious about Test First?
>
> Thanks in advance for the insights,
> Erik
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>
I think you can consider writing a completely separate spike to explore your
subject, so long as you make absolutely certain that you do not merge it
into production code. To avoid that temptation it really should be seperate.
Speculating a bit however, I think your process for developing this part of
your code maybe very wrong. It sounds like your looking for justification
for hacking - which generally is a bad sign - and that maybe you need to
take a step back and look at different approaches. Maybe instead of focusing
on results you could focus on process e.g. to calculate foo I first need to
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

HTH

Andrew
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/rspec-users/attachments/20100221/a0e3584f/attachment-0001.html>

>
> Date: Sun, 21 Feb 2010 10:37:14 +0000
> From: Andrew Premdas <apremdas at gmail.com>
> To: rspec-users <rspec-users at rubyforge.org>
> Subject: Re: [rspec-users] Do you still Write Tests First on code that
>        is      churning hard?
> Message-ID:
>        <88fd8ddc1002210237m39085abbo6c43a7dc34130463 at
mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> On 19 February 2010 08:59, Erik Pukinskis <erikpukinskis at
gmail.com> wrote:
>
> > Hello Specmeisters!
> >
> > I have a bit of a philosophical question for the TDD witches and
> > wizards out there.  I''m working on some code that is really
> > churning... It''s doing complicated calculations, but the
actual
> > desired results are a moving target. The acceptable values, and even
> > the structure of the software''s output are changing
constantly.  The
> > internal architecture is changing rapidly, and I''m constantly
throwing
> > away methods I no longer need.
> >
> > This has resulted in me no longer writing specs on this part of my
> > codebase.  They just become obsolete very very fast.  Changing the
> > specs constantly feels like a pointless doubling of my effort.  Specs
> > seem to help with debugging and verification that the software is
> > performing as expected.  But I''m spending most of my time
trying to
> > figure out what I should be expecting.  I verify that things are
> > working quickly and informally, because it''s likely the
definition of
> > "working" will change before the week is up.
> >
> > Am I being stupid?  Is it really a pointless doubling, or am I
> > creating more debugging time for myself than I''m saving
without
> > writing specs?  Should I be more religious about Test First?
> >
> > Thanks in advance for the insights,
> > Erik
> > _______________________________________________
> > rspec-users mailing list
> > rspec-users at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-users
> >
>
> I think you can consider writing a completely separate spike to explore
> your
> subject, so long as you make absolutely certain that you do not merge it
> into production code. To avoid that temptation it really should be
> seperate.
> Speculating a bit however, I think your process for developing this part of
> your code maybe very wrong. It sounds like your looking for justification
> for hacking - which generally is a bad sign - and that maybe you need to
> take a step back and look at different approaches. Maybe instead of
> focusing
> on results you could focus on process e.g. to calculate foo I first need to
> 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
>
> HTH
>
> Andrew
>
I''m a bit with Andrew on this.   I think you are not asking the right
question.

In TDD/BDD I view writing the tests/spec as PART of writing the code, so if
you are questioning the value of spending the time to write the specs, and
lamenting that you feel this is wasted effort, I have to ask why are you not
questioning the value of even writing code when the target is changing so
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 is
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 itself
is just a waste of time, much less writing the specs, and you need to spend
your effort elsewhere until what is needed is better known.

OTOH, if this is a situation where you are doing a lot of experimentation
and discovery, and the writing of the code is necessary to figure out
''what
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
code
itself is considered disposable and the likelyhood that it won''t ever
make
it into production ''as is''.  In that case, then there may not
be much value
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
27''
is supposed to take for inputs and produce for outputs.

Kent Beck touches on this in his ''flight of the startup'' blog
post
http://www.threeriversinstitute.org/blog/?p=251  and a followup
''developing
for the flight of the startup''
http://www.threeriversinstitute.org/blog/?p=252  and he makes some good
points about when it pays to be dogmatic about some agile practices such as
TDD, and when it''s better to put some of those practices aside
depending on
what it is that you are trying to deliver to the customer at a particular
point in the project.

If you are currently in the phases Kent describes as Taxi and Takeoff, then
you could very well be right to dispense with a majority of tests and other
practices that are needed for maintainable high quality code. (because
you''re not trying to deliver highly maintainable code.)  OTOH if you
are in
the Climb or Cruise stages, then I''d be greatly concerned that
''what we are
building'' is in such a constant state of flux, and I''d suggest
something has
a smell that''s ungood.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/rspec-users/attachments/20100222/6c8e994b/attachment-0001.html>