Sudoku and TDD

Expand Messages
• A friend just sent me the following link: http://devgrind.com/2007/04/25/how-to-not-solve-a-sudoku/ Our very own Ron Jeffries comes in for some criticism.
Message 1 of 22 , Apr 26, 2007
A friend just sent me the following link:

http://devgrind.com/2007/04/25/how-to-not-solve-a-sudoku/

Our very own Ron Jeffries comes in for some criticism. Intelligent

---

April 25, 2007
How to not solve a Sudoku

I found this at Ravi Mohan's One Man Hacking:

Ron Jeffries attempts to create a sudoku solver - here, here,
here, here and here. (You really ought to read these articles. They
are ummm{cough} err. enlightening.)

Peter Norvig creates a Sudoku Solver.

Compare. Learn.

To increase the impact, I suggest you read Norvig's essay first. It's
a great read and the elegance and concision of his solution gave me
this tingly warm feeling of sheer developer entrancement. In contrast,
Jeffries' writings on implementing a Sudoku solver by following a
test-driven development approach, are just disconcerting. In the end,
he abandons his half-finished work after five postings. If he achieves
anything, he impressively demonstrates that he's not exactly an
algorithms expert (which Peter Norvig, of course, is).
• It s clear that the blogger doesn t get that the purpose of the two exercises was entirely different and that they each meet their separate objectives. Charlie
Message 2 of 22 , Apr 26, 2007
It's clear that the blogger doesn't get that the purpose of the two
exercises was entirely different and that they each meet their separate
objectives.

Charlie

> -----Original Message-----
> From: extremeprogramming@yahoogroups.com
> [mailto:extremeprogramming@yahoogroups.com] On Behalf Of
> martijn_meijering
> Sent: Thursday, April 26, 2007 10:54 AM
> To: extremeprogramming@yahoogroups.com
> Subject: [XP] Sudoku and TDD
>
> A friend just sent me the following link:
>
> http://devgrind.com/2007/04/25/how-to-not-solve-a-sudoku/
>
> Our very own Ron Jeffries comes in for some criticism.
>
> ---
>
> April 25, 2007
> How to not solve a Sudoku
>
> I found this at Ravi Mohan's One Man Hacking:
>
> Ron Jeffries attempts to create a sudoku solver - here,
> here, here, here and here. (You really ought to read these
> articles. They are ummm.{cough} .err.. enlightening.)
>
> Peter Norvig creates a Sudoku Solver.
>
> Compare. Learn.
>
> To increase the impact, I suggest you read Norvig's essay
> first. It's a great read and the elegance and concision of
> his solution gave me this tingly warm feeling of sheer
> developer entrancement. In contrast, Jeffries' writings on
> implementing a Sudoku solver by following a test-driven
> development approach, are just disconcerting. In the end, he
> abandons his half-finished work after five postings. If he
> achieves anything, he impressively demonstrates that he's not
> exactly an algorithms expert (which Peter Norvig, of course, is).
>
>
>
> To Post a message, send it to: extremeprogramming@...
>
> To Unsubscribe, send a blank message to:
> extremeprogramming-unsubscribe@...
>
>
>
>
>
• A solver that doesn t waste a lot of bytes in explanation: http://www.jsoftware.com/jwiki/Essays/Sudoku
Message 3 of 22 , Apr 26, 2007
A solver that doesn't waste a lot of bytes in explanation:

http://www.jsoftware.com/jwiki/Essays/Sudoku

martijn_meijering wrote:
>
> A friend just sent me the following link:
>
> http://devgrind.com/2007/04/25/how-to-not-solve-a-sudoku/
> <http://devgrind.com/2007/04/25/how-to-not-solve-a-sudoku/>
>
> Our very own Ron Jeffries comes in for some criticism. Intelligent
>
> ---
>
> April 25, 2007
> How to not solve a Sudoku
>
> I found this at Ravi Mohan's One Man Hacking:
>
> Ron Jeffries attempts to create a sudoku solver - here, here,
> here, here and here. (You really ought to read these articles. They
> are ummm…{cough} …err…. enlightening.)
>
> Peter Norvig creates a Sudoku Solver.
>
> Compare. Learn.
>
> To increase the impact, I suggest you read Norvig's essay first. It's
> a great read and the elegance and concision of his solution gave me
> this tingly warm feeling of sheer developer entrancement. In contrast,
> Jeffries' writings on implementing a Sudoku solver by following a
> test-driven development approach, are just disconcerting. In the end,
> he abandons his half-finished work after five postings. If he achieves
> anything, he impressively demonstrates that he's not exactly an
> algorithms expert (which Peter Norvig, of course, is).
>
>
• Hello, ramacd. On Thursday, April 26, 2007, at 2:07:02 PM, you ... It s kind of a question of what one is trying to do. I m trying to let people have a
Message 4 of 22 , Apr 26, 2007
Hello, ramacd. On Thursday, April 26, 2007, at 2:07:02 PM, you
wrote:

