Tuesday, January 27, 2009

How Engineering Decisions Get Made

Now that we're a small team, patterns are emerging on how we make technical decisions. Team dynamics has always been pretty fascinating to me, and tons has been written about good engineering practices (e.g. Code Complete) combined with good project management (e.g. Getting Results).

Let's say you're working on a big project, and need a design decision. For example, your team is trying to decide whether to go with Rails or Django, or whether to use a database, flat files, or write your own storage system. Maybe you need to define a communication protocol. There are many ways to decide, but it comes down to three basic patterns:
  1. "The Man in the Room" – One of the star developers thinks "I know how to do this," goes off into a room, and reemerges three days later with a prototype. The other developers are shocked and awed. When one discovers a flaw in the decision, the concern is brushed away with "but it's already working!" The design is adopted, partially to not hurt the star developer's feelings. Because the initial decision was never discussed, the developer ended up reinventing wheels, and forgot some of the requirements.
  2. "Let's chat" – An hour-long discussion ensues, dominated by the most outspoken developers. Positions are taken early. The group is by the quieter developers, as initial arguments are exchanged. Eventually, the group moves to the whiteboard, and the different options are sketched out. One group eventually wins over, the other feels beaten. A decision is seemingly reached, but is quickly forgotten, since no one remembered to write it down.
  3. "Committee rodeo" – An overeager project manager proposes to form a committee that makes a decision. Opinions are solicited. Specifications are written, then rewritten. At the scheduled time, all parties involved meet in a room, with a domain expert flown in from across the country to help out. After a day of deliberation, a decision is reached, and the specification becomes forever written in stone.
Well, those are the worst cases, actually, and you can probably make every single one work for you. I prefer (2.), combined with the discipline of writing things down.


Viðar Másson said...

So did you go with Django or Rails?

Paul Böhm said...

Viðar, we didn't really discuss about django vs. rails, gabor just gave that as an example.

(we're already well into using django, but i think most (all?) of us could live with either)

Nivi said...

A couple thoughts:

1. Why not use the scientific method to make decisions? Is there a better approach? Check out Managing to Learn for a formal approach that also addresses the topic of "feelings". Here's a sample.

2. Consider partitioning decisions into ones that are "cheap to change" and ones that are "expensive to change". Choosing a framework can be an "expensive to change" decision. When you're making expensive to change decisions, try set-based development. In your case, you would use Django *and* Rails, learn from both, and then make a decision.

The common objection to this approach is "we don't have the resources to do that." My response is "you don't have the resources to *not* do that."

I recommend Poppendieck and
Poppendieck's Implementing Lean Software Development for more on set-based decision making.

"There's never time to do it right but there's always time to do it over." – ?

"Learning is action reflected." – Kent Beck

leo said...

Actually I'm a big fan to discus important design or architectural decisions with the whole team. Everybody needs to agree on them that they are happy later on working with this decision. We missed this sometimes in the past and I still regret that we missed that.

However these discussions can soon get pretty endless, especially as your team grows. So I’m also a fan that somebody prepares the discussion and makes a recommendation to the team. This is usually your architect or your übergeek, which does know half of the content of the internet. Mostly the team will agree on him anyway, because they know that he knows best. But they have the possibility to decide if they really want what he did decide.

When it does go to such as important question as which framework probably the owner of the company or the boss has finally to decide if he agrees with the teamdecision as this might have an influence on the business as well (how hard it might be to find people work with this technology, legal decisions, corporations and so forth).