"Only the engineers who work on a large software system can meaningfully participate in the design process. That's because you cannot do good software design without an intimate understanding of the concrete details of the system. Generic software design What is generic software design? It's "designing to the problem": the kind of advice you give when you have a reasonable understanding of the domain, but very little knowledge of the existing codebase."
"When you're doing real work, concrete factors dominate generic factors. Having a clear understanding of what the code looks like right now is far, far more important than having a good grasp on general design patterns or principles. For instance: In large codebases, consistency is more important than "good design". I won't argue that point here, but I wrote about it at length in Mistakes engineers make in large established codebases."
Meaningful design decisions for large software systems require engineers who have intimate, concrete knowledge of the existing codebase. Generic design advice aimed at domain-level problems is of limited practical use when codebase details are unknown. Concrete factors such as current code structure, existing dependencies, and unpredictable interactions typically constrain implementation options and dominate general design principles. In large shared codebases, consistency often matters more than pursuing an idealized design. Individual changes must account for how the codebase will integrate those changes given its intermediate, mixed-state architecture. Complete rewrites would make generic guidance more applicable, but are rarely practical.
Read at Seangoedecke
Unable to calculate read time
Collection
[
|
...
]