Sez You Architecture and the Architecture Ninja
I don't like getting into architecture arguments with people who are fundamentally interested in the argument being constructive. There's discussions and there's arguments. Having an argument doesn't mean that it has to turn into a shouting match or a "measuring contest."
I try to remind whoever I'm arguing with that we're both on the same side, with the same goals.
Sometimes, though, these Architectural Arguments devolve into what I call "Sez You Architecture."
These kinds of meetings usually go something like this:
"I'm concerned about the lack of Unit Testing on Project A. I'd like to see a little less coupling and some better code coverage numbers, otherwise I won't feel comfortable signing off on a Go-Live."
"Sez you. My team has done a great job and I don't see a problem."
Sometimes I feel like Harvey Keitel as "The Wolf" in the movie Pulp Fiction.
"Pretty please, with sugar on it, fix the ****ing build server." - Scott 'The Wolf' Hanselman
Discussions that devolve into "Well, sez you" are never healthy for anyone. Nobody wants to be the bad guy, and it's rarely a good idea for management to go get "The Smart Guy" and have him come crashing down through a stained glass on a zipline ready to save the day. However, doesn't that so often seem to be the case?
Bringing in external assistance or even oversight/governance can be a good thing, but only if the tone of the engagement is set properly. Everyone should agree what the goals are and what success looks like. The person coming in should understand they are there to help, not to dictate rules or order people around. It is very likely that the Architecture Ninja has little context and has only been told that things are messed up and that a few specific people should be killed to get the project on track.
Instead, in my experience, folks should consider two primary issues:
- The folks ON the project may not be able to see the holistic view, as they're just too close.
- The Architecture Ninja can't possibly understand the complete history of why certain decisions were made.
If everyone remembers these two basic facts, things might turn out better. The project team remembers that the ninja is here to help, while the ninja should focus on highly leveraged actions and avoid going over things line by line.
A crappy project can't be fixed by a line by line code inspection, no matter how good a ninja one is. Sez me.