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.
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).
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.