Didn't you encounter the problems because you tried to simplify reality by using an abstraction?
Software is always simplifying reality by using abstractions. What else could it possibly do? Completely simulate reality?
As another commenter pointed out, "The map is not the territory."
The full Korzybski quote is perhaps more insightful, if less pithy: "A map is not the territory it represents, but, if correct, it has a similar structure to the territory, which accounts for its usefulness."
> The full Korzybski quote is perhaps more insightful, if less pithy: "A map is not the territory it represents, but, if correct, it has a similar structure to the territory, which accounts for its usefulness."
Right, nobody is expecting a map to actually be the territory. The only question is whether it's useful. We do have a pithier quote for that; one of my favorite quotes of all time:
"All models are wrong, but some models are useful."
But abstractions are also useful. You can't just not abstract anything at all.
I took a look at my company's metrics this morning. Approximately 30% of the candidates we send to clients (and who have not ended up out of the process for reasons outside of quality, e.g. the company hired someone else) have ended up getting an offer. That's an important piece of information: it tells me that my company does not have a problem with failing to screen out weak candidates.
Is that leaving out some important details? Yeah, of course! One of our candidates failed an interview because he was too aggressive in questioning his interviewer about their company's prospects. That's a useful piece of information, too; it was (along with a couple other anecdotes) a clue that we should try to do more basic coaching for candidates before interviews.
The data tells me how common the problem is, and suggests which problems are most critical to solve first. The anecdotes can tell me in detail about the nature of the problems, and suggest to me possible interventions. Both of those things matter.