Live data from Hacker News

The Sudoku Affair

explaining.software

1–10 of 45 posts

Re: The Sudoku Affair

#2
As someone who wrote 60 pages of design for a new VCS before writing a single line of code, I appreciate this post.

Design is crucial. The optimal time for that design may be different for different things, but I do know that incremental design can, and often does, fail.

Re: The Sudoku Affair

#3

As someone who wrote 60 pages of design for a new VCS before writing a single line of code, I appreciate this post. Design is crucial. The optimal time for that design may be different for different things, but I do know that incremental design can, and often does, fail.

Your method is still incremental design, unless you started at page 1 and stopped at page 60.

Re: The Sudoku Affair

#4
Sadly, link isn't loading for me. I'm assuming this is the attempt to TDD into a Sudoku solver?

Sucks, as it is largely a dunk on the author. It really is a sobering experience, to attempt something like that and use what are advertised as good tools, only to fall flat on your face.

I think what people often fail to appreciate is if you see ANY strategy work, it has almost certainly been rehearsed. Many many times. Even when you are doing something where you are using the exact correct tools, for it to work smoothly pretty much requires rehearsal.

And this is exactly why you do gamedays for how to react to failures. If you have not practiced it, then you should not expect success.

Re: The Sudoku Affair

#5

As someone who wrote 60 pages of design for a new VCS before writing a single line of code, I appreciate this post. Design is crucial. The optimal time for that design may be different for different things, but I do know that incremental design can, and often does, fail.

Your method is still incremental design, unless you started at page 1 and stopped at page 60.

That is, in fact, what I did.

But then again, you know I was referring to Jeffries' SOP of designing while coding and refactoring incrementally.

Re: The Sudoku Affair

#6
Hilarious post. I recommend people read to the end

> If Jeffries started with a different core representation, then it's likely his subsequent design decisions would also change. The bookkeeping for constraint propagation might push him towards Norvig's relational approach to the rules of Sudoku; rather than continually recomputing the rows, columns, and boxes, he could simply have a map of each cell onto its peers. He could distill every lesson of the previous posts, creating something simpler and faster.

> But Jeffries isn't in the business of starting over. He not only believes in incremental design, but in using the smallest possible increments. In his posts, he regularly returns to GeePaw Hill's maxim of "many more much smaller steps." He is only interested in designs that are reachable through a series of small, discrete steps.

Jeffries has radicalized me. This sort of puttering-around with "incremental design" is too pervasive in the corporate world. In software we have the luxury of rethinking from first principles, and we must use it. Death to MMMSS

Re: The Sudoku Affair

#7
It is interesting to basically critique a series of blog posts like its a film.

But re: design vs. increment, I do think incremental TDD is pretty useful in domains where you have low confidence that you could come up with a good design. If you asked me to implement an LLM today, 0% I could design a good one. But given enough time I could slowly start to implement one (maybe?).

The two quotes that got me are

Jeffries:

> So I try to make small decisions, simple decisions, decisions that will be easy to change when, not if, a better idea comes along.

Norvig, about Jeffries:

> He didn't know that so he was sort of blundering in the dark even though all his code "worked" because he had all these test cases.

I fear someone could say this about me, about almost everything I've ever built. I guess something like "I just kept crawling and it just kept working!"

Re: The Sudoku Affair

#9
post #4

Sadly, link isn't loading for me. I'm assuming this is the attempt to TDD into a Sudoku solver? Sucks, as it is largely a dunk on the author. It really is a sobering experience, to attempt something like that and use what are advertised as good tools, only to fall flat on your face. I think what people often fail to appreciate is if you see ANY strategy work, it has almost certainly been rehearsed. Many many times. E…

It's specifically about the limits of incremental design.

TFA's thesis is roughly that incremental design dooms you to a local maximum:

Since Jeffries (the TDD/Sudoku guy you seem to be aware of) starts out with a suboptimal representation for the board, there is no small change that can turn the bad code into good code. At some point along the line, he makes motions in the direction of the design that Norvig used, but as there is no incremental way to get there (maintaining two representations was a dead-end since it hurt performance so much), he never does.

Re: The Sudoku Affair

#10
post #4

Sadly, link isn't loading for me. I'm assuming this is the attempt to TDD into a Sudoku solver? Sucks, as it is largely a dunk on the author. It really is a sobering experience, to attempt something like that and use what are advertised as good tools, only to fall flat on your face. I think what people often fail to appreciate is if you see ANY strategy work, it has almost certainly been rehearsed. Many many times. E…

It's about that, as I too expected from the title, but there's a twist.

The twist is that Jeffries started working on that project again in 2024 and wrote 45 more posts on it. And that's what this article is about.

Post reply on HN