I got a headache, and I’m not speaking about my latest mention on the Simon Morley’s curiously named blog. It’s more about tiny little questions I keep on hearing when someone says something which is vague in nature. I hope to get rid of these headaches once I have written them down. So, for my first post in 2011, here it comes.
Compared to what?
Whenever I read or hear some absolute statement, I start to wonder compared to what. For example consider a status meeting of a software project in a crisis situation. Since the measurement systems of the project are probably the first to go overboard (with reference to Weinberg’s QSM Vol. 2), there is certainly serious trouble. Now, team sits together and starts to blame everyone for their crisis situation. As Bob the programmer says: “You testers should have found that serious load bug.”
Pause for a moment.
Count to ten before deciding how to respond to that sentence.
Just another moment.
Now, as your blood gets back into your brain, ask yourself first: “compared to what?” Maybe if you had spent more of your time testing for load and scalability, then the tremendous bugs in the functionality wouldn’t have been found in first place. Maybe most of the team goofed off most of the time. Without deriving the context in which Bob sees this premise you are not able to respond congruently.
But how do we derive that context? Well, by asking Bob questions. Try to find out what he is concerned about. What is it that he wants to ask us? Maybe it is a team problem, maybe Bob is right, maybe … All of this is of course just fiction, but in order to respond constructively we may want to derive the context first.
After we found out more about the problem at hand, we may continue to derive what the problem is, whose problem we are faced with, and who should solve it. If we find suitable answers to these questions, we have identified the problem. Congratulations. At that point we can finally decide whether or not we should solve the problem. Wait, we can “not solve” the problem? Of course we can. if your lights are on you may figure out whether or not you are in charge to solve that problem, thereby doing the right thing. Just remember that cucumbers get more pickled than brine gets cucumbered. (The Secrets of Consulting, Gerald Weinberg, Dorset House, 1975, page 125)
Whenever someone makes an absolute statement, conclude his sentence with “… until now” in order to open the full variety of things he hasn’t considered. By simply adding these two words you open up minds to consider alternatives otherwise rejected or neglected. Take for example a response to Bob’s claim from earlier: “We have absolutely no experience with load testing such an application!” Stand-alone this is a rather defensive reaction to Bob’s blaming. But if we now conclude “… until now” we open up the prospect that humans have the ability to learn new things.
Left alone the response would hinder further thought to alternative solutions as if the content is a Law of Nature. By adding “… until now” we open up the possibility to change viewpoints in the future, and to adapt to changing circumstances.
These tiny little words work in many situations. Take for example “we have never delivered a good GUI to our customers.” “… until now.” Now, we can have a discussion about what it needs to develop a meaningful GUI, rather than spend time in sorrow that we’ll be unable to do anything about the Law of Nature.
For whom? When? In which context?
This is probably the most surprising consideration. We derived the context earlier. But more often than not, statements like “complexity”, “enterprise”, “apple pie”, or “quality” are an attribution to a relationship between a thing and a person. In the software world more often than not this involves a software product and a person. So, rather than rest upon “we have quality problems in our software”, start to ask quality for whom? Problem for whom? When? Under which circumstances?
Try these three little things out, and I hope I haven’t planted my headache into your head by this write-up.