Twenty-six years of developing software for different organizations yet I still struggle with the desire for simplicity in the face of conflicting needs.
The tendency is to think of a "user" as a lone person in front of a screen using a UI of some kind. This idea of user is incomplete. In addition to people using a UI, for say a university financial aid system, a management chain exists with the need for applications to be modified as quickly as possible with new requirements and with no interruption of service. They need applications to communicate with one another. To meet those needs, developers utilize libraries, frameworks, etc. for modularity and reusability. To insure that nothing gets broken while modifications are made, regression testing must occur. Adding test suites increases the likelihood of uninterrupted service. To help with module interdependencies, developers use package managers. And so the stack of software grows.
I'd call it accidental complexity, but it's not an accident. We are dealing with complex software stacks, often with interdependent modules, because we are trying to meet many different needs simultaneously. I don't see an easy way out of the situation.
Over the years, I've become better at determining when to abstract problem solutions in order to provide for future needs and when to do the minimum possible to get the problem solved. I don't think there is a rule or formula for making that determination. You just have to make mistakes and learn from them.
The tendency is to think of a "user" as a lone person in front of a screen using a UI of some kind. This idea of user is incomplete. In addition to people using a UI, for say a university financial aid system, a management chain exists with the need for applications to be modified as quickly as possible with new requirements and with no interruption of service. They need applications to communicate with one another. To meet those needs, developers utilize libraries, frameworks, etc. for modularity and reusability. To insure that nothing gets broken while modifications are made, regression testing must occur. Adding test suites increases the likelihood of uninterrupted service. To help with module interdependencies, developers use package managers. And so the stack of software grows.
I'd call it accidental complexity, but it's not an accident. We are dealing with complex software stacks, often with interdependent modules, because we are trying to meet many different needs simultaneously. I don't see an easy way out of the situation.
Over the years, I've become better at determining when to abstract problem solutions in order to provide for future needs and when to do the minimum possible to get the problem solved. I don't think there is a rule or formula for making that determination. You just have to make mistakes and learn from them.