> A solver that doesn't waste a lot of bytes in explanation:

> http://www.jsoftware.com/jwiki/Essays/Sudoku

It's kind of a question of what one is trying to do. I'm trying to
let people have a glimpse of how I use code to figure things out.

Ron Jeffries
www.XProgramming.com
Find the simple path to what works and follow it,
always looking for a simpler path. -- Patrick D. Smith
• ... Further, the comparison is entirely useless. What the others are doing is demonstrating known solutions to known problems. What Ron is doing is
Message 5 of 22 , Apr 26, 2007
On 4/26/07, Ron Jeffries <ronjeffries@...> wrote:
>
>
>
>
>
>
> Hello, ramacd. On Thursday, April 26, 2007, at 2:07:02 PM, you
> wrote:
>
> > A solver that doesn't waste a lot of bytes in explanation:
>
> > http://www.jsoftware.com/jwiki/Essays/Sudoku
>
> It's kind of a question of what one is trying to do. I'm trying to
> let people have a glimpse of how I use code to figure things out.
>
>

Further, the comparison is entirely useless. What the others are doing
is demonstrating known solutions to known problems. What Ron is doing
is demonstrating a process to elucidate a working solution to a poorly
understood problem. The former is almost entirely irrelevant to
• ... A math professor friend of mind once complained about a particularly tidy mathematical genius (I think it was Gauss, but it s been a decade) who ended up
Message 6 of 22 , Apr 26, 2007
Ron Jeffries wrote:
>
> It's kind of a question of what one is trying to do. I'm trying to
> let people have a glimpse of how I use code to figure things out.
>

