Loading ...
Sorry, an error occurred while loading the content.

What is a spike? (was Re: [XP] What objections have you heard to doing a spike?)

Expand Messages
  • Adrian Howard
    Hi Ron, ... Yeah... that s sort of how I feel. The question is do you draw the line between: A) throwing a couple of lines of code away when your tests point
    Message 1 of 36 , Oct 2, 2007
    • 0 Attachment
      Hi Ron,

      On 1 Oct 2007, at 14:55, Ron Jeffries wrote:

      > Hello, Adrian. On Monday, October 1, 2007, at 8:05:26 AM, you
      > wrote:
      >
      >>> Interesting. I would call them spikes.
      >
      >> Would you ask the customer before starting them?
      >
      > Sometimes yes, sometimes no. Depends on how long they were, or
      > whether a customer decision might differ depending on the answer.
      >
      > My guess is that the truly skilled person, if we could find one,
      > does spikes all the time and almost never has to ask permission.

      Yeah... that's sort of how I feel. The question is do you draw the
      line between:
      A) throwing a couple of lines of code away when your tests point you
      in a new direction during TDD
      B) throwing a days work away when the new UI library your playing
      with turns out not to solve the problem you hoped it would

      I would never call (A) a spike. I would definitely call (B) a spike.
      The stuff in the middle - not so sure... which is where my "need to
      ask the customer" line came from. I could have sworn that this was in
      the book definition of spike too - but I was, as is often the case,
      making things up :-)

      >> That's what I've internalised as the difference between a spike and
      >> normal development - its something that's potentially not of direct
      >> business value to the Customer, and is going to take enough time for
      >> the Customer to care about when prioritising work.
      >
      > Yes. But tell us some specific kinds of things that are like that,

      Hopefully answered by the examples at the end :-)

      > if you like, and we can kick them around. I see at least these
      > possibilities:
      >
      > I can see two ways of doing this and they won't make much difference
      > to the duration of the story.
      >
      > In this case, I'd just fold the experimentation into the story's
      > estimate. OTOH, I'm pretty good at spiking for an hour, not a
      > week. But even if I needed a week, I still need to decide, which
      > means I still need the information.

      That's what I do - and I don't call this a spike (maybe I should).

      > I can see two ways of doing this and if the first one doesn't work,
      > the estimate for the story will be much higher.
      >
      > In this case, there is business value, namely information as to
      > the size of the story. I'd propose the experiment to the customer
      > as a way to get the estimate.
      >
      > OTOH, we could give the higher estimate, do the spike as part of
      > the story, and if it came out on the good side, finish the story
      > early. There's some question in my mind whether that is fully
      > honest, and we might want to discuss it.

      Yup. That's what I'd call a spike.

      > I thought I'd have more kinds of spike but at this moment everything
      > I can think of is one of the above two. How odd ...

      I think my number three would be

      I can see a/some ways of solving this particular problem, but I'm not
      sure if any of them will actually work. The best way to find out is
      by trying it out. We might have to redefine the problem if it doesn't
      pan out.

      >>> And I'm wondering what these
      >>> big things are that you are doing. Sounds like they are so large you
      >>> "fear" to waste the code. Makes me wonder if they are too large in
      >>> some way. We could explore some of them if you like ...
      >
      >> Possibly. I may be biased of course but it doesn't feel like fear.
      >> Two examples of what I'd call spikes:
      >
      > Some people don't like to say "fear". :)

      It frightens me :)

      >> * Is a web-based API going to be fast enough to deal with the number
      >> of logging requests we're expecting, or are we going to have to give
      >> the client boxes direct access to the database we're logging to?
      >> Having a web API gives us these advantages, but its useless if it
      >> can't cope on the hardware resources we currently have [we spiked
      >> code for both options at the same time, binned the DB code and kept
      >> the web API when it proved capable]
      >
      > Yes. Presumably we'd prefer the Web API. We "fear" that it won't be
      > fast enough. In this case, I might well just implement the Web one
      > and wait and see. Depends on how different I expect the two
      > solutions to be, namely can I plug the faster but more complex one
      > in underneath?

      We weren't really sure (the faster/complex one would have involved
      some changing of networking/firewall policy that would have been non-
      trivial to implement). That's why we decided to explore both options
      at the same time. It was a case of figuring out which set of problems
      were more surmountable.

      >> * Is having inline error messages that appear as the user types in
      >> values going to decrease the amount of time spent dealing with user
      >> errors [we tried it, turned out it didn't, but we kept the code
      >> anyway because people liked this method of error reporting better]
      >
      > Sounds like a customer request to me.

      Kind of. The customer request was "make the incidence of this kind of
      error go down". We didn't know for certain what will help - but we
      had some theories. We spiked one. Turns out our theory was wrong, but
      we kept the code anyway because it had some other benefits that we
      hadn't anticipated.

      (We actually fixed the problem later by completely killing that
      particular part of the UI and doing it in much simpler way. The spike
      code lived on in other places because it have value in another way)

      Adrian
    • Adrian Howard
      On 3 Oct 2007, at 15:07, Ron Jeffries wrote: [snip] ... [snip] I m pretty sure your definition is more globally accepted than mine. I would imagine that I ve
      Message 36 of 36 , Oct 3, 2007
      • 0 Attachment
        On 3 Oct 2007, at 15:07, Ron Jeffries wrote:
        [snip]
        > I was taught by the inventor of the term, whom I may of course have
        > misunderstood entirely, that a spike was an experiment where one
        > quickly blasts through all the levels of some problem, so as better
        > to understand it and its solution.
        >
        > As such, I pull the notion out whenever I see alternatives (or no
        > alternative) and need better understanding.
        >
        > I would try never to do a spike that took a whole day, because I've
        > found that I can usually learn what I need to know in far less time
        > than that. If a spike takes ten minutes, I think that's just fine.
        [snip]

        I'm pretty sure your definition is more globally accepted than mine.
        I would imagine that I've moved from the book definition to mine over
        the years. Silly me.

        Now I think of it - my experimental stories should just be called...
        stories. That's how we treat them after all.

        Adrian (feeling especially dim this week :)
      Your message has been successfully submitted and would be delivered to recipients shortly.