1 Comment

Mysteries and Puzzles

I was recently introduced to the writings of Dr. Gregory F. Treverton. Treverton is currently a RAND analyst and previously a high-ranking US intelligence official. In his book Reshaping National Intelligence for an Age of Information Treverton made the distinction between mysteries and puzzles. Dr. Treverton offers that puzzles are questions with answers – for instance, how many nuclear missiles a nation possesses. Mysteries are those questions for which there are no answers – for example, whether a particular country will take military action against another. Puzzles involve facts and data. Mysteries involve judgment, analysis, and interpretation.

This distinction between Mysteries and Puzzles encapsulates something essential about the nature of software.

It seems that software development is consistently seen only as a puzzle. This pervades both the business aspects of software and the technical aspects. The business mind tends to think that a software project and its business model can be figured out all upfront. Put enough thought into it and do enough fact gathering, and the puzzle of the software application will be solved. Technical people often fall into a similar trap. Pick the “right” process and pick the “right” technology, and the puzzle of how to deliver the software application is solved. And, yet, there is continual puzzlement (pun intended) by the serious quality problems in software, the failure of projects, and the befuddlement of customers who can’t understand that what they were delivered is not what they needed.

To be sure, there are puzzles involved in software. There are times when progress towards the end business objective is held up by the lack of certain facts. Once gathered, the process continues. Certain technical decisions are also puzzles. Trying small experiments or reading up on certain algorithms can solve these puzzles.

Looking at the whole of software as a mystery is perhaps the useful and important construct here. Needs change. Opportunities come and go while a project is in midstream. Feedback while a system is under development will impact what requirements are implemented, changed, or omitted. What the market wants and needs and is willing to pay for is unknown. How best to implement software under changing conditions and with available (possibly changing) financial and human resources is a very tricky problem. All these things involve open questions with great risks. It requires analysis, interpretation, and judgment to envision a software product or service, to implement it, to manage its changing requirements and risks, and to bring it to financial success.

Isn’t it interesting that when software projects fail the failure is often even seen as a puzzle. Developers and managers investigate, find the apparent missing piece, and make sure that that piece is included next time (creating an ever more heavyweight and ineffective process). It’s a cycle of puzzles – a puzzle to start, a puzzle to determine the failure, and a puzzle when starting anew. All too often puzzlement remains and failure propagates.

Perhaps software is best seen as a mystery enveloping a collection of puzzles. It is the mystery, however, that is often missed for what it is. Those puzzles that do exist attract all the attention while the larger mystery is misperceived to also be a puzzle. Software requires smart, capable people who can engage the art and science of analysis, risk management, and prediction. The mystery inherent to software requires difficult decisions and creative thinking from start to finish.

The ideas of Mysteries and Puzzles seem quite powerful and are likely notions we’re going to explore and develop further.