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

TDD and up-front design

Expand Messages
  • Brandon Olivares
    Hi, I was discussing TDD with someone today who is a little apprehensive about jumping into it. I cited the success I ve had with it on the latest site I ve
    Message 1 of 36 , May 6, 2009
      Hi,

      I was discussing TDD with someone today who is a little apprehensive about
      jumping into it. I cited the success I've had with it on the latest site
      I've been working on.

      But then he mentioned it would probably work on web sites, but not
      necessarily so much on applications that require some more planning. I am
      working on a game, which he cited as an example of something it would
      probably not work so well on.

      I know that excessive up-front design is frowned upon by XP, and I've found
      that mind set to be rather liberating with the projects I have done
      recently. But, what do you do when there is more of a requirement for
      initial planning before you jump into coding? Or, do you think there is no
      such case where that would be necessary?

      Basically, how does the design phase, if any is ever necessary, fit into the
      development process?

      Thanks,
      Brandon

      --
      www.perpetualseeker.com
      Blog about college, programming, and other random things.
      Follow me on Twitter: http://twitter.com/devbanana
    • Brandon Olivares
      ... Lol! I will have to share that analogy with my friend who is questioning TDD. ... So there is still design, but instead of being in one stroke, it s
      Message 36 of 36 , May 7, 2009
        On 2009-05-07, Ilja Preuß wrote:
        >
        >
        > Hi Brandon,
        >
        >> So the process of refactoring can match any advantage gained from a
        >> lot of up-front design?
        >
        > Yes, in the same way that continuous steering can match any advantage
        > gained from a lot of up front trip planning.
        >

        Lol! I will have to share that analogy with my friend who is questioning
        TDD.

        >> I like refactoring, and tend to do a lot of it. I guess the question is
        >> whether there are any corners one can get pinned in that is hard to get
        >> out of through refactoring.
        >
        > And assuming that there are, a related question would be how you are
        > more likely to avoid those corners: by up front attention to design, or
        > by continuous attention to design.
        >

        So there is still design, but instead of being in one stroke, it's
        throughout the entire project?

        >> Of course any refactoring has some pain because of trying to undo what
        >> you've done that needs refactoring. I guess the more frequently it is
        >> done, the less painful it is.
        >
        > And the less frequently it actually feels like "undoing", and more like
        > simply "doing".
        >

        Well, that's true. I couldn't think of a suitable word.

        >> An example he gave me of something that might be hard to get out of is
        >> if you realize your class needs to be a singleton. Now that I think
        >> about that, though, that doesn't seem so hard to change for an
        > existing class.
        >
        > Yes. Much harder is it to undo an existing Singleton. I also can't
        > think of a case where a class needs to be a Singleton, frankly, so I
        > typically avoid them.
        >

        Nor can I. I've never found the need to use them before.

        >> I will do so. The only experience I can speak from is my TDD practice
        >> with web sites, since that's mostly what I do. But this is an entirely
        >> different beast, so it's unchartered territory for me.
        >
        > My very first TDD experience was a game that I programmed as a hobby
        > project with a friend. We already had failed twice using up front
        > approaches, because the design simply became too rigid. With
        > refactoring, we also made mistakes, but at least we knew how to work
        > the design out of corners, instead of having to start from scratch.
        >

        Thank you for the concrete example.

        >>> Websites are "easy", so they could indeed get by with very little
        >>> designing. Consider most Rails sites, where MVC gets rubber-stamped
        >>> in for you. Most don't need refactoring or designing.
        >>>
        >>> The larger the project, the _more_ likely you need to grow the
        >>> design, because the _less_ likely you are to guess at the right
        >>> design before you start!
        >
        > Exactly!
        >
        > Cheers, Ilja
        >
        >
        >



        --
        Brandon
        www.perpetualseeker.com
        Blog about college, programming, and other random things.
        Follow me on Twitter: http://twitter.com/devbanana
      Your message has been successfully submitted and would be delivered to recipients shortly.