You can't design software you don't work on

Limits of Generic Design Advice

• Many agree high-level principles and shared terminology are helpful for framing problems, but “the map is not the territory.”
• Several note the article itself becomes the kind of generic advice it criticizes and is tautological.
• Some argue foundational CS concepts (types, invariants, error handling, time/space tradeoffs, concurrency, information theory) change slowly; what churns is surface-level tools and patterns. Others counter that the “body of knowledge” about how to structure systems is huge, evolving, and context-dependent.

Architecture vs Implementation

• Strong support for the claim that you can’t effectively design features for a large, existing system without working in that system: real constraints are buried in code, data, and historical hacks.
• The “Amazon free samples” example is used to show how “simple” requirements explode into many edge cases that are hard to foresee upfront.
• Some push back: with enough prior experience building similar systems, you can design large applications without coding, especially for greenfield projects.

Is Software Engineering or Art?

• One view: because practices and trade-offs shift rapidly, software is more creative art than stable engineering, albeit with engineering-adjacent disciplines.
• Counterview: we do know how to build high-reliability systems (e.g., NASA style), but it’s too slow/expensive for most businesses, which optimize for “good enough” over “good.”

Role and Value of Architects / Analysts

• Many criticize “architects” who don’t code or read the code: they give buzzword-laden, unusable guidance or rubber-stamp designs produced by senior devs.
• Others defend a distinct architecture/analysis role focused on understanding business information flows and big-picture coherence, with programmers handling technical details.
• There’s nostalgia for systems analysts and careful upfront analysis in older industries (e.g., banking); start-up cultures tend to favor rapid experimentation instead.

Consistency vs “Good Design”

• The article’s line “consistency is more important than good design” is heavily debated.
• Pro-consistency camp: heterogeneous stacks and “cowboy” tech choices (e.g., one-off Redux sections, random frameworks) impose cognitive and maintenance costs; consistency improves onboarding, velocity, and allows fixing bug classes once.
• Skeptics argue that rigid consistency can entrench bad patterns, discourage incremental improvement (violating the Boy Scout rule), and push toward risky “boil the ocean” rewrites.

Domain Understanding and User Involvement

• Several stress you can’t design good systems without deep understanding of the business and users.
• Best results reportedly come when engineers are also active users, can directly see user issues, and have freedom to fix small problems opportunistically.
• Discussion touches on XP’s “customer on the team,” with caveats that real customers often don’t want to be involved; effective “customer proxies” are needed.

Organizational and Incentive Problems

• Commenters blame cheap, compliance-obsessed leadership for underinvesting in real architecture and refactoring time, leading to long-lived “Galactus”-style monstrosities.
• Short average tenure (≈2 years) limits developers’ holistic understanding; “architects” often become meeting-bound approvers rather than real designers.
• There’s also criticism of “Real Programmers” who optimize low-level details while resisting necessary business-driven change, creating complex but brittle systems.