Right, Wrong, and Style

Introduction

This post is the third part of a ramble-rant about the software business. The first post is entitled Goodwill, Negative and Positive; the second, Visions, Quests, Missions.

Right and Wrong

I’ve beat on the right-and-wrong drum a bunch in this series – particularly in Goodwill, Negative and Positive. There are clearly things that conveniently and neatly fall into these categories. And there are things that do not. A lot of those things fall under…

Style

You may find this scary (I do): At the time of this writing, I manage people. The people I manage actually manage people – how scary is that? And the people they manage develop ETL (Extract, Transform, and Load) processes.

Now I’ve written ETL processes since before I knew they were called ETL. That doesn’t make me an expert, but it does make me experienced. I have my own way of approaching solutions. “With all your experience, your way must be the best Andy.” Wrong. Experience doesn’t mean I know everything. You can check with my team, I don’t know everything. In fact, experience has shown me it’s best to keep an open mind and learn something new every day.

I regularly tell members of my team: If you see something that looks dumb, email or IM me and say “Andy, this looks dumb.” I will respond in one of two ways; 1) “It’s designed that way because…”; or 2) “You’re right, that is dumb.” The end result will be a better product for our customers.

One reason I love Test-Driven Development is because it’s built around failing first. And I fail all the time. When I found a methodology that incoporated failure into its cycle, I was home. TDD fit my style.

Really, It’s No Imposition…

Now I could mandate everyone on the team do things that fit my style. But that would be dumb. Why? Because (brace yourself) people are different. Imposing my style on the team would not improve things – it would hamper innovation.

This is why standards usually fail outright or are ignored.

“So what’s the right way to convey best practices, Andy?” It depends. The answer is different for different leaders, because there are different styles of leadership as well. I make heavy use of something I call…

“The Buffet Model”

This model isn’t named after a rich Nebraskan (his name has two T’s), this is from the salad bar / buffet. Basically, I demonstrate the best way I know to solve a problem or address an issue. If that works for you, you are free to use it. If not, you can keep doing it your way so long as it doesn’t really mess up the rest of the effort (more on this in a bit). I believe if you see me enjoying the stuff on my plate, you will say “Hey, that looks good. What is it?” and opt for steak instead of beef broth soup.

There are good reasons for sticking with the broth in some instances, so we don’t make declarations at Andy’s Buffet like “Broth stinks. Always have the steak.” What we do instead is offer two dishes for obtaining beef protein on the buffet and you can choose which one to consume.

Before this analogy is stretched beyond usefulness, let me stop here. The “buffet selections” are actually design patterns. What’s more, any developer on the team can add to the collection of design patterns at any time.

So, what happens if a developer insists on developing in a style that really messes up the rest of the effort? We talk about it. The goal of these meetings is to learn from each other. Each side presents their arguments and the goal is consensus. Most of the time, we reach consensus and choose a pattern that works best. Sometimes we decide both patterns have merit and we agree on when to use each. On rare occassions, this meeting deteriorates into something akin to an intervention. And every once in a blue moon, I have to be the heavy and say “Please do it this way for now.”

Disagreement is Good

When I was in the Virginia Army National Guard, I learned about overlapping fields of fire. It’s part of a foxhole perimeter defense tactic that allows me to take cover behind a berm and shoot at the people running and gunning towards you while you take cover behind your berm and shoot at the people running and gunning towards me. Keeping you safe keeps me safe. We win together.

What does this look like in the software workplace? I find an apt analogy when I work with people who have different styles. They are going to look at any business problem from their perspective, and it’s different than mine. We are going to disagree. They may even say “Andy, this looks dumb.” (We’ve been here already, haven’t we?)

So long as there is trust and respect we can cooperate – even if we have different styles or disagree. This is the first step to a better solution. In the end, we win together.

Conclusion

There’s a difference between “wrong” and “different.” When we learn this, we start to understand the true power of diversity.

:{> Andy