Go Hang Yourself 4
How do you handle disputes with design decisions? There’s a few different strategies, including drawn out discussions, giving them rope, or “I am god, hear me roar”. They all have their pros and cons. There are a few facts that can’t be denied:
- Design is a creative process
- One design does not fit all problems
- No matter what you choose, there will always be a better way
- There are drawbacks and risks to every design (submitted by Doug)
So, what about driving consensus with long, drawn out discussions? After all, if two heads are better than one can’t we avoid bad decisions by having everyone agree on a solution? This is what makes design by committee fail flat on its face. In essence, the consensus based design is driven by compromise and making the wrong people happy. The people that need to be happy are the ones using your software (not necessarily the same as the ones paying you to create the software). That’s another challenge that isn’t the same as today’s topic. The people that don’t need to be as happy with the user interface design are the people who write the software. Everyone has their own opinion and their own idea of what’s best, and when you try to please everyone you have a project that looks like Frankenstein’s monster. Worse, it works about as well.
Ok, so many times consensus among opinionated people doesn’t work out. What’s another approach? Well you can give people some rope to hang themselves with (and hence, the name of the article). One of four things will happen: the dissenting opinion will run out of energy trying to prove the point with code, the attempt to try something new will completely fail, one of the alternate solutions will succeed, or you will have more than one correct solution. But the point is you now have something more concrete than windbags throwing their weight around. If the dissenting opinion runs out of steam, or the idea fails, you have some experience pointing to the fact that the proposed alternate solution wasn’t a good idea to begin with. If the alternate solution succeeds, and the main solution fails, you are not stuck. If they both succeed, you can now choose the most elegant of the two and move forward. Of course, at this point you may have to resort to the last option…
We’ve all dealt with the type: “I am the design god, hear me roar!” I’m sure, if we were honest with ourselves, we’ve all been that person. Honestly, there are times where we need this person. A strong person to move the team forward with something . We all know that it’s not the best way because of the third point above, but it may be the best option right now . There’s going to be some dissension at different points, and there does need to be someone who will make the determination. This person should be fair and unbiased, choosing what is best for the project. The danger of the design god personality is that there is always the possibility of only pushing their own preferences, regardless of whether it is right for the project or not.
I’d add a fourth undeniable fact to your list: there are drawbacks and risks to every design.
Your recommendation seems similar to Toyota’s set-based concurrent engineering (SBCE): have multiple teams, each working on a different design, and a date certain at which the final design will be selected by the lead engineer.
SBCE covers more than just that, but that’s the central idea. There are a lot of processes that feed into this. One thing that’s important is that there are no “winners” and “losers” among the teams; they all are working toward creating a top product.
You are absolutely right. I’ll add that fourth fact to the list.
Interesting post.
Look at it this way; maybe the only undisputed benefit to design by committee is to be a check on the power of the more powerful members. If the lesser members can, in effect, veto or filibuster changes that go against their preferences, it’s guaranteed that whatever emerges, while usually ugly and hard to work with, is at least not going to make your life worse.
A design god, on the other hand, is a feast or famine. They’ll either hit it out of the park or they’ll create something far more evil than the worse committee-spawned creeper.
The committee approach is best for protecting the interests of all members regardless of relative political power, while the design god gives you the only shot at Correctness at the risk of Massive Fail. Sometimes protecting people is more important and sometimes you know that if you fail, someone else will try and get it right, so I guess you need to decide which one is more important to you.
Pure design by committee is guaranteed to extend the time it takes to make the final product due to the discussion that goes on.
You do need to validate your design, which is something that wasn’t really addressed in the article. If you assume your design is validated merely because a committee spit it out, then you are sorely mistaken.