Curious v. Too Damn Smart

I have witnessed a lot of requirements gathering sessions over the years.  Too often the software developer takes the opportunity to demonstrate to the “user community” just how damn smart he or she happens to be.    The developer tends to ask complex questions and then rolls his or her eyes because the user just does not know what they want.

I am often shocked how little homework the developer has done before the requirements meeting.  It is pretty common for the developer to show up and not have any prepared questions.  Instead they ask the question, “tell me what you want?”  The developer needs to spend time studying the business.  They also need to distinguish between features of a software application and the benefits of a software application.   Developers tend to gravitate to features and ignore the benefits.

The user should be doing most of the talking not the developer during the requirements process.  A good rule of thumb is the 80/20 rule.  The developer should be talking about 20 percent of the time and the user should be talking about 80 percent of the time.  The developer needs to keep the user talking by asking open ended questions.

A developer should be skilled at creating functional decompositions of features that map directly to the benefits.   The developer needs to keep asking the question, “why does my user care about this feature?”  The purpose of a software application is to benefit the user and to help them do his or her job.


Brunelleschi’s Dome

In the late 1200’s it was decided that Florence needed a cathedral that would rival the cathedrals of London and Milan.  The original planners had envisioned a cathedral with a dome that would be the largest dome ever constructed.  They decided to move forward with the construction even though the designers were not certain how the actual dome would be constructed.

Brunelleschi's Dome

Brunelleschi's Dome

For nearly a century it was obvious that no one in Florence or anywhere for that matter had any clear idea how to construct the dome.   All attempts to build the dome had failed and the cathedral was domeless.  While the intent of the dome was going to represent civic pride it instead was a constant reminder of failure and embarrassment.   The story does not end here.

The original planners had been overly ambitious.  All contemporary building knowledge had been exhausted.  The man that would eventually design and oversee the construction of the dome was named Filippo Brunelleschi.    Brunelleschi believed the secret of the dome was not in contemporary knowledge but held in the past.  He would resurrect forgotten concepts by studying the ancient architecture of Rome especially the Pantheon.  He spent over a year studying the Pantheon and it eventually gave up its architectural secrets and he had his solution.   He designed and constructed the largest unsupported dome in Christendom. The dome is an architectural achievement that architects still marvel at today.

Sponsors of software projects can be overly ambitious too.  One of the problems with iterative development such as Agile is it is based upon design as you go. One of the problems with designing as you go is the probability of creating undesirable constraints. Brunelleschi knew he could not tear down what had already been built.   He could not start from scratch.   The outer walls of the cathedral had already been constructed and this dictated the size and shape of the dome.  The same thing happens in software development where previously written code and design constrain all future solutions.

The requirements of the project need to be outlined and the technical solution needs to be understood.  The degree of understanding needs to be in proportion to the importance of the problem.  It was not a good idea to start construction of the cathedral without a clear understanding of how the dome would be constructed.   Lucky for inhabitants of Florence and everyone who has visited the city that Brunelleschi appeared on the scene.

Brunelleschi documented his project in secret code he only understood to maintain controlPlans over the project. He even refused to explain the details of his plan to the project sponsors. They had no choice but to tolerate Brunelleschi’s difficult and uncompromising behavior.   He documented the project without any intention of communicating, so clearly the reason he documented the project was because it was too complicated for him to do all the analysis in his head.

Brunelleschi’s Dome: How a Renaissance Genius Reinvented Architecture (Paperback)

Better Software Requirements

Over the next few weeks I am going to write about how to improve software  requirements.    Most software organization cannot get requirements right.   It is not uncommon for software requirements to grow two to three times throughout the software life-cycle.  I argue that software requirements is the largest unresolved issue facing the software industry.

There have been many software methodologies that have attempted to resolve the requirements problem, but none are long lasting.  Agile methodology recognizes the problem of poor requirements but fails to provide the right solution.  As one Agilista wrote me, “Extreme helping the customer figure out what they want is not part of Agile.”

The role of the software developer needs to be  helping customers define what they want in a software application.  Most software organizations skip this step. Customer often cannot define what they want because they lack the basic vocabulary to do so.  The software developer needs to develop the skills of asking the right questions.

Imagine a customer who wants to buy a computer being asked the question, “What processor speed do you want?”  Now compare and contrast that with the question, “What do you do with your computer?”  A better question is, “What would you like to do with your computer?”  The processor speed depends on what the customer wants to do with his or her computer.  The customer does not know the answer to, “What processor speed do you want?”

The root cause of requirements growth is a lack of understanding of the business problem that needs to be addressed.  The problem is those tasked with creating software rely on customers to articulate what is needed. To often customers  cannot articulate their needs because they do not have the basic vocabulary to do so.   Customers  may  lack the vocabulary to explain what’s wrong and especially what is missing.

Sometimes what people say they do is not what they really do, and what they say they need to do their jobs is not what they really use (artifacts). It is important for the software developer to determine what is really needed and not rely on customers  to tell them what is needed.

Developers need to develop the skill of probing and asking the right questions, and then they need to offer a solution based upon the answers.  Over the next few weeks, I am going to write on this topic, so stay tuned.
Published in: on May 25, 2009 at 01:01  Leave a Comment  
Tags: ,

WIFM is everyone’s favorite radio station.

