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.
One of the most useful skills I gained from programming competitions is the ability to write and debug an algorithm in my head. And I suspect your 60-page design document was written by essentially doing the same thing: coming up with a prototype design, and mentally testing it against the use cases to figure out if the design is workable, and committing the notes to paper only after you confirmed that it worked in your head.
Good article. For me, this is the fundamental concept:
> Both Norvig and Jeffries are genre programmers; they have spent most of their career solving a specific kind of problem. And that problem, inevitably, lends itself to a particular kind of solution.
I wish more people would be circumspect about the genre of problem they're trying to solve and how their framing railroads them into a particular type of solution that might have a better method.
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…
The way I think of this is that there is no shame in Jeffries not having as good and intuitive grasp of the problem as Norvig. After all, this kind of problem is almost tailor-made for Norvig's skill set. Like many of us who haven't done a lot of work in this space would do, Jeffries spends a lot of time early on just exploring the problem space. He starts with a seemingly intuitive (naive?) data structure and goes from there. So far so good. No shame in any of that. All of us have been in a similar situation. I think that the key moment comes at blog post number 12. As the author of this post describes, this is where Jeffries basically recognizes that his approach needs to radically change and where a lot of people would throw away what they have, it having served the function of helping one understand the problem, and start from scratch with different assumptions, data structures, etc. Jeffries didn't do that, probably because he firmly believes in the TDD dogma and probably because he felt pressured to make this work, since he way publicly working through this. That's where Jeffries goes wrong. He should probably have admitted that in some cases you should just start from scratch instead of tinkering at the edges of something that's clearly suboptimal.
Norvig is a world level genius and he outdid Jefferies because of that. No shame in losing a basketball match to LeBron James.
Leaving Norvig out of it, it seems to me that there is some shame in taking a reasonably straightforward problem like this one, thrashing around with it for months or years without producing an effective solution, and then being unable to see that your methodology wasn't working.
If the account is accurate, this Jeffries guy wasn't getting the ball through the hoop, whether or not LeBron was around.
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.
One of the most useful skills I gained from programming competitions is the ability to write and debug an algorithm in my head. And I suspect your 60-page design document was written by essentially doing the same thing: coming up with a prototype design, and mentally testing it against the use cases to figure out if the design is workable, and committing the notes to paper only after you confirmed that it worked in y…
Interesting. Perhaps that is what I did.
I did do that to design the UX, but for algorithms, I am not so sure. I am really bad at coding competitions, for example.
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…
I do something similar where even for something substantial, I'll start out with "what's the simplest thing that might work".
Of course with past experience, my first 'simple' thought is usually quite practical or sensible. In the same way it's hard to invent an inefficient algorithm that does no useless busywork--we've wired our brains toward good.
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.
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.
Was that for Yore?
Um, yeah. How do you know the name?
I have never mentioned it by name, I think. Only linked to it occasionally.
Edit: Another reason I am surprised is that Yore became its name only a few months ago.
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.
Thanks! Annoyed that the link is still not loading for me. :(
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, b…
Thanks! Annoyed that the link still isn't loading for me.
I'm curious on the thesis. I'm assuming "locked in by tests" increments are the problem? I'm curious why you couldn't treat this like any learning task where you can take efforts that are effectively larger steps to see where they can get you?
I should also note that I am not clear I understand how bad of a representation of the board you could get locked with. I got a working solver years ago with what is almost certainly a poor representation. https://taeric.github.io/Sudoku.html