I keep seeing two philosophies bash heads at work.

1. "Hey, use these tools according to idioms and best practices for that tool. We worked hard getting this to work predictably, and it depends on you doing things consistently."

2. "Go pound sand, I want to do what makes sense for the project. To hell with your nazi conventions."

They're both right, and they're both idiots.

#1 is right because precedents exist for a reason. People did a bunch of stuff with their tools and got things to behave reasonably well, showing mastery over a stack. There could also be actual legal- and infosec- related reasons to following a protocol for changes, and ignoring those precedents invites disaster.

#1 is an idiot because there's a fine line between enforcing consistency and micromanagement. If the idioms they confuse with architecture are making it harder for other people to work, then they need to back off and let context, not ego guide the conversation. Good architecture should enable and encourage people to change the software in radical ways.

#2 is right because Context. Is. King. No project should shape around a tool. Tools should simply and objectively obey their users through good and bad use alike in service of the project. A culture that would oblige you to change for the sake of a tool is not an engineering-driven culture, it's a culture driven by self-anointed thought leaders who learned everything they know about software from Medium.com and Smashing Magazine. To enforce idioms and consistency blindly is turn the best practices found so far into the status quo that prevents change.

#2 is an idiot because there's a baby in the bathwater, which is some of that context they so treasure. By getting defensive with #1, they forget that the more they change, the more the team has to re-learn to adapt. The worst case is the cowboy that rewrites the implementation from scratch, causing QA to re-do ALL WORK and causing engineers to drop everything for one person's way of doing things.

The compromise is hard, but here's what I think it entails:

- Context really is king, but frame your changes in terms understood by how the team already thinks about the project; and
- Make those changes work independent of the tech stack on which they sit.

Doing this requires a solid understanding of, well, SOLID, and lots of patience dealing with ego and red tape.

This may seem obvious to you, but I'm so tired of watching the arguments at work about this degrade software quality and the end-user's experience.

  • 0
    @oreru an architect makes plans to be followed, but sometimes doesn’t catch every detail
Your Job Suck?
Get a Better Job
Add Comment