Everyone’s favorite radio station is WIFM, or, “what’s in it for me.”  I was consulting with a company that develops software for the property casualty insurance industry.  During one of my consulting engagements, I encouraged a group of developers to learn about the insurance industry.   Yeah, that is right.  I encouraged them to learn about the core business.  What a crazy idea!  A couple these developers discovered there are numerous journals, magazines, organizations, and conferences dedicated to just the property causality insurance industry.  By the way, I have learned over the years every industry has its own magazines, conferences, and trade shows.

These same developers asked to go to a property causality industry trade show instead of the standard software conference.   One of the developers told me, “it was like a million light bulbs went off in my head.  I walked up to one of our competitor’s booth and watched a demo of their software products.  I thought their product was really cool, then I took a big gulp and realized our product can’t do that.”  At the conference, like many conferences, there were small group meetings.  One of the meetings was on how information technology impacts the insurance industry.  To the surprise and delight of the software developers out of the fifty or so attending the small group session, they were the only software developers.  The rest of the group was comprised of those internal clients that interface with software development.   The small group welcomed these two developers with open arms and they became the focus of small group discussion.  In the end, the software developers collected a fist full of business cards from companies offering them jobs.

Unfortunately most software developers do not subscribe to trade industry magazine, conference or trade shows that represent the core business.  Instead, they stay huddled up in their cubes blaming their users for poor requirements.  They have not figured out that their lack of knowledge regarding the core business is part of the problem of poor requirements.

Read More at Reboot! Rethinking and Restarting Software.

Got industry experience?

Often I find myself just sitting around thinking.  The other day I started searching several online job posting websites.  I was wondering if other disciplines require  knowledge  of the core business.  In my quest to figure this out I reviewed over 500 job postings for a variety of different technical disciplines including mechanical engineer, electrical engineer, chemist, and biologist.  In each case, over 90 percent of the job postings required industry domain expertise.   For example, a job posting for a mechanical engineer required 11-14 years of experience in production packaging of electronic equipment.   The same was true for chemist and nearly all chemist jobs required domain experience or knowledge of the core business.

Let me stop and review.   If you are a chemist then your future employer wants you to know about chemistry and the industry (core business).  The same is true if you are a mechanical engineer or electrical engineer.

This is in sharp contrast to software development.  When I examined job posting after job posting, almost none required any knowledge about the core business.   Out of 100 job postings for software developers that I  reviewed only 4 required industry domain knowledge.   Think about this for a second.   Poor  requirements plague the software industry.  Do ya think it has anything to do with the fact most software developers have no knowledge of the core business?  Come on folks!

One could argue that it is better to be a generalist instead of a specialist, but no other industry suffers as many project failures has software development.  No other industry frustrates end users like the software industry.  No other industry has such a problem with requirements as the software industry.

Read more at Reboot! Rethinking and Restarting Software Development

Gorillas and I.T. – Go to the jungle

Tom Kelly is an Industrial Designer for one of the most successful industrial design firms, IDEO. He writes in his book The Art of Innovation, “Your customers may lack the vocabulary to explain what’s wrong and especially what is missing.” Bingo! One has to start to ask the question, “If your customer does not know what he or she wants or cannot articulate what is wanted, then how exactly should the requirements process work?” Kelley writes, “It is common for well-meaning clients to duly inform us what a new product needs to do. They already ‘know’ how people use their products.” His firm does not rely on customers telling them about their problems. His book is full of stories recounting where customers were wrong about problems and possible solutions. His firm has learned to study customers and not rely on what they say. Kelley’s views are not unique, and his views are shared by many other industrial designers. Now if Kelley is right, and customers cannot articulate what they want, and especially what is missing, then how should the requirements process work?

Too often software development teams ask customers what do you want.  The problem is customers cannot articulate what they want.   Customers are unable to describe their own requirements.   The whole idea of gathering requirements is just wrong.

Gorillas and I.T.
Jane Goodall studied and learned about gorillas by studying them. She learned a lot from just observing and sometimes being among the gorillas. She utilized a technique known as ethnological study.  The best insights come from observation, interviews and informal conversations.

If you want to learn about your customer, then you need to go to the jungle.

The bottom line is software developers can learn a lot from industrial designers and other researchers.

Read more at Reboot! Rethinking and Restarting Software Development.

Jane Goodall Institute

Little Errors in The Beginning…

Little errors in the beginning leads to great a one in the end, St. Thomas Aquinas.

Getting software requirements wrong has a ripple effect throughout the entire software life cycle.  These little errors can be missed, incomplete or just plain wrong requirements.

Some of the little errors are the result  of not knowing what needed to be known.  These type of mistakes can be excusable as long as they do not occur over and over again.  The problem, of course, with software development is these little errors occur over and over again because software developers refuse to address their responsibility creating these little errors.  Software developers and their management team shrug their shoulders and say, “you did not tell us you wanted that.  These little errors are the result of culpable ignorance or just plain ole fashion negligence.  The root cause of of little errors in the beginning is a fundamental lack of knowledge about the core business and especially the customer.

Too many in software development rely on the customer (end user) to tell them what they want.  As Tom Kelly points out in his book, The Art of Innovation, most customers do not have the vocabulary or the ability to describe what they want.  This my friends is is the root cause of all those little errors in the beginning.  The basic fundamental assumption that customers know what they want and they will be able to articulate what they want is just plain wrong.

Until software development understands that their core business does not have the ability to articulate what they want and especially what is missing, software development will never move forward as an industry.

Read more at the free online book Reboot!  Rethinking and Restarting Software Development.  (www.RebootRethink.Com)