The Problem With Calling Them Laws
Every developer has read them. Conway's Law. The mythical man-month. DRY. SOLID. We treat these like physics—immutable truths that govern how code must behave. But here's what bothers me: they're not laws. They're post-mortems dressed up as prophecy.
A law predicts what will happen. Gravity doesn't negotiate. Drop something, it falls. But software engineering "laws" are really just patterns we noticed after things went wrong. Fred Brooks watched a software project collapse in 1975 and wrote about it. We've been citing him like he discovered a fundamental force of nature.
I'm not sure this helps us. Maybe it actually limits us.
- We use them as permission to avoid hard conversations about why our project failed
- Copy-pasted architecture decisions because "Conway's Law says our org structure will match our code structure"
- Stayed rigid when flexibility might have saved three months of work
Where They Break Down
Last year I built a real-time collaboration tool for a Bogotá-based design studio. Twenty-three people. Three teams. The textbook move: organize your codebase to match your org structure. Clean boundaries. Microservices. We spent four weeks architecting for something that never happened. By month two the designer needed access to the backend team's components. The frontend team needed to debug the API layer. Turns out when your company is small enough, pretending you're Netflix's engineering org just creates friction.
The law didn't predict our actual constraints. It predicted a different team. A different budget. Different urgency.
Or take the mythical man-month. Yes, adding people to a late project makes it later. This is true. But it's not true universally. It's not true when you're building an MVP where people can work in genuinely parallel tracks. It's not true when hiring means getting one specific person who knows your codebase already. Brooks watched sequential work on an operating system. We act like he was describing all software forever.
I'm not sure we should trust any principle that doesn't account for context, but I keep reaching for them anyway because they feel safer than making the call myself.
Why We Need Them (Even If They're Broken)
Here's the contradiction: I wouldn't ship my last three products without thinking through these patterns.
They're useful because they're distilled experience. They work as check-in points. When you're tired at 2 AM and wondering if you should refactor that controller, DRY reminds you that duplicated code is usually a smell. Not always. But usually.
The danger isn't in knowing them. It's in worshiping them.
- They work great as conversation starters
- They're terrible as conversation enders—when someone says "Conway's Law says" and suddenly debate stops
- Use them to question your assumptions, not to avoid thinking about your assumptions
What I Actually Do
I treat software engineering principles like what they actually are: observations from other people's expensive mistakes. They're signposts pointing to risks I should watch for. Nothing more.
When I start a new project, I don't ask "which law applies?" I ask "what could go wrong with this team, this timeline, this scope?" Then I go back and check if any established pattern has something to say about that specific risk. Sometimes they do. Sometimes a "law" actually captures something real about my situation. Other times the answer is just: hire better, communicate more, scope tighter.
The hard part? Knowing which is which. Knowing when you're invoking a principle because it genuinely applies versus when you're hiding from a decision that needs human judgment and context you don't want to admit you lack.
That's not a law. That's just work.
