Your Software Is a Model. 3 Points That Arise From It.

Your software solves a task.

You map a process, rules, and knowledge of the domain in the software. This mapping is not the reality. It is an image of the reality that your team, and you, have created.

Every representation is an abstraction.

Therefore, the following applies to your software:

1. Your software is flawed. #

Every abstraction has holes. It does not represent reality in detail. It can not and should not. Your software represents only a relevant section in the currently required accuracy. Errors are inevitable.

Everything else would be unaffordable.

2. Your software is (nevertheless) useful. #

Even if errors are inevitable, as soon as even one user can work successfully with your software, a benefit is created. It is not about the most detailed mapping and implementation of all complexity.

Creating value is all that matters.

3. Your software needs adaptation. #

So, since bugs are intentional, one or two will become a difficulty after all. That means you’ll want to adjust your abstraction and your model. This is not bad, it is just predictable and logical.

So be prepared for it and try not to hold on to what is outdated.