What you call the repair step I see as running the greedy algorithm again, from a different node in the search graph.
There's probably some optimal level of fear-of-mistakes for any given project. Monorail made me realize my brain was tuned too far in the fear direction. I stand by that generalization.
This is what I was referring to. Yes, if you tackle coding projects that are challenging mostly by size and not by algorithmic difficulty, simply plowing ahead is the right attitude. But sometimes you will encounter real challenges, and for those you will need all the top-down design and logical tricks that you can muster. To the extent that my personal experience is relevant, for my PhD thesis I've designed and implemented a novel algorithm. I went through three non-functional versions before I realized that I actually needed to spell everything out on paper first, before writing a single line of code. After that, I was done in two weeks.
OP isn't right that this is greedy either. What your users are doing is an iterative search with a backoff strategy. They pursue one path through the search space, and when they don't find the solution, they remove some links (backing off) and try a new path through the search space.
The clever bit is whether you can automate their decision mechanism for how they're proceeding through the space step by step, and what points you can fall back to when something does wrong (and how to recognize when you've gone wrong).
The fact that people can do this by the seat of their pants somewhat shouldn't come as a surprise to people who study cognitive psychology, but certainly might be a surprise to engineers. After all, that's why everyone who's not a social scientist loves Malcolm Gladwell's books.
In my experience (playing Monorail!) the "fast" approach is basically guess, repair, repair, repair, ... If you're trying to keep a mental stack of tentative moves to "undo," as many people do, e.g. when doing a Sudoku, that's a different, more "logical" approach, to me. The fast approach has no state except the current state of the board.
With iterate and repair, people are using an internal heuristic to make a choice and refining that over time. These are not necessarily the locally optimal choice.
Please don't make offensive comments like, "I guess the algorithms course is no longer required at MIT?!"
The very presence of the "internal heuristic" that you mention is usually enough to make the algorithm greedy.
Otherwise, thanks for being nice, and try to take less offense at what people say on the Internet.
That is most likely a wrong assumption. Greedy algorithms usually do not find globally optimal solutions, yet the people solving these problems are finding -the- solution. That is enough to suggest that the heuristic people are using is much more complex than merely choosing local optimums.
No one is wrong or right. It just depends on what you believe users are doing. One thing is certain: users use "local search" techniques as opposed to "systematic" search. The salesman problem describes this: the algorithm operates using a single current node and moves only to neighbors of that node.
However, depending on the "local search" algorithm used, those may be greedy or not: - "Hill Climbing" is greedy. The algorithm is affected by local maxima, ridges and plateaux. - "Simulated annealing" is not greedy. It uses "gradient descent" and does not always pick the "best" neighbors.
I believe the heuristics used by the users: - are not very precise ("Well, it is better, right?") - may change over time ("Oh, look at this!") That's why, I think it is not a "greedy" algorithm with deterministic results, but it is NOT complete anyway (hence, the clear process).
I can't wait for you guys to kick my butt :) ps: I'm a business major...
All you guys are trying to label, taxonimicate the "lay person's" strategy into your hierarchy.
Humans are damn smart, and the cocksure MIT nerd got his ass handed to him.