Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Reflections on Sudoku, or the Impossibility of Systematizing Thought

rjp.io

Post reply on HN
Print view View original

11–20 of 67 posts

Re: Reflections on Sudoku, or the Impossibility of Systematizing Thought

#11

Post by aleph_minus_one »

schoen wrote: post #3

Isn't there a less-conceptual (but still conceptual) problem that correctness of software is commonly abrupt rather than continuous? You don't get a series of almost-right programs gradually approximating the right program, you have a correct program and variations on it may fail completely. Of course, whether this is literally true depends on what sort of algorithmic problem you're approaching. But there must be man…

> Isn't there a less-conceptual (but still conceptual) problem that correctness of software is commonly abrupt rather than continuous? You don't get a series of almost-right programs gradually approximating the right program, you have a correct program and variations on it may fail completely.

I consider it to be plausible that such a topology could exist (at least for many situations). The problem rather is that such a topology would likely behave very different from users' expectations.

Re: Reflections on Sudoku, or the Impossibility of Systematizing Thought

#12

Post by aleph_minus_one »

NitpickLawyer wrote: post #6
gnat wrote: post #5

Earlier quoted context omitted.

I think there’s an analogy in the dumb management dream that there’s a process by which you can replace these expensive skilled workers with cheap unskilled idiots and still get great results. Another variation: the magic process that lets you get great results from people who don’t care. Excellence doesn’t come solely from process. The benchmarks of great process with unskilled workers who don’t care is fast food, a…

> there’s a process by which you can replace these expensive skilled workers with cheap unskilled idiots and still get great results. > Another variation: the magic process that lets you get great results from people who don’t care. Isn't that pretty much what the US military does? They take in "dumb" teens + docs + processes and get whatever it is they need out of this? It's also cheap (compared w/ industry). And by…

> The military processes are at the base of lots of organisational stuff we have in software dev and business as well (agile, scrum [...])

The Agile Manifesto was exactly the counter-manifesto to this, and thus any methodology that calls itself agile (e.g. Scrum) is:

Agile Manifesto

> https://agilemanifesto.org/

Principles behind the Agile Manifesto

> https://agilemanifesto.org/principles.html

Re: Reflections on Sudoku, or the Impossibility of Systematizing Thought

#14

Post by omnibrain »

schoen wrote: post #3

Isn't there a less-conceptual (but still conceptual) problem that correctness of software is commonly abrupt rather than continuous? You don't get a series of almost-right programs gradually approximating the right program, you have a correct program and variations on it may fail completely. Of course, whether this is literally true depends on what sort of algorithmic problem you're approaching. But there must be man…

I always use the following analogy:

I f your customer orders a feature, you implement all the code, just the button to call the feature is missing, then you delivered nothing.

If you just add the button to the program, but implement nothing else, you delivered the feature. It's just still buggy.

Re: Reflections on Sudoku, or the Impossibility of Systematizing Thought

#15

Post by JonChesterfield »

This was an interesting read but the source article is fascinating https://explaining.software/archive/the-sudoku-affair/

TDD as an incremental search from a simple start point towards a solutions. Put in those terms, it'll work when the path from start to solution is smoothly differentiable.

Re: Reflections on Sudoku, or the Impossibility of Systematizing Thought

#16

Post by jerf »

aleph_minus_one wrote: post #12
NitpickLawyer wrote: post #6

Earlier quoted context omitted.

> there’s a process by which you can replace these expensive skilled workers with cheap unskilled idiots and still get great results. > Another variation: the magic process that lets you get great results from people who don’t care. Isn't that pretty much what the US military does? They take in "dumb" teens + docs + processes and get whatever it is they need out of this? It's also cheap (compared w/ industry). And by…

> The military processes are at the base of lots of organisational stuff we have in software dev and business as well (agile, scrum [...]) The Agile Manifesto was exactly the counter-manifesto to this, and thus any methodology that calls itself agile (e.g. Scrum) is: Agile Manifesto > https://agilemanifesto.org/ Principles behind the Agile Manifesto > https://agilemanifesto.org/principles.html

"Scrum" isn't really "Agile", though. Maybe someone developed it through a truly Agile process, but then they froze it and held it up as an unchanged ideal and started down the oh-so-appealing road of telling anyone that finds it doesn't work for them that it's because they weren't doing it right.

I find myself having to distinguish between what I call "Real Agile" and Scrum quite a bit, because Scrum is exactly the sort of thing that Real Agile was a reaction against.

I've raided Scrum for ideas in my agile processes, but I would never rigidly do exactly it.

Re: Reflections on Sudoku, or the Impossibility of Systematizing Thought

#17

Post by aleph_minus_one »

