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

Re: [XP] Sudoku and TDD

Expand Messages
  • Ron Jeffries
    Hello, Kelly. On Friday, April 27, 2007, at 11:42:35 PM, you ... I wouldn t say that TDD is optimized for anything, though it might be optimal or better
    Message 1 of 22 , May 1, 2007
      Hello, Kelly. On Friday, April 27, 2007, at 11:42:35 PM, you

      > This is clearly the case. So is XP/TDD explicitly designed to solve
      > the problems of the business programmer? Or, is it equally applicable
      > in all domains? My suspicion is that it's optimized for business
      > programming, and while it would be effective at scientific
      > programming, there might be other methods for doing that which would
      > be just about as good in some cases.

      I wouldn't say that TDD is "optimized" for anything, though it might
      be "optimal" or "better" for one thing or another. As is any
      technique, I imagine.

      > I personally found the posted code to be hard to read, even though it
      > was compact and fast. I suspect it would be rather difficult to
      > maintain. Ron's solution was rather verbose, and had the disadvantage
      > of never being finished... which was really it's biggest failing from
      > an XP perspective IMHO. Aren't we supposed to try and get something
      > simple and limited working, and then improve it?

      It does go thru a few versions, but not as many as I had
      contemplated. I might go back to it, but I think as it stands it
      does show the main things I had in mind, namely how to use code to
      think about algorithms. It's probable, given the blog stuff we've
      read, that I didn't bring out that point well enough, at least for
      some readers, though folks here seemed to get it.

      >> If someone paid me to write a sudoka solver I might have a different
      >> outlook. Instead, they pay me to help them to make their lives easier
      >> and run their business. Often they have only vague ideas about how I
      >> am going to do that, but the ideas evolve over time.

      > And Ron's ideas about the original Soduku puzzle were also vague. At
      > the time, I ribbed Ron a bit trying to get him to do the simplest
      > thing that could possibly work (a mildly pruned recursive search) but
      > I don't think I got through because he was after something different
      > than I was.

      Yes. It would have been easy enough to do a full-on search. That
      wasn't my purpose: my purpose was to solve it knowing only what a
      human would, not someone with math and computer science degrees.

      To me that's what makes it fun.

      > If I were to approach this problem, I would use TDD for sure. I would
      > program up the slowest Suduku solver in the world that worked, and
      > then I would use TDD with fanatic relentless refactoring to optimize
      > for both speed, maintainability and readability.

      Yes ... where I wanted a strategic one that used human strategies.

      > I would rather use Ron's code base to create a Sudoku puzzle creator.
      > And that's one next logical step.

      >> Because this is the nature of business software, it is often more
      >> valuable to come up with a naive, working solution quickly so that its
      >> usefulness can be evaluated than to spend time designing a superior
      >> but ultimately no more useful solution.

      > Clearly.

      Seems so to me ...

      Ron Jeffries
      You don't want to sell me waterfall.
      You want to go home and rethink your life.
    Your message has been successfully submitted and would be delivered to recipients shortly.