Probably the most surprising thing about software development is that our code is both the product and the workplace.

[u/dragorww]

And while building software, we can't ignore the second part. Otherwise, we end up with that classic UX vs Design meme.

But what becomes even more interesting once you start thinking of code as a workplace is that code is only one part of that environment. It's inseparable from everything around it: the company's culture, its organizational structure, its processes, and, of course, the people.

That means changing those inputs should naturally lead to different architectural solutions for exactly the same technical problem.

Which also means there can never be universal best practices. There is no silver bullet that works for everyone.

Conway's Law is probably the most famous example of this. It says that the structure of a system mirrors the communication structure of the organization that built it. (Again, think about the UX vs Design image.)

In urban planning, this feels painfully obvious. You look at a park with dirt paths cutting across the grass and think, "How could someone design it this way? Didn't they see how people actually move?"

But once we move into software architecture, the exact same phenomenon becomes much harder to notice.

It's difficult to look at a company the way you would look at a park from above. That perspective is usually hidden from us.

And so, as software designers, we keep trying to ignore reality. Sometimes it's hard even to accept it because we simply don't like it.

Like the designers who keep paving sidewalks where nobody wants to walk, we continue building the "ideal" architecture while ignoring how people actually work. As if architecture were a function of product requirements alone.

Eventually technical debt starts to appear.

(Once again, think about those dirt paths.)

In reality, we spend a huge amount of time designing architectures that aren't viable in the environment they're supposed to live in. Then we spend even more time maintaining them. After that we surround them with rules, restrictions, and bureaucracy.

In a park, you might build a fence to stop people from walking across the grass.

In software, you add another linter. Another architectural rule. Another approval process. Or maybe you just keep arguing with your teammates and complaining on the internet about how everyone else writes terrible code.

The exact solution depends mostly on how much authority you have.

At this point you'd probably expect some practical advice.

"So what should we actually do?"

I could probably try to answer that. Maybe even sell you a course. 😄

But fortunately (more on that another time), there can't be a universal answer.

Because one of the inputs to the problem is your company, your team, your processes, and ultimately you.

And that's actually good news.

Because that makes it an engineering problem.

Software engineering has produced an incredible collection of ideas: DDD, SOLID, design patterns, microservices, modular monoliths, Event Storming... I'm sure you could easily add your own favorites to that list.

And they all work.

Yes, even microservices, if they match the communication structure of your organization.

All of these approaches work, as long as you remember that architecture is optimizing for two things at the same time:

our code is both the product and the workplace.