Something that drives me quite batty is when people turn to me for help and request a solution without explaining the problem. In other words, they tell me their answer to a puzzle, without explaining what the puzzle is, and expect me to understand what to do. They want the answer to be 42, but what is the question being asked?

This happens a lot in software design. The client calls up and tells us they want something done a specific way. They are telling us how to implement a feature, without explaining what the feature is or why it needs to be done their way. Since they don’t understand the architecture of the product, they usually don’t understand the impact of the request. And since they are approaching the problem from a non-technical perspective, their proposed solution may not technically work.

Now if they told us first what the problem is in detail, then their proposed solution, we can contribute to the discussion. We can laud them if their solution is great or present alternatives with lesser impacts because we now know and understand the problem too. And we can implement the chosen solution better because we also understand the problem better.

I am not sure I understand why people communicate this way. Maybe its embarrassing to explain a problem, or people feel they are being helpful by providing a solution. Maybe its human nature to only present solutions because, in doing so, they are proving their worth. Or maybe because they have found a single solution, and they are just plumb proud to announce it.

Whatever the reason for this communications flaw in all of us, it’s not good for great software design. Great design comes from finding multiple solutions to a problem, attacking it from different angles and mind-sets. Mosly, I find just dicussing the nature of problem exposes a myriad of possible solutions and alternatives, and that discussion leads to better software.

So next time you talk to a software person, start the conversation by describing the problem you are having in detail, and then, when they understand the problem, offer them your solution. Or better yet, walk them through your thinking to the solution with you. And listen when they offer alternatives, they do see things from another perspective. It makes for better communication, better software and much better solutions.