Software is written in a context, in order to solve problems. Over the time, the context is lost, original problems get dissolved (or they don't need solutions, anymore). Original team is not there any longer. New people join, the same old framework (assumptions, etc) is used to solve new problems. That's how complexity grows.
When talking about software complexity, we're really talking about a lot of things.
Most importantly there's essential and accidental complexity. The first is inherent in the problem being solved and the second is complexity that is added in the solution that isn't necessarily required.
The other big issue is deciding what the problem that is being solved is, and how that interacts with previous efforts. Often features get scoped, defined, and implemented without a coherent conceptualization with how it fits. When done this way, the problem definition itself includes unnecessary complexity. This is often hard to avoid as it's hard to get stakeholders and those with an understanding of how things would mesh to speak to same language much less agree.
Even without all those issues, the usual culprit is that software is written by many authors over time where the original authors may no longer be involved. In these cases, many of the best intentions and decisions can get lost in incremental loss of architectural integrity. If you're lucky a new bright author will recognize this as an issue and incrementally evolve it toward suitable new patterns.
Writing software over time with many authors is basically just a version of broken telephone.
3 comments
[ 0.23 ms ] story [ 13.7 ms ] threadRead Peter Naur's "Programming as theory building" http://pages.cs.wisc.edu/~remzi/Naur.pdf
Most importantly there's essential and accidental complexity. The first is inherent in the problem being solved and the second is complexity that is added in the solution that isn't necessarily required.
The other big issue is deciding what the problem that is being solved is, and how that interacts with previous efforts. Often features get scoped, defined, and implemented without a coherent conceptualization with how it fits. When done this way, the problem definition itself includes unnecessary complexity. This is often hard to avoid as it's hard to get stakeholders and those with an understanding of how things would mesh to speak to same language much less agree.
Even without all those issues, the usual culprit is that software is written by many authors over time where the original authors may no longer be involved. In these cases, many of the best intentions and decisions can get lost in incremental loss of architectural integrity. If you're lucky a new bright author will recognize this as an issue and incrementally evolve it toward suitable new patterns.
Writing software over time with many authors is basically just a version of broken telephone.