Highlights
Passages saved from the original.
- generic software design advice is typically useless for most practical software design problems.
- When you’re doing real work, concrete factors dominate generic factors.
-
- In large codebases, consistency is more important than “good design”
- The kinds of topic being discussed are not “is DRY better than WET”, but instead “could we put this new behavior in subsystem A? No, because it needs information B, which isn’t available to that subsystem in context C, and we can’t expose that without rewriting subsystem D, but if we split up subsystem E here and here…“.
- Generic software design advice is useful for building brand-new projects.
- Generic software design advice is useful for tie-breaking concrete design decisions
- This is one of the most useful functions of an official “software architect” role: to provide a set of general principles so that individual engineers can all tie-break their concrete decisions in the same direction3.
- architects can both claim credit for successes (after all, it was their design) and disclaim failures (if only those fools had followed my design!)
- When working on large existing codebases, useful software design discussions are way, way more concrete than many people believe. They typically involve talking about individual files or even lines of code. You thus can’t do useful software design without being intimately familiar with the codebase (in practice, that almost always means being an active contributor).
- Purely generic architecture is not useless, but its role should be restricted to (a) setting out paved paths for brand new systems, (b) tie-breaking decisions on existing systems, and (c) helping companies make broad technology choices.
Summary AI-generated
Summarised by an AI assistant when this source was saved. Double-check against the original.
In summary, meaningful software design is fundamentally a concrete process that requires intimate knowledge of an existing codebase, rendering detached generic advice largely ineffective except for new projects or high-level decision tie-breaking.
- Generic design principles are largely useless for existing large systems because concrete constraints and internal consistency outweigh abstract best practices.
- Meaningful software design requires active participation from engineers who intimately understand the system’s current state and implementation details.
- Generic advice remains valuable only for architecting new systems, tie-breaking between acceptable options in existing codebases, or setting company-wide technology standards.
- Detached "architect" roles often fail to produce implementable designs; tying design ownership directly to hands-on implementation would align incentives with practical engineering reality.
Notes this inspired
- Generic vs Concrete software designGrowing
What worked for others in other scenarios might not work for you. Concrete system design discussions are best done by the people involved in working in the system. It'll be more specific.…