>The programmer would have had to miss something architecturally up front for that to be the case. It happens, but it's not that common.
It is very, very common indeed. Seldom is software created with all the requirements and complexities of the problem known upfront. In fact, very often the process of development of the software itself reveals all the different ways in which the original specifications were imprecise and not completely thought through. And new features and requirements get added onto later all the time.
Software is created in an iterative process of feedback and development. At each stage, the programmers takes the shortest, most straightforward approach to solve the problem. When the programmers are not careful (or just lazy) they inadvertently add dependencies that shouldn't exist and make the whole thing more complex. Of course, any single infraction seems innocent enough, but eventually you almost always end up with software that is much more complex than it needs to be.
Here is a talk on how software is too complex all the way from 2006. I am more than confident that the problem has only gotten worse in last 15 years.
> At each stage, the programmers takes the shortest, most straightforward approach to solve the problem.
Unfortunately, this is the often the best case. There’s a point in the life of most good programmers where they can’t help but to massively over engineering everything they make, adding pointless interfaces and abstractions everywhere, to chase the dream of reusability. This mindset will utterly bury your capacity to iterate.
I once saw a Java method trail to initialise something which was 19 levels deep - each level just making one method call to the next abstraction. You couldn’t just trace it in the IDE - lots of those calls called an interface method or something, so you had to hunt down the implementer. But it got worse. There was also a method trail alongside it for cleaning up that context. It had the same 19 levels deep trail, but after all that work the final callee was an empty function.
It is very, very common indeed. Seldom is software created with all the requirements and complexities of the problem known upfront. In fact, very often the process of development of the software itself reveals all the different ways in which the original specifications were imprecise and not completely thought through. And new features and requirements get added onto later all the time.
Software is created in an iterative process of feedback and development. At each stage, the programmers takes the shortest, most straightforward approach to solve the problem. When the programmers are not careful (or just lazy) they inadvertently add dependencies that shouldn't exist and make the whole thing more complex. Of course, any single infraction seems innocent enough, but eventually you almost always end up with software that is much more complex than it needs to be.
Here is a talk on how software is too complex all the way from 2006. I am more than confident that the problem has only gotten worse in last 15 years.
https://www.kernel.org/doc/ols/2006/ols2006v1-pages-441-450....