> In real life things get very complex because there are 200 working parts interconnected. And not because "it's bad design". But because that is the requiremen

> In real life things get very complex because there are 200 working parts interconnected. And not because "it's bad design". But because that is the requirement. These sorts of things are always better discussed in terms of specific cases instead of generalities, but I think one of the key parts of good software engineering is factoring the requirements into the simplest design possible. And even when time or other considerations prohibit creating an extensive design ahead of time, practicing a few well-chosen heuristics like "use composition", "keep functions and methods short", "use clearly defined and consistent terminology in your abstractions" can go a long way to making code less unruly and easier and cheaper to refactor down the road.