“The mere formulation of a problem is far more essential than its solution, which may be merely a matter of mathematical or experimental skills.” –Albert Einstein
In the past two and half years as an analyst I’ve come to appreciate the above Einstein quote more and more. As by way of illustration, I once was brought in to mediate a project that was going very slowly. The developer kept asking for more details, and the other project manager couldn’t seem to provide them, and felt all the estimates she was getting were way out of line. I sat down with both of them separately, and over the course of the week, tried to figure out the problem. What I found out was for a vast majority of the features, the developer was trying to solve a much more complex, completely unnecessary, problem. The project manager had provided ton’s of detail on what she thought the solution should be, but very little on what the problem actually was. Forced to extrapolate the problem from pieces of the solution, the developer was diving down rabbit holes.
This is a problem I see quite often with a certain kind of client, who tries to describe in exact detail what he or she thinks she wants, without explaining why. Scrum development, if done wrong can even exacerbate the problem, by keeping the team focused on small unimportant problems, while the real goal or need goes uncommunicated.
Even in situations where client’s are upfront and clear about their overarching goals and vision, issues still arise. Maybe the organization or process is so complex that it doesn’t matter how many stakeholders you try to involve, you’re alway missing one.
The solution isn’t to call another fifteen people into the meeting, or to gather more information, draw up more 36 step visios, or mock up another ten forms. In fact, if you’ve already started doing all that, throw it out, or at least stick it in a deep dark file cabinet. Stop focusing on the little problems and start focusing on the problem cloud.
What do I mean by problem cloud? The best analogy is the electron cloud. In physics, the electron cloud is region of space around the nucleus where you’re most likely to find your electrons. Similarly, the problem cloud is the collection of tasks, and challenges your users are most likely to run into.
Just as with electrons, you can’t know where the problems actually are in your cloud. You can’t imagine every little task that your software is going to be called on to help accomplish. So as software designer, your main question becomes “how do I write this such that my users can tweak things to solve almost any problem in this cloud.”
That’s why you can throw out your visio’s, and make all the stakeholders leave the room. Because once you’re at this point, that’s all just noise and reference material. Instead of trying to really understand the complexity, attack it with flexibility. If you can’t remember if the customer wanted the system to do A or B, don’t look it up, make it really easy to do both.
Essentially, make sure whatever you design has a robust configuration engine. Assume that whatever you’ve been told was incomplete, or wrong, or will change, and when the system needs to change with it, you won’t be there anymore. And if you are still there, you’ve probably just made your own job easier.
This is a little different than the scrum mantra of “leave the details until the last responsible minute.” This is more like “leave the details to someone else who’s closer to the process than I am.” And as counterintuitive as it sounds, this is the best way to deal with highly complex processes. The issue is that when you have to use a 36 box visio with dozens of possible branches to describe what the customer is telling you, it probably means the process is very intuitive, and more complex that what you’ve captured so far, and what you’ve drawn is fundamentally wrong in a subtle but important way no one realizes. And if it’s not, it will be a month from now. If you build exactly to spec, you’ll have a rigid, hard to change, and low value system.
To finish off with another quote, I’ll paraphrase Eric S. Raymond. Good tools are useful in the expected way, but a truly great tool lends itself to uses you never expected. In a fast paced, complex, ever evolving business environment, good tools just aren’t good enough anymore. You’ve got to make them great, and that means letting go of the conceit that your system can have a solution for everything. Once you do that, you’re free to build a system that empowers users to solve the problems themselves.