Do the simplest thing that could possibly work

I get it.

YAGANI.

A term coined by consultants who don’t understand an industry who basically say “do the least possible thing that will work” because they don’t understand the domain and don’t understand what requirements are often non-negotiable table stakes of complexity you need to compete.

It reminded me of a Martin Fowler post where he was showing implementation of discounts in some system and advocating to just hard code the first discount in the method (literally getDiscount() {return 0.5}).

Even the most shallow analysis would show this was incredibly stupid and short sighted.

But this was the state of the art, or so we were told.

See also Ward Cunningham trying and failing to solve Sudoku using TDD.

The reality is most business domains are actually complex, and the one who best tackles that complexity up front can take home all the marbles.

Undoubtedly, Fowler suggested this as an incomplete step in the development process, essentially to get the code to compile.

Incredible that we can tar both complexity and simplicity with the brush of "consultant BS."

A better explanation of this is on my blog todo list, but:

> Even the most shallow analysis would show this was incredibly stupid and short sighted.

Why? Yes, there's a high probability that this single line of code is ultimately wrong. But having it allows for testing the system (to ensure that getDiscount gets called, that the resulting price is between zero and the undiscounted price, etc.) and it can trivially be replaced when the actual discounting logic becomes known. Nothing can reasonably be called "short sighted" that doesn't actually limit you in the future.

> See also Ward Cunningham trying and failing to solve Sudoku using TDD.

It was Ron Jeffries who was struggling with Sudoku, not Ward Cunningham.

And he didn't struggle because of "doing simple things", but because he didn't actually know how to solve Sudoku, and rather than doing research (or trying a few by hand and reflecting on his own thought process) he expected to gain special insight into the solver by modeling the problem more accurately.

If he had actually known, then he would have just applied the same techniques to modeling the solver, and avoided all the embarrassment.

TDD is orthogonal to "doing the simplest thing", just preached by many of the same people. The problem isn't with writing tests for early iterations of the project that aren't anywhere near fully functional. The problem is that the making the tests pass doesn't actually teach you anything about what the next step of functionality is. You still have to actually think, and Jeffries didn't have a proper basis to ground his thinking.

Norvig's approach to the problem involved some clever hacks that aren't necessarily the best thing from a code maintainability standpoint. But he resisted the temptation to create a prematurely generalized system for solving constraint-propagation problems, trying to create some generic abstract representation of a "constraint" etc. In essence, that code didn't diverge from what the XP gurus preached; it just didn't follow their specific methods ("OO" modeling that's heavily based on creating new classes, TDD etc.).

I independently came to the same conclusions about how to solve the problem, however many years ago. Recently, I was reminded of the story (I think via https://news.ycombinator.com/item?id=42953168) and tried writing a solver from scratch as an exercise. My code was certainly not as "clever" as Norvig's, but only a bit longer and IMO much better factored.