Last time I wrote about the ORID (Objective, Reflective, Interpretive, Decisional) model for conversations. Software development is hard because not only do you have to deal with technical challenges, but there are so many opportunities for poor communication. Detecting when poor communication occurs is important, as it lets you ask questions and steer conversations back into a much more productive result. Here’s a classic conversation I hear on software teams all the time:
Person A: We’re going to use <tool/framework/library>
Person B: No! <tool/framework/library> sucks. We’re going to use <alternative tool/framework/library>
Note that both of these people have jumped to the Decisional stage of the conversation (i.e. What to do). I’m sure that individually, both people went through the model, yet didn’t attempt to step through together (or as a team) each of those stages. I’ve learned that it’s easy to jump to different conclusions (D) if you don’t share the same background.
Using the ORID model as a guide, here’s a much more effective way the people could have had that conversation:
Person A: I’ve noticed we write a lot of code that deals with files. (O)
Person B: I’ve noticed that as well. (O)
Person A: It makes me feel frustrated (R) because we spend less time doing interesting stuff (I)
Person B: I didn’t realise you were frustrated about it! I also notice we tend to have a lot of bugs in that area as well (I)
Person A: I’d like to use some <tool/framework/library> so that we can improve our productivity (D)
Person B: I definitely would like to as well.
Person A: I think <tool/framework/library> would work well
Person B: I’ve had bad experiences with <tool/framework/library> because it also has lots of bugs (I). I think <alternative tool/framework/library> might still do the job, and help you feel less frustrated. What do you think? (D)
Person A: Let’s give it a go.
The conversation may not still go in the same direction of agreement, however there is much more opportunity to discuss why one particular solution will fit the issues both parties are feeling. Without making those items explicit, the discussion becomes an argument about choosing one solution over another. With a shared understanding of how both people are feeling, there are many more opportunities to clarify what problems the solutions are trying to fix. In fact, the solution each party originally thought of may change as a result.
It may also be a good idea to defer making the decision until later, giving us more options.
For example, we might have two developers arguing over Hibernate or iBatis. If we can hide the real framework behind something else, we can try both (and more) without affecting the main body of code.
We can defer the decision until we have real data on which performs better in our situation.
Hi Pat,
I think you have expressed that very clearly, thanks its very useful.
Something I try to bear in mind (often harder to do in practice) is that whatever might be my preferred solution going into a discussion, there may be some context I am unaware of which leads to a different solution.
I agree with Andy regarding evidence based decisions, if we can agree on a way to proove one solution over another we are in a much stronger position, e.g. Maybe we try out both together.
Another aspect is that if someone has a negative association with a certain solution, it is important to try and get to the root of why that is. Did they use an older version? Maybe the context was different and they are not aware of something in the current context? Or maybe there is something you are missing and it will benefit everyone to get to the bottom of it.
Whichever, as you say, if you can at least get a shared understanding of the problem you are working together rather than in different directions.
Cheers,
Jim