I had a similar experience while trying to devise an algorithm to fill up n spots having n-1 soldiers available in the military. So after losing few hours, not being able to come up with any combination that satisfied all conditions I run to the sergeant, explained the problem and he just erased a spot for 24h, changing spec. Suddenly everything fell in to place.

Alexander the Great did the same thing in order to solve the Gordian Knot[1], he changed the spec by removing the complexity (in one stroke).

I was not in a position to even think about proposing the removal of any spot that had to be guarded at all times. Doing so, might have resulted in someone (including myself) doing double-shifts for a few days. Only he who has the power can do it (e.g. Larry Wall for Perl, Alexander the Great for the Gordian Knot and the sergeant for the military camp).

[1] https://www.wikiwand.com/en/Gordian_Knot

I think you'll like George Pólya's How To Solve It. That's one of the methods he prescribed on solving a difficult problem; by gently removing the most difficult part and look at it again.

Finding a better solution by changing the problem is great, especially as the problem stated is often not the problem faced.

Not doing something, or doing something dramatically simpler, ends up with less code being written. The cost of writing the code is usually a small fraction of the cost of supporting it during over the life span of the system.

One problem I faced was a client that as part of an e-commerce re-implementation brought a huge list of requirements for promotions and how they should work. There was hundreds of use-cases, some being very complicated.

I came back to the client and said, "are you sure you need all of this?" After working with them to investigate, it turned out that they had just documented all the features of their existing system. In the previous ten years, they had created exactly one coupon, and that was for a flat 10% off.

That was the functionality we initially went live with.

This is the difference between a real programmer and a coding monkey.

Coding monkeys consider the spec the problem and try to write code that solves it.

Programmers consider the spec a part of the solution and evolve it as necessary.

Interestingly this is pretty much "valuing individuals, working software, and customer interaction" - the core of the agile manifesto, but the bits that never seem to ever show up in "Agile" workplaces where way too often rigid compliance with standups, scrum meetings, and evenly sloped burndown charts (and foosball table, bean bags, and free energy drinks) are all "critical to the process", and fixed price engagements and hard deadlines are "the business reality"...

"The problem is not the problem, the problem is your attitude towards the problem." - Jack Sparrow

So many times I've seen someone struggle to implement a poorly written spec rather than just say 'hey can we just do X instead?' If X solves the REAL problem then sure you can.

> the problem stated is often not the problem faced.

100% true! So many times I was assigned to the task in issue tracker, where requirements was written, estimation was made, but after I sat and tried to solve given problem, it turned out that 80% of issue description was false - real problem was totally different than it was written in task.

What seemed right on planning meeting, turned out to be quite false in the process.

But quite often managers/product owners etc. don't understand this. They often believe 100% in planning ahead and issue tracker/backlog descriptions... And when something is going off the track (like it sometimes does - when problem needs extra time for thinking through) they aren't so glad because thinking and design process was not budgeted in issue tracker (even if it could lead to the better design on the long run).

Perfect is the enemy of good enough. If you never ship a "perfect" product, it has 0 value.

In the end, you provide value or you don't. The hardest thing about any product development is to stop taking things out or worse yet, keep adding things in. The top performers are usually the ones who can weigh these pros and cons almost immediately and force the product in a better direction.

And good enough is the enemy of at all. Love this little piece of wisdom from Paul Buchheit.

I wish somebody writes a book accumulating such stories. Nothing excites me more than learning from history.

Check "The Art of Unix Programming" by Eric Raymond. It's full of exciting stories from computing pioneers epoch, and more than that, it's just filled with empowering inspiration about simplicity. To quote just one story from this book:

> One epochal example not mentioned in Gabriel's paper is from distributed hypertext systems. Early distributed-hypertext projects such as NLS and Xanadu were severely constrained by the MIT-philosophy assumption that dangling links were an unacceptable breakdown in the user interface; this constrained the systems to either browsing only a controlled, closed set of documents (such as on a single CD-ROM) or implementing various increasingly elaborate replication, caching, and indexing methods in an attempt to prevent documents from randomly disappearing. Tim Berners-Lee cut through this Gordian knot by punting the problem in classic New Jersey style. The simplicity of implementation he bought by allowing “404: Not Found” as a response was what made the World Wide Web lightweight enough to propagate and succeed.

Kobayashi Maru