TL;DR
Meaningful software design requires intimate knowledge of the existing codebase; generic design guidance rarely maps cleanly onto large, evolving systems. Broad architectural guidance can help for new projects, tie-breaking decisions, or company-wide standards, but design work is most effective when done by engineers who implement and maintain the code.
What happened
An argument was laid out that effective software design on large, established systems depends on the people who actively work on those systems. Generic, high-level design advice—what the author calls "designing to the problem"—is common in books and blogs, but has limited practical use when engineers face the messy realities of a shared, changing codebase. In such environments, concrete constraints, internal consistency and small implementation details usually determine which changes are safe and feasible. Design conversations that succeed tend to be narrow and technical, among a few engineers familiar with specific files, subsystems and recent refactors. The piece also notes exceptions where generic guidance helps: building greenfield systems, resolving ties between acceptable concrete options, and establishing company-wide architectural directions. Finally, the author warns that standalone architect roles that don't share implementation responsibility often produce designs that are difficult to realize in practice.
Why it matters
- Design decisions disconnected from the codebase risk being impractical or impossible to implement in the real system.
- Relying on abstract architecture alone can create a gap between planners and implementers, undermining project outcomes.
- Assigning design work to engineers who also build the system helps surface concrete constraints and reduces downstream surprises.
- Generic principles still play a role for new projects, company-wide consistency, and breaking ties between viable implementation paths.
Key facts
- The author distinguishes "generic software design" (high-level principles) from "concrete software design" (decisions grounded in the current code).
- Generic advice is ubiquitous in literature and discussions but often unhelpful for day-to-day work on large, shared codebases.
- In established systems, internal consistency and small implementation details frequently outweigh abstract design principles.
- Meaningful design conversations typically happen among a small group of engineers who actively contribute to the codebase.
- Concrete constraints can reduce viable implementation options to a small set, making an intimate knowledge of the system essential.
- Generic design guidance is most useful for greenfield projects, for tie-breaking between acceptable concrete options, and for company-level architectural choices.
- The author argues that formal architect roles that spend all their time on abstract designs tend to deliver little value to implementers.
- A proposed remedy is that designers should share accountability for a project's success or failure to align design and implementation incentives.
What to watch next
- Whether organizations shift responsibility so designers also carry implementation accountability (the author advocates this).
- The extent to which companies favor "paved paths" and general principles versus empowering local engineers to make concrete decisions.
- not confirmed in the source: The specific impact of AI-assisted development on the balance between generic and concrete design practices.
Quick glossary
- Generic software design: High-level design advice and principles that are not tied to a specific existing codebase; useful for broad guidance.
- Concrete software design: Design decisions made with detailed knowledge of an existing system's code, constraints and recent changes.
- Codebase: The collection of source code, configuration and related artifacts that make up a software system.
- Greenfield project: A new software project started from scratch, without constraints imposed by an existing codebase.
- Architect (software): A role focused on high-level architecture and design; responsibilities and practices vary between organizations.
Reader FAQ
Who should do software design for large systems?
Engineers who actively work on and understand the codebase are best positioned to make meaningful design decisions.
Is generic design advice useless?
Not entirely; it's valuable for new systems, company-wide consistency, and as a tie-breaker between concrete options.
Are formal architect roles ineffective?
The author contends that architect roles focused solely on abstract design often fail to deliver practical value to implementers.
Can a full rewrite make generic design practical?
The author notes that if you could freely rewrite an entire system, generic design would be more applicable; otherwise it's constrained by concrete factors.
You can't design software you don't work on Only the engineers who work on a large software system can meaningfully participate in the design process. That’s because you cannot do…
Sources
- You can't design software you don't work on
- You can't design software you don't work on | Lobsters
- Why You Can't Design Solutions Before Coding
- programming practices – Over thinking development
Related posts
- How market design transformed Feeding America’s food distribution
- Kidnapped by Deutsche Bahn: A 35 km Trip That Ended 63 km Away
- Feynman’s Hughes Lectures: 950 Pages of Handwritten Notes, 5 Volumes