3 ms·
The usual counterexample to this is the famous Sudoku implementation comparison between Norvig and Jeffries, where Norvig's upfront design seemed to quickly and
by dwohnitmok 5y ago
The usual counterexample to this is the famous Sudoku implementation comparison between Norvig and Jeffries, where Norvig's upfront design seemed to quickly and nicely solve the problem at hand and Jeffries eschewing of design led to blindly iterating into nowhere.
http://ravimohan.blogspot.com/2007/04/learning-from-sudoku-solvers.html http://ravimohan.blogspot.com/2007/04/learning-from-sudoku-s...
(with a previous HN comment outlining it here: https://news.ycombinator.com/item?id=3033446 https://news.ycombinator.com/item?id=3033446)
At this point the class of problems to be solved with software is too diverse and messy to ever be cleanly encapsulated by a single batch of "best practices." It would much more useful to me if every neat, clean set of best practices came with case studies of when it succeeded spectacularly and when it absolutely crashed and burned to gain an intuition of when to apply them and when to ignore them.
- buescher 5y agoThe Jeffries thing could only be better if he had tackled each rule of Sudoku one at a time in two-week sprints, simulating a stakeholder revealing the "implicit spec".