A math professor friend of mind once complained about a particularly
tidy mathematical genius (I think it was Gauss, but it's been a decade)
who ended up substantially changing the way results were published.
Before his time, published proofs tended to be longer and more
meandering, as the reflected not just the result, but how the result was
arrived at. This fellow (let's presume it was Gauss) relentlessly
polished before publication, getting down to the bare minimum, the most
brilliant proofs.

It was apparently much more impressive to read, and everybody started
following Gauss's approach. Although this permanently raised the bar,
which is in some sense a good thing, it removed a lot of the clues that
students and mere mortals used to see how good math was really done. My
friend compared it to climbing up and pulling the ladder up after you.

Like my friend, I think both styles have their place. But your narrative
approach seems to fit much better with the agile values we're promoting,
unreproduceable brilliance.

William
• ... The point made in the post (this is in the comments of the original post) is that the algorithm will not emerge using TDD. You need to know the algorithm
Message 7 of 22 , Apr 26, 2007
> Further, the comparison is entirely useless. What the others are doing
> is demonstrating known solutions to known problems. What Ron is doing
> is demonstrating a process to elucidate a working solution to a poorly
> understood problem. The former is almost entirely irrelevant to
>

The point made in the post (this is in the comments of the original
post) is that the algorithm will not 'emerge' using TDD. You need to
know the algorithm beforehand and then you can implement it (using TDD
if need be). There is no point writing tests and refactoring in the
hope that the algorithm will reveal itself. Its valuable to completely
figure out an algorithm on paper before starting to code.

--
Siddharta Govindaraj
• ... Which is a valid point, but so is mine. I have been writing business software for quite a while now and I can count the number of times I ve had to design
Message 8 of 22 , Apr 26, 2007
On 4/26/07, Siddharta Govindaraj <govind@...> wrote:
>
>
>
>
>
>
> > Further, the comparison is entirely useless. What the others are doing
> > is demonstrating known solutions to known problems. What Ron is doing
> > is demonstrating a process to elucidate a working solution to a poorly
> > understood problem. The former is almost entirely irrelevant to
> >
>
> The point made in the post (this is in the comments of the original
> post) is that the algorithm will not 'emerge' using TDD. You need to
> know the algorithm beforehand and then you can implement it (using TDD
> if need be). There is no point writing tests and refactoring in the
> hope that the algorithm will reveal itself. Its valuable to completely
> figure out an algorithm on paper before starting to code.
>
> --
> Siddharta Govindaraj
>

Which is a valid point, but so is mine. I have been writing business
software for quite a while now and I can count the number of times
I've had to design an algorithm. A few times I had to look one up.
Most often I just call a library that implements it for me. The hard
part in business software isn't coding algorithms. It is understanding
what problem you need the computer to solve and why.

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.

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.
• Hi Siddharta, ... That s a pretty well-known characteristic of TDD, often discussed here and on the TDD list. So if the author of the comment thought he was
Message 9 of 22 , Apr 26, 2007
Hi Siddharta,

> > Further, the comparison is entirely useless. What the
> others are doing
> > is demonstrating known solutions to known problems. What
> Ron is doing
> > is demonstrating a process to elucidate a working solution
> to a poorly
> > understood problem. The former is almost entirely irrelevant to
> >
>
> The point made in the post (this is in the comments of the original
> post) is that the algorithm will not 'emerge' using TDD. You
> need to know the algorithm beforehand and then you can
> implement it (using TDD if need be). There is no point
> writing tests and refactoring in the hope that the algorithm
> will reveal itself. Its valuable to completely figure out an
> algorithm on paper before starting to code.

That's a pretty well-known characteristic of TDD, often discussed
here and on the TDD list. So if the author of the comment thought
he was making a point that contradicts the notions of TDD, he was
wrong.

That said, some people think better while coding, others while
making marks on a yellow pad.

Charlie
• ... Hmmmm... I don t know how you figure out algorithms, but for me there s a lot of tinkering with the problem until I understand what s really going on. It s
Message 10 of 22 , Apr 26, 2007
Siddharta Govindaraj wrote:
> The point made in the post (this is in the comments of the original
> post) is that the algorithm will not 'emerge' using TDD. You need to
> know the algorithm beforehand and then you can implement it (using TDD
> if need be). There is no point writing tests and refactoring in the
> hope that the algorithm will reveal itself. Its valuable to completely
> figure out an algorithm on paper before starting to code.
>

Hmmmm... I don't know how you figure out algorithms, but for me there's
a lot of tinkering with the problem until I understand what's really
going on. It's getting down and dirty with the nature of the problem
that gives me the raw material to find the solution.

Sometimes I do that with scratch paper. Sometimes I do it by pushing
coins around on a table. Sometimes it's with scratch code. And
sometimes, yes, I do it with TDD.

There may be no point for you to use TDD, but it seems a little sweeping
to say that there's no point for anybody to use a method, doesn't it

William
• Hello, Siddharta. On Friday, April 27, 2007, at 12:31:03 AM, you ... That s one way ... and certainly I think one has to know what to do before one does it,
Message 11 of 22 , Apr 27, 2007
Hello, Siddharta. On Friday, April 27, 2007, at 12:31:03 AM, you
wrote:

>> Further, the comparison is entirely useless. What the others are doing
>> is demonstrating known solutions to known problems. What Ron is doing
>> is demonstrating a process to elucidate a working solution to a poorly
>> understood problem. The former is almost entirely irrelevant to

> The point made in the post (this is in the comments of the original
> post) is that the algorithm will not 'emerge' using TDD. You need to
> know the algorithm beforehand and then you can implement it (using TDD
> if need be). There is no point writing tests and refactoring in the
> hope that the algorithm will reveal itself. Its valuable to completely
> figure out an algorithm on paper before starting to code.

That's one way ... and certainly I think one has to know what to do
before one does it, in every case, to some degree.

On the other hand, what we have in the code so far is a modular
structure with multiple strategies, which will, I think, be
extendable as other strategies are discovered or invented. There are
sometimes known and concrete strategies for solving problems, but
more commonly not. The world doesn't seem to be made up of math and
sudoku.

Ron Jeffries
www.XProgramming.com
We cannot solve our problems with the same thinking we used when we created them.
-- Albert Einstein
• ... Ron Jeffries www.XProgramming.com Fatalism is born of the fear of failure, for we all believe that we carry success in our own hands, and we suspect that
Message 12 of 22 , Apr 27, 2007
Hello, Adam. +1! On Friday, April 27, 2007, at 1:18:05 AM, you wrote:

> Which is a valid point, but so is mine. I have been writing business
> software for quite a while now and I can count the number of times
> I've had to design an algorithm. A few times I had to look one up.
> Most often I just call a library that implements it for me. The hard
> part in business software isn't coding algorithms. It is understanding
> what problem you need the computer to solve and why.

> 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.

> 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.

Ron Jeffries
www.XProgramming.com
Fatalism is born of the fear of failure, for we all believe that we carry
success in our own hands, and we suspect that our hands are weak. -- Conrad
• ... Exactly. Different situations need different approaches. In this case, the problem was a sudoku solver. I don t think the original blog post meant to say
Message 13 of 22 , Apr 27, 2007
> 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

Exactly. Different situations need different approaches. In this case,
the problem was a sudoku solver. I don't think the original blog post
meant to say that TDD is bad, but that TDD is not always the answer.
There are situations where it works, and situations where it doesnt.

On a side note: Isn't there a subthread here that !TDD==Hacking?
That's the kind of dangerous generalisation that gives agile a bad
name. Every practice has a context around it.

--
Siddharta Govindaraj
• ... On a not altogether unrelated note, Uncle Bob did an interesting spot on TDD ing an algorithm. Most people wouldn t think of TDD ing algorithms, but his
Message 14 of 22 , Apr 27, 2007
On 27/04/07, Siddharta Govindaraj <govind@...> wrote:
> Exactly. Different situations need different approaches. In this case,
> the problem was a sudoku solver. I don't think the original blog post
> meant to say that TDD is bad, but that TDD is not always the answer.
> There are situations where it works, and situations where it doesnt.

On a not altogether unrelated note, Uncle Bob did an interesting spot
on TDD'ing an algorithm. Most people wouldn't think of TDD'ing
algorithms, but his results are interesting.

http://butunclebob.com/ArticleS.UncleBob.ThePrimeFactorsKata

--
Regards,

Tim Haughton
• Colour me confused: Is Sudoku a known problem or a poorly understood one? Just like the Bowling Game, where Ron took a 3 line J solution and turned it into a
Message 15 of 22 , Apr 27, 2007
Colour me confused:

Is Sudoku a known problem or a poorly understood one?

Just like the Bowling Game, where Ron took a 3 line J solution and
turned it into a page of Ruby, I saw a simple problem being made overly
complex. Now I'm not in the "why walk when you can drive" camp that
results in gasoline being wasted on a lot of 2 minute trips, I'm in the
"why go miles out of your way to ford the stream, when the bridge is
right here?" one.

Maybe using APL/J has made me leery of solutions where the code is near
in size to the tests. I'm used to a ratio of 10:1 or higher. After all,
in my experience, 90% of a problem is stating it.

>
> On 4/26/07, Ron Jeffries <ronjeffries@...
> <mailto:ronjeffries%40xprogramming.com>> wrote:
> >
> >
> >
> >
> >
> >
> > Hello, ramacd. On Thursday, April 26, 2007, at 2:07:02 PM, you
> > wrote:
> >
> > > A solver that doesn't waste a lot of bytes in explanation:
> >
> > > http://www.jsoftware.com/jwiki/Essays/Sudoku
> <http://www.jsoftware.com/jwiki/Essays/Sudoku>
> >
> > It's kind of a question of what one is trying to do. I'm trying to
> > let people have a glimpse of how I use code to figure things out.
> >
> >
>
> Further, the comparison is entirely useless. What the others are doing
> is demonstrating known solutions to known problems. What Ron is doing
> is demonstrating a process to elucidate a working solution to a poorly
> understood problem. The former is almost entirely irrelevant to
>
>
• A question: How do we know Gauss needed a ladder? It was Gauss after all. (another one: how does one get rid of irrelevant parts of the quoted text. It seems
Message 16 of 22 , Apr 27, 2007
A question:

How do we know Gauss needed a ladder? It was Gauss after all.

(another one: how does one get rid of irrelevant parts of the quoted
text. It seems like theres an HTML spiderweb surrounding all the post.)

William Pietri wrote:
>
> Ron Jeffries wrote:
> >
> > It's kind of a question of what one is trying to do. I'm trying to
> > let people have a glimpse of how I use code to figure things out.
> >
>
> A math professor friend of mind once complained about a particularly
> tidy mathematical genius (I think it was Gauss, but it's been a decade)
> who ended up substantially changing the way results were published.
> Before his time, published proofs tended to be longer and more
> meandering, as the reflected not just the result, but how the result was
> arrived at. This fellow (let's presume it was Gauss) relentlessly
> polished before publication, getting down to the bare minimum, the most
> brilliant proofs.
>
> It was apparently much more impressive to read, and everybody started
> following Gauss's approach. Although this permanently raised the bar,
> which is in some sense a good thing, it removed a lot of the clues that
> students and mere mortals used to see how good math was really done. My
> friend compared it to climbing up and pulling the ladder up after you.
>
> Like my friend, I think both styles have their place. But your narrative
> approach seems to fit much better with the agile values we're promoting,
> unreproduceable brilliance.
>
> William
>
>
• ... Dear Rubyjin, Thank you for your work on the sudoku solver. I am now using this to check the sudokus I am crafting for the newspaper. Yesterday I found
Message 17 of 22 , Apr 27, 2007
ramacd wrote on 27/04/2007 16:05:37:

> Just like the Bowling Game, where Ron took a 3 line J solution and
> turned it into a page of Ruby, I saw a simple problem being made overly
> complex.

Dear Rubyjin,

Thank you for your work on the sudoku solver. I am now using this to check
the sudokus I am crafting for the newspaper.

Yesterday I found that the solver came up with a different solution to
mine. After some more careful manual checking, I found that there were in
fact two solutions. It would have been very bad if I had submitted this to
the paper!

Please could you change your solver so that it tells me if a sudoku has
more than one solution?

Thanks,
Sudokujin.

PS: People are not simple problems.
PPS: All problems for which people want solutions are people problems.
PPPS: Deploy it to production. It's the only way to be sure.

--
Elizabeth Keogh
liz@...
http://sirenian.livejournal.com
http://jbehave.org

[Non-text portions of this message have been removed]
• Hello, ramacd. On Friday, April 27, 2007, at 11:05:37 AM, you ... I d love to see a simpler Ruby version that follows the J style. Ron Jeffries
Message 18 of 22 , Apr 27, 2007
Hello, ramacd. On Friday, April 27, 2007, at 11:05:37 AM, you
wrote:

> Just like the Bowling Game, where Ron took a 3 line J solution and
> turned it into a page of Ruby, I saw a simple problem being made overly
> complex. Now I'm not in the "why walk when you can drive" camp that
> results in gasoline being wasted on a lot of 2 minute trips, I'm in the
> "why go miles out of your way to ford the stream, when the bridge is
> right here?" one.

I'd love to see a simpler Ruby version that follows the J style.

Ron Jeffries
www.XProgramming.com
Anyone can make the simple complicated.
Creativity is making the complicated simple. -- Charles Mingus
• ... When teaching almost any discipline, it is common to take simple, understandable problems and show their solutions using techniques that have broader real
Message 19 of 22 , Apr 27, 2007
On 4/27/07, ramacd <ramacd@...> wrote:
>
>
>
>
>
>
> Colour me confused:
>
> Is Sudoku a known problem or a poorly understood one?
>
> Just like the Bowling Game, where Ron took a 3 line J solution and
> turned it into a page of Ruby, I saw a simple problem being made overly
> complex. Now I'm not in the "why walk when you can drive" camp that
> results in gasoline being wasted on a lot of 2 minute trips, I'm in the
> "why go miles out of your way to ford the stream, when the bridge is
> right here?" one.
>
> Maybe using APL/J has made me leery of solutions where the code is near
> in size to the tests. I'm used to a ratio of 10:1 or higher. After all,
> in my experience, 90% of a problem is stating it.
>
>

When teaching almost any discipline, it is common to take simple,
understandable problems and show their solutions using techniques that
have broader real world applications. The bowling game and sudoku were
both chosen for the same reasons. Those reasons are: that they are
simple enough for anyone to grasp, but complex enough to demonstrate
the technique and possibly lead in some interesting directions.

An exploratory solution to sudoku is no more or less practical than
your typical "Hello, World" example. It serves the same purpose. It
shows what the technique can do without getting overly bogged down in
complex domain issues. If you wanted to type "Hello, World" what type
of VM would you need? Most people would just use MS Word, but how
often does it come up?
• ... Or, better, fixes it so that it doesn t have more than one solution. ... Bill Tozier AIM: vaguery@mac.com; Skype: vaguery; Twitter: Vaguery
Message 20 of 22 , Apr 27, 2007
On Apr 27, 2007, at 12:21 PM, Elizabeth Keogh wrote:

> Please could you change your solver so that it tells me if a sudoku
> has
> more than one solution?
Or, better, fixes it so that it doesn't have more than one solution.
-----
Bill Tozier
AIM: vaguery@...; Skype: vaguery; Twitter: Vaguery
thttp://williamtozier.com/slurry

"People who write obscurely are either unskilled in writing or up to
mischief."
-- Sir Peter Medawar
• ... 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?
Message 21 of 22 , Apr 27, 2007
> On 4/26/07, Siddharta Govindaraj <govind@...> wrote:
> Which is a valid point, but so is mine. I have been writing business
> software for quite a while now and I can count the number of times
> I've had to design an algorithm. A few times I had to look one up.
> Most often I just call a library that implements it for me. The hard
> part in business software isn't coding algorithms. It is understanding
> what problem you need the computer to solve and why.

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 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
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?

> 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.

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.

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.

-Kelly
• 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 22 of 22 , May 1, 2007
Hello, Kelly. On Friday, April 27, 2007, at 11:42:35 PM, you
wrote:

> 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
> 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
www.XProgramming.com
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.