I recently lead an in-depth design discussion for a relatively complex software platform. A few minutes afterward, I was already reflecting on
what had occurred and how. Several things occurred that I’ll call “pattern vs. antipattern” tugs of war. During the meeting, I often felt the group trying to move our discussion in one direction that I, for better or worse, thought was ineffective. I would then redirect us on to what I felt was a better path. In true catalog form, here’s the list:

• Understand the Problem vs. Jump to the Solution — solutions were being flung about like drunken darts only a couple of minutes into our discussion. This situation almost always leads to suboptimal or faulty solutions. As a facilitator, try to ensure that the problem has been clearly stated. If at all possible, write it down on a (virtual) whiteboard. Make sure everyone agrees that the problem as stated is the problem the group is there to solve. Sure enough, after performing this exercise, we all had a very different and clear understanding of the problem than that with which we walked in the door.
• Assume the Worst vs. Assume the Best — occasionally the exact details of a requirement are unclear, and not assuming something will totally derail the design discussion. You have a couple of choices. The first is to halt the discussion and get the details cleared up. This is clearly the best solution, as you’ll no longer have to assume anything. However, it can be the case that the person who can clear things up isn’t available. Or in some cases, the question you’ll be asking will require another meeting at another level of the organization. If you find yourself in that spot, and you can’t wait (we couldn’t!), then the best approach is to work from the worst possible case scenario. You’ll then be in the best position to handle whatever answer comes your way. However, our tendency is often to assume the best (“That will never happen!”). Fight that tendency. However, whatever you choose, follow up at your earliest opportunity.
• Basing Decisions on the Current Situation vs. Basing Decisions on History — many times the group wanted to veer off into safer territory. In some cases, a possible solution departed significantly from the current design. While this is a valid concern (we do want consistency of design across the system where possible), it is certainly debatable. Occasionally the situation at hand will merit a significant departure from the current design. Another way history can rear its ugly head is the assertion that we’ve always solved similar problems like ‘x,’ so we should do so with this problem as well. Again, note the word “similar.” All problems are somewhat different and have their own eccentricities. So, rather than working from history, I pushed us back to a clean slate with the statement “Let’s stop thinking about the past and start from scratch. We may very well come up with the same solution you guys are proposing, but I’d rather do so through our own objective analysis and not instinct.” Guess what. We came up with a different solution that we all felt better about.
• Shooting for the “Best” Solution vs. the “Easiest” Solution — now sometimes we can’t afford the best solution. I grant that. However, I’m trying to fight the tendency to immediately jump to the “easiest thing that could possibly work.” Often this pops up in the first P vs. AP — if we don’t clearly understand the problem, sometimes an easy solution jumps out that doesn’t deal with the underlying details we’ve yet to uncover. Also, sometimes the best solution is quite simple and elegant. It doesn’t necessarily have to be harder and more complex than the easiest solution. In fact, sometimes the “easiest” solution leads to the most accidental complexity in the long run. So, shoot for the best solution you can come up with, and only then, optimize for cost.
• Present Possible Solutions Objectively vs. My Solution is the Best! — one would hope that we all start here, but we don’t. We tend to like our own solutions to problems and want them to “win.” Our ego can get in the way of even hearing an alternate solution presented by another team member. I point you to my friend Ted Neward’s post for more on “egoless programming.” So, as a facilitator, you’ve got to make sure that all solutions are presented objectively. I often had to say things like “OK, let’s assume before we ever get started that this is a good solution to the problem and not hack away at it until it's fully presented, and we all understand it.” In the end, this insistence led us to choose a solution that none of us (myself included) originally thought we’d pick.
• Validating from Code vs. Validating from Memory — more often than not, questions about the existing design/code/behavior will come up. Rather than scratching your head and trying to remember what you wrote six months ago, pull up the code and find out. I can’t tell you the number of meetings I’ve attended where baseless assertions were made about existing code, only to require another meeting the next day to revisit the whole discussion once those assertions were proven wrong. Again, as a facilitator, I directed us to solve every problem for which all of the facts were available. We inserted placeholders in our solution where questions remained. Guess what we’re doing now? Well, I’m writing about the meeting, but the rest of us are validating from code. Tomorrow we'll fill in the blanks!

The original version of this article was published at: https://www.mattstine.com/2011/05/16/design-meeting-patternsantipatterns/