Developing solutions to complex technical problems as a team can be fun and challenging, but also highly contentious as every great developer has their own Grand Plan for how things Should Work. For every developer in the room there will be just as many proposed solutions to any given problem. They may be based on competing philosophies, varieties of foresight, attention to edge cases, and other considerations that provide a fertile ground for a passionate discussion, but that discussion often struggles to find focus and consensus.
So how do you streamline this process? Discussions like these can go on endlessly, go off on tangents, and nitpick on trivial details. How do you avoid hashing out solutions that are over-engineered and overly complicated?
One way to do this is to focus more on the problem rather than the solution.
When you focus solely on the problem, you’re working with facts everyone can agree on. Aim your discussion at getting everyone to fully understand the problem, and all the issues surrounding it. Once everyone is on the same page, you’re better positioned to prioritize the issues and offer specific proposals to address them. At this point, you still need to work to keep the discussion focused, so always take every solution and go back to understand the problems they address, and their side effects.
As an example here’s a set of 5 questions I like to follow when attacking a new problem. In general, it keeps me focused, while preventing me from falling in love with any one solution prematurely.
1. What is the high level problem you want to solve?
2. What impediments are currently making this a problem? i.e. Why does this problem exist?
3. For each impediment, what are the issues that need to be addressed to resolve that impediment?
4. For each issue that needs to be addressed, what are all the possible solutions you can imagine?
5. For each solution, what are each of their advantages and disadvantages? What is the scope and magnitude of each of those advantages/disadvantages?
The main things to take away from this are that in steps 1 through 3, you’re just decomposing the problem. Every complex problem is just a combination of simple problems. When you’re dealing with simple problems, you’re more likely to come up with simple solutions.
A second thing to note is that it isn’t until step 4 that you’re even thinking about solutions. Also, your goal at this point is to come up with multiple solutions to each issue. This is very useful for helping everyone keep an open mind. Each individual should make it their goal to see the advantages and disadvantages of each possible solution rather than picking one and arguing it to death.
Step 5 may still be the most contentious since it leaves the most room open for debate, however the fact that you’ve just laid out and decomposed the problem should lead to a more focused discussion on possible solutions.
So in your next planning meeting, give this a shot, and see if it leads to a faster successful outcome, or at the least, a more enjoyable meeting. The key thing is to use the forum of a group discussion to make sure ideas are added that any one person may have missed — not as a platform for everyone to argue their master plan. Ultimately every developer has the same goal of solving problems, executing that goal well as a team is the challenge. But instead of getting passionate about the solution, get passionate about understanding the problem.