So here is a lesson I take from these kinds of problems. Look at the interface of your program. Are there any elements that seem to be arbitrary decision on yo

So here is a lesson I take from these kinds of problems. Look at the interface of your program. Are there any elements that seem to be arbitrary decision on your part as a designer that are there only so that you have easier time? If yes, even though it might seem a good idea today, there is a chance you will need to change it in the future or it will become a sore for some of your users. Always try to understand the problem in terms of underlying fundamental rules/definitions and only use these for the outside surface (contract, API) of your system. Fundamentals don't change. If they change it most likely means you had wrong understanding of the underlying problem in the first place. Using only fundamentals for your API will mean easier integration with clients and interoperability with other systems. As an example, if you implement an application that assumes that a user account is connected with an employee and the employee only has one manager and that only the manager does approvals you might find that yes, the application works but also you will find yourself an a lot of problems pretty soon when you find that there are times or parts of your organization that don't follow this pattern. - an outside contractor might be brought that needs an account, - an employee or contractor can have multiple managers, - an employee or contractor may need multiple separate accounts, - the manager may need to deputize somebody else to do approvals, - the manager may want to decide they want to run their organization differently and trust their employees to do the right thing (but can't because the app forces approval flow), etc. These problems happened because of naive understanding of the model of the system (ie. the model does not correspond to the fundamental properties of the system) or because the designer decided it is too much work to implement these.