You have to fix this. It's shit. The whole thing is broken for the user, the database. The accounts team hate it. You've got to fix it.And you, being the obliging worker crack on with fixing the thing. You work through everything you know to get the thing working but can't seem to get it working at all.
How can this happen? How can you be fixing something for so long without actually fixing the thing? You change all the stuff you think controls it, walk through your tests and they still all fail.
Maybe it's impossible. It feels impossible. It feels eternal at 3am when you worrying about being awake enough for the demo to your boss in the morning.
When you've exhausted all your known control of the system, it's time to prove that this can't be fixed.
This is also an excellent way of proving that it can't be. If you can't prove that it can't solved, it must be solvable. Assuming you have all the information to hand, simply proving the unprovability of the problem can either save you time or in trying and failing to prove the unprovability of the problem you show yourself one thing: you need to try harder.
This is like the devil's advocate on steroids. You attack the entire problem from all angles, based on all information and prove that given all the constraints and facts you have, it is simply impossible.
This isn't really a single method, but a combination of several methods. It's a brute force[link] attack on all the assumptions you have [assumption reversal]. It requires [link]brain storming for all the possible information and then coming up with a [analogies] which prove that the UX, business model or underlying logic simply won't work.
But it is a rigorous method. What it isn't is a barrage of negative statements until your boss, colleague or client gives in. That's just the builder's technique of sucking through your teach, giving miserable estimates until they're ground down and give in.
You have to be careful about this because if you're wrong - if in proving the unprovability you wrongly prove impossible and someone else proves it possible, this uncovers your lack of knowledge or lack of rigour. You might fairly know less than the next guy, but you shouldn't lose out because of your lack of logic applied to the problem because that bit is simple.
It starts like this:
if
[things that are true]
then
[things that we want to be true cannot be true]
So, obviously you need to understand how the two relate.
Good examples of this are where users can find themselves going down two routes. They can move themselves into a new account, yet can be yanks into another account. Often these impossible problems are user experience and even business logic, rather than programming but if you dont' identify that fact you will be in an infinite loop of fixing-by-breaking, never reaching the goal of shipping the flipping code.
Performance problems can also be unfixable. By finding that the infrastructure is under strain of that third party systems are simply not up to it, you can understand the constrains of the environment. This provides you with the list of things that are true, and allows you to see what isn't possible.
The assumption reversal tehnique is closely related to this. Get a list of everythign you think to be true of the system, about its infrastructure and the business. If these show that the fix cannot be done without somethig in the list of truisms being false, you've proved the problem unfixable.
Proving that something can’t be solves requires stating the case logically: i.e. the way that the system is implemented makes it impossible for the required output ever to happen.
This requires - explaining the way that the system works in logical terms - explaining the required output in logical terms - proving that the two can never match.
