Remember that the abstractions you built to help you think about problems are there to help. They are not reality, and when you think of them as such they stop helping you, and they hold you back.
You see this problem in the context of software. A programmer creates a software model of a problem, implements a solution in that model, then releases the solution to the modeled problem as a solution to the original problem. Pretty soon, an aspect of the original problem is uncovered that isn’t in the model. Rather than remodeling the problem to encapsulate the new information, though, us programmers will call that an “edge case” that needs special treatment. The solution is now a solution to the model problem, with a little nub expressed as a conditional statement for handling this other case. You do not have to have been working on a project for long before it’s all nubs and no model.
You also see this problem in the context of the development process. Consider the story point, an abstraction that allows comparison of the relative sizes of problems and size of a team in terms of its problem-solving capacity. If you’re like me, you’ve met people who want you deliver more points. You’ve met people who set objectives featuring the number of points delivered. You’ve met people who want to see the earned points accrue on a burn-down. They have allowed the story point to become their reality. It’s not, it’s an abstraction. Stop delivering points, and start solving problems.
