What is vs what should be 

As in much of life, software can drive you crazy because how things are (“what is”) is not how we’d like (“what should be”). 

Years ago, a client came to me with a small issue in their accounting software.  There was indeed a problem.  The software company acknowledged the issue. But they weren’t going to fix it any time in the next six months.   

It wasn’t a major issue.  They could live with it.  And one of my developers could fix the problem. 

But the client just couldn’t get over how this was JUST WRONG. 

He was stuck on the divide between what is and what should be.  And he spent at least 20 minutes talking to me about the injustice of it all.* 

This is a key way that projects can get messed up. People get caught on what should be.  What was promised.  What they thought they heard.  What they really want. 

Instead of trying to find a way to make things work right now.  Which is often possible if we let go what we think should have been.     

*My developer fixed it.  Took much less time than the time spent complaining.