Comment by lyaa
4 years ago
The complexity of many applications does not come from the client-facing features but rather from other business requirements.
For example, interaction analytics, A/B testing support, targeted updates, predictive caching, obfuscation and security, etc. For large companies, setting up the code base so new junior employees can start making contributions fast is also important and that adds to the total complexity too.
It's so much simpler to build an app if all you needed to do is get the minimum features done.
Yeah, not really. I've worked at some big companies, and currently at one you almost certainly have heard about in the news. The features you describe don't justify the complexity of these apps. Usually these features are implemented without any real consideration for the overall architecture, independently, and within a bubble such that the engineers and PMs on the project locally maximize the feature's complexity. Then it cascades when the feature is integrated into the rest of the app.
I think we differ in what we consider "justification." It seems to me that you are using the moral judgement of the sacrifice of perfect-pretty-code while I am considering the business-operations evaluation.
For a company which needs teams to implement features independently, the bubble you judge to be negative could indeed be an acceptable, or even necessary, compromise. The business decision to have independent teams might introduce complexity, sure, but within the context of the company's needs and goals, it might be a good choice and thus the added complexity is justified in my view.
The goal of any company is not to generate the most optimized code base. It only needs code that works for its purposes. It's a necessary balance which carries risks and opportunities.
I don't disagree with your last paragraph. I think we just disagree on where that line is reasonably drawn.