Bilingual

Learning Software Architecture
16 hours ago
- Software design is best learned through hands-on experience, not just formal courses.
- Conway's Law explains that software architecture mirrors the social structure of the producing organization.
- Incentive structures (e.g., PhD deadlines) heavily influence the quality and nature of scientific software.
- One can attempt to change incentive structures (rare but impactful) or adapt to them.
- The rust-analyzer project shows design decisions to attract both deep contributors and weekend warriors, e.g., by isolating features and using catch_unwind for safety.
- Recommended resources: Boundaries talk by Gary Bernhardt, How to Test, ØMQ guide, Jamii's blog, Ted Kaminski blog, Software Engineering at Google, and The Philosophy of Software Design.
Package Management as Org Chart
17 days ago
- Conway’s Law states that an organization's system design mirrors its communication structure, including dependency management strategies.
- Dependency management tools encode resolution strategies and manifest formats that define permissible dependencies and how conflicts are resolved.
- Different strategies reflect organizational dynamics: monorepos enforce uniformity, workspaces allow autonomy, and tools like Bazel enforce explicit dependencies.
- Maven uses 'nearest-wins' mediation, prioritizing proximity in the dependency tree, akin to top-down organizational decision-making.
- Containerization (e.g., Docker) shifts control to developers, while infrastructure-as-code (e.g., Terraform) creates interfaces to reduce paging.
- Runtime dependency negotiation (e.g., module federation) defers version resolution to avoid inter-team conflicts, reflecting fragmented leadership.
- Strategies like vendoring dependencies or using lockfiles represent responses to past issues, such as upstream instability or bad experiences.
- Automated tools (e.g., semantic-release) reduce human liability in releases, and Go's MVS ensures upgrades occur only when explicitly required.
- Onboarding tools (e.g., Brewfile) may formalize processes but often fail, relying on informal support channels like Slack for actual setup.
The Vertical Codebase
24 days ago
- The author argues against horizontal codebase structures that group by type (components, hooks, types, utils) because it separates related code by domain, making navigation and maintenance difficult as the codebase grows.
- Horizontal structures increase cognitive load and reduce cohesion, as code that changes together doesn't live together, leading to poor scalability and discoverability issues, exemplified by Sentry's codebase with over 200 files in a top-level components directory.
- The proposed alternative is a vertical structure, where code is grouped by domain or feature (e.g., src/widgets/) rather than technical type, aligning with team ownership and logical groupings to improve cohesion and reduce unnecessary coupling.
- Vertical grouping requires thoughtful organization, often tied to routes or pages, and may involve creating separate verticals for shared components like PageFilters, with clear public interfaces to manage dependencies and enforce boundaries.
- Implementing vertical structures can involve tools like monorepos with pnpm workspaces, eslint-plugin-boundaries, or Nx to enforce dependencies and define public interfaces, though it requires more communication and effort to avoid duplication and ensure correct grouping.

Hasty Briefsbeta

software-architecture

Learning Software Architecture

Package Management as Org Chart

The Vertical Codebase