What’s the real problem?

October 12, 2012

How often we try to solve a problem in the terms first presented to us.  Occasionally this works.  But very often the statement of the problem is self-limiting, and tends to steer us away from finding a real solution.  Or — and this is just as problematic — we may re–phrase a problem in limiting and perhaps misleading terms.

Not long ago I changed the e-mail address at which I receive notices from what had been a very active mailing list.  Instantly, I noticed that incoming mail from that list had stopped.  What was going on?  Was there a spam filter?  I realized that I’d changed the list settings before creating my new email account.  Had the list sent mail to the momentarily non-existent email address, and then turned me off?  What other scenarios could lead to such an email blockage.  I worked diligently on this problem, sought the assistance of the list owner and of several list participants, but got nowhere.  A whole weekend went by, but no solution appeared.

And then the email I wanted started to flow.  It turned out that this once-active list had experienced a significant decline in traffic, and there had been absolutely no messages during the whole weekend.  Come Monday there was a trickle of emails on the list — and they all came through to me just as they were supposed to.

In fact I had originally seen the problem as, “No emails coming through”.  But then I had quickly rephrased it into a question that I thought would be more helpful — “What is blocking my emails?”  And holding on to that paradigm had blinded me to the very simple solution — “There were no emails for anybody”.

Recently a colleague shared with me her concerns about the board of the small nonprofit that she directs.  We immediately began talking about various training programs or board retreats that might make the board a more functional support for this nonprofit and for its director.  It felt appropriate for us to talk about the possible agenda for such training, whether it should be for all board members or just those on the executive committee, etc.  Our unspoken paradigm was that the board didn’t understand its best role, and so wasn’t behaving in the most productive manner.  Bring about the required understanding or attitude and the problem would be fixed, we believed.

It took quite a while for us to step back and reformulate the problem, into the simple statement, that “The board is not serving the role needed by the organization and its director”.  And with this understanding we could ask whether, in fact, the right people were serving on the board, whether the personal benefits they sought from board service were consistent with the organization’s situation, and whether there were any positive models of board service within the board’s recent history.  Board training (in the conventional sense) remained one possible option, but not the only option.

Another organization that I’ve worked with found that they weren’t taken seriously when seeking large contributions.  They struggled to produce clearer descriptions of their programs, that they were sure would excite potential major donors.  The new materials were better, and did attract more small donations.  But they didn’t solve the problem — major donors were still holding back.  It turned out that the public financial statements were unclear and inadequate. This didn’t bother small contributors, but were a real concern to major donors.  A new treasurer was able to produce much clearer financial reports, and larger contributions began to flow.

In each of these cases the relevant people heard a statement of the visible problem, but made assumptions as they translated it into a limiting reformulation.  Letting go of those assumptions and asking anew what was the real problem turned out to be the key.

The moral here is simple:  Our first question should always be, “What is the problem?”.  And we need to answer that in the most primitive way, trying to state the problem as seen or experienced, rather than as transformed by some suggestive but often inaccurate assumptions or deductions.

Advertisements

This was written in 2002.  I’m amazed to find how relevant it is today — even with all the changes that have taken place.

I help design computer systems for business applications, and so you might expect me to extol the virtues of computer systems in this column.  But — quite the contrary — I offer here my observations on the overuse of computers, on the danger of excessive reliance on this technology, and on the need for creative vision.

To many of my clients, and would be clients, I am, of course, a priest of this technology.  Clients bow to me, expecting that my knowledge of computer technology uniquely qualifies me to design a role for computers in their organizations.  I remember one client in Holland begging me for a “great purchasing system” to compliment the scheduling tool I had given his organization.  But when I asked him what problems this system should solve, he was mute.  He could not tell me whether the critical problem was vendor selection, quality control, scheduling full truck loads, lead time, or what.  And yet, without me, he was running the purchasing department, and must have been sensitive to such issues and knowledgeable about which were in control and which were not.

Read the rest of this entry »

My tolerance for complexity — in all things — seems to be decreasing with age. And I don’t believe it’s the onset of dementia. Quite the contrary, I attribute it to wisdom gained with considerable experience

Brian Kernighan, one of the authors of the ‘Unix’ computer language, wrote:

Debugging is twice as hard as writing a program in the first place. So if you’re as clever as you can be when you write it, how will you ever debug it?

Computer programs always have some degree and complexity, and usually are not exactly correct.  They are born with “bugs”, and the task of debugging is about finding those flaws of logic that lead to wrong behavior in certain — perhaps unusual — cases.  If the program is written in a clear straightforward manner, with visible structure, and an appropriate number of explanatory comments, the debugging process will be much easier.  But if the program is written with clever tricks — perhaps taking advantage of some esoteric facts about the number system — debugging will be difficult or, as Kernighan suggests, impossible.

I used to travel widely, delivering to computer programmer audiences a talk entitled “On being lazy, absent minded, and a great system developer”.  I explained that being lazy meant that once I’d developed some code that worked, I’d take time to document it carefully, and package it so that it could be re-used in other larger programs in a natural way.  Thus I would do something well, once.  Being absent minded meant that I’d often lose track of where I was in the coding or development process.  To compensate, I’d have to write a plan first, and document any changes to that plan as I proceeded.

With these definitions, all the developers and analysts in my audiences could affirm that my qualities of laziness and absent-mindedness — as I compensated for them — were excellent qualities!  In fact, what I’d spelled out are two best practices for writing code.  A program consisting largely of well written and already debugged small sub-programs will almost always be more reliable than one written as a new mass of virgin code, and intelligent comments are an important compliment to the code itself.

I asked my audiences for a show of hands, how many spent much or most of their time debugging or updating other people’s code.  Most raised their hands.  Then I  asked how many found that code to be unclear, unstructured, hard to read, and difficult to  modify in a safe reliable fashion.  Again, most hands went up.  Finally, I asked how many were rewarded in their performance review for writing such high quality code — instead of just for writing lots of lines of code that seemed to work.  This time the hands stayed down.

Evidently, although we recognize that complexity is almost unmanageable, we’re too often unwilling to invest in simplicity.  And simplicity is the product of good design.  I believe that the underlying issue is our reluctance to understand the importance of design.

I’ll have more to say about this in future posts on this blog.