jerf wrote: post #16
aleph_minus_one wrote: post #12

Earlier quoted context omitted.

> The military processes are at the base of lots of organisational stuff we have in software dev and business as well (agile, scrum [...]) The Agile Manifesto was exactly the counter-manifesto to this, and thus any methodology that calls itself agile (e.g. Scrum) is: Agile Manifesto > https://agilemanifesto.org/ Principles behind the Agile Manifesto > https://agilemanifesto.org/principles.html

"Scrum" isn't really "Agile", though. Maybe someone developed it through a truly Agile process, but then they froze it and held it up as an unchanged ideal and started down the oh-so-appealing road of telling anyone that finds it doesn't work for them that it's because they weren't doing it right. I find myself having to distinguish between what I call "Real Agile" and Scrum quite a bit, because Scrum is exactly the…

> "Scrum" isn't really "Agile", though.

Wikipedia:

> https://en.wikipedia.org/wiki/Scrum_(software_development)

"Scrum is an agile team collaboration framework commonly used in software development and other industries."

In other words: people who claim to do Scrum, but in a non-agile way are simply scammers.

Re: Reflections on Sudoku, or the Impossibility of Systematizing Thought

#18

Post by bubblyworld »

schoen wrote: post #3

Isn't there a less-conceptual (but still conceptual) problem that correctness of software is commonly abrupt rather than continuous? You don't get a series of almost-right programs gradually approximating the right program, you have a correct program and variations on it may fail completely. Of course, whether this is literally true depends on what sort of algorithmic problem you're approaching. But there must be man…

Obvious counters aside (like syntax issues or whatever) I have almost the opposite intuition. Most of my programs start out as partial solutions to a problem I don't fully understand, and it is only through interaction with the environment (users, or other machines sometimes) that the edge-cases and incorrect assumptions become clear. These programs have a lifecycle of refinement to deployment to analysis to refinement and repeat. At each step they are workable or almost-so, and over time the solutions start to map the domain more correctly. Sometimes (like in business) the domain is evolving simultaneously!

(can give examples if anyone's interested but this is getting long already)

I imagine this wouldn't work so well for hard algorithmic stuff where there are mathematical properties you need to be aware of and maintain. But I find most problems I solve are more organic - people are quite resilient to fuzzy boundaries, so people-facing stuff tends to have that property too. There's a large fuzzy space of "workable solutions", so to speak, and navigating that space is kind of inevitable if you want a quality solution.

Perhaps I'm just not intelligent enough to one-shot that kind of stuff =P

Re: Reflections on Sudoku, or the Impossibility of Systematizing Thought

#19

Post by PaulHoule »

rjpower9000 wrote: post #2

I was fascinated by the "Sudoku Affair", found myself speculating on the internal mindset of TDD advocates, and ended up with an unsatisfying conclusion that you can't systematize thought. Not my best writing but thought I'd share nonetheless.

There's the principle "never let them see you sweat" and if you're trying to convince people of an idea like TDD you never want to be seen floundering. You don't publish anything about your sudoku solver until you've succeeded at it. Otherwise you're just proving "TDD sux" which, for all "X sux", TDD sux more than X.

Re: Reflections on Sudoku, or the Impossibility of Systematizing Thought

#20

Post by SAI_Peregrinus »

jerf wrote: post #16
aleph_minus_one wrote: post #12

Earlier quoted context omitted.

> The military processes are at the base of lots of organisational stuff we have in software dev and business as well (agile, scrum [...]) The Agile Manifesto was exactly the counter-manifesto to this, and thus any methodology that calls itself agile (e.g. Scrum) is: Agile Manifesto > https://agilemanifesto.org/ Principles behind the Agile Manifesto > https://agilemanifesto.org/principles.html

"Scrum" isn't really "Agile", though. Maybe someone developed it through a truly Agile process, but then they froze it and held it up as an unchanged ideal and started down the oh-so-appealing road of telling anyone that finds it doesn't work for them that it's because they weren't doing it right. I find myself having to distinguish between what I call "Real Agile" and Scrum quite a bit, because Scrum is exactly the…

Royce's original "Waterfall" paper[1] is significantly more iterative & agile than Scrum! It's outdated since at the time (1970) programming was done mostly on paper & then run later on a mainframe or special-purpose computer, but many of the core ideas still hold true for modern programming environments.

Of course many of the organizations that claimed to be implementing Waterfall omitted the iterative steps, then wondered why it didn't work. That also happens with "Agile" processes. Sticking to the waterfall analogy, it's like if you stopped the evaporation & precipitation cycle that refills the upstream aquifer & wondered why the waterfall stopped flowing!

[1] https://www.praxisframework.org/files/royce1970.pdf

Post reply on HN