What we’ve got here is a failure to communicate!

If men are from Mars and women from Venus, then software development is from Andromeda and the user community is from the Milky Way.   Men and women have difficulty with communication because they are from different planets and software development and its user community can’t communicate because they are from different galaxies.

The communication gap seems to be growing larger.  Software developers tend to communicate in techno speak.   Most developers lack basic communication skills and this is one of the root causes of poor requirements.  Developers are not very skilled at asking open ended questions or how to politely probe.   They tend to ask biased questions.    Too many developers prefer computers over people.  All of this leads to poor communication.

So what should software developers do?  Funny that you ask such a question.  Developers need to learn how to

  1. Avoid using confusing jargon and acronyms
  2. Ask open ended questions
  3. Learn to politey probe
  4. Master the metaphor
  5. Avoid biased questions
  6. Focus on the benefits and solutions not the features.

Read more at Reboot! Rethinking and Restarting Software Development.


Organization makes a system of many appear fewer

Mark Twain once said, “A person that does not read books is no better off than a person who does not know how to read.”  An organization that creates chaotic documentation is no better off than an organization that does not create any documentation.  The argument could be easily made the organization is actually better off by not wasting time creating chaotic useless documentation.

On any single software project or application, there can be 100’s perhaps 1,000’s of artifacts.  The artifacts can be requirements specifications, design documents, flow charts, code, test plans, test cases, so on and so forth.  Most of these documents will reside on personal computers or stored on some shared drive.   I have worked with organizations where all “important” documents are stored on a shared drive.  The share drive was created with no standards and no subdirectories.  In other words, there is just a big pile of documents.  Within those documents there are no naming conventions, no standard glossary and no standard format. It can be nearly impossible to find information, so developers just ignore any previous written documentation and start from scratch.

I ask software development organizations to compare how they catalog and organize their documentation to how a library organizes knowledge.  I ask, “What would the local library look like if they followed a similar process for organizing documentation?”  Some people tell me the library would be empty, others tell me books would just be staked up all over the place, still others tell me some of the books would be half written and some of the books would be tucked away in librarians desks.  For too many software development organizations their documentation is not organized at all and it is chaotic at best.

The idea of classifying information and knowledge is not a new idea and has existed for several millenniums.  Classifying was one of those skills in which Aristotle excelled.  Aristotle understood information is easiest understood when it is classified and organized.    The idea of organizing and classifying is nothing new and it should not be a novel idea to software development. The bottom line humans like things organized, we have been organizing information for millenniums, and it is time software development get on board.

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.

Get Fluent in IT Speak

To get the right word in the right place is a rare achievement

– Mark Twain (American humorist, 1835 – 1910)

Years ago, I was speaking at a conference in the Ukraine and a live interpreter was translating my speech.   The members of the audience were wearing headphones, so they could hear the translation.  At the break, the interpreter came up to me with a list of words and asked me to explain the meanings.  She asked me to explain what was meant by the word, “y’all.”   I am from Texas and everyone in Texas (and the southern part of the USA) knows what “y’all” means. I explained it was slang for all of you and the plural form of “y’all” is “all y’all.”    The interpreter had a list of other words that I did not even know I used.  I was totally unaware that I used words like “fixin” or “gotta.”[i] Since I do a fair amount of public speaking in places other than the Southern USA, I have tried to eliminate slang and jargon from my vocabulary.   This has helped me become a better communicator.

Confusing Communication

One of the barriers to improving productivity and quality is poor communication.  Over the years I have carefully observed how software developers interact with each other and especially how they interact with the core business, user community and customers.   Software developers are not good at communicating with the core business or with their customers.

It is common in the software domain to have inconsistent terminology and symbol usage whether it is written documentation or actual code. Using inconsistent terminology, symbols and languages causes confusion among readers and it negatively impacts communication, productivity and quality.  Standardization of terminology goes along way to improve both productivity and quality.  Unfortunately software developers often proclaim standardization negatively impacts their creativity and it burdens projects, but nothing could be further from the truth.

Software developers, like any technician, have to communicate with each other and ultimately they have to communicate with the core business.   The choice of vocabulary and the method of communication is not the same between technical teams and with the core business.  The type of communication used to communicate with the core business should not be the same as the technical communication used by software developers.  The core business does not have the skill set to understand the technical jargon.

You should try and eliminate any jargon or technical words from your vocabulary.

[i] Fixin to go is used instead of, “I am getting ready to leave” and “I gotta go” is used instead of “I have to leave.”

Published in: on June 12, 2009 at 06:00  Leave a Comment  

The code is not the documentation!

There are a lot of reason why the code can’t be the documentation.  The first reason is obvious because most organizations and individuals have no standards in place.  As an example let’s compare sheet music with coding – shall we.

Keep in mind sheet music was not always been what it is today.  There have been several evolutions of what is known as sheet music.   A Benedictine Monk named Guido of Arezzo was the first to attempt the standardization of music notation in his book Micrologus published in 1026. The idea of sheet music has evolved over several centuries and as software evolves standardization of terms, vocabulary and symbols will be commonplace.  I hope it does not take the software industry a 1,000 plus years to standardize terminology.

There is no accepted standard for notation for software development.   By notation I mean how do we communicate about software.   Notation differs from organization to organization and even differs within an organization.    The lack of consistent standardized vocabulary, verb usage, and symbols is really unique to software development.

Any first year music student, unlike software developers, learns the symbols of music and basic music notation.  Music notation is a system of writing music so that specific pitches and rhythms can be communicated.  Music notation indicates exact pitches by the upward or downward placement of symbols called notes on a staff.  A note is an oval.  Its duration is indicated by whether it is black or white and if it has a stem and flag.  As music students progress the symbols become more complex.  While most music novices can play and understand a level one music book, it is impossible for a novice to play or even understand an advanced music composition.

Sheet music, unlike code or software documentation, is written concise and consistently. Structure in music allows the composer to communicate to musicians how the piece should be played.  It is a printed page, like a book or poem, that tells a story.  A talented, creative and imaginative person created the story.  Without consistently written sheet music it would be impossible for musicians to play the story with their instrument.   Just like structure does not inhibit the creativity of a composer, structure does not inhibit the creativity of a software developer.

Sheet music transcends language and time. Music notation gave western music a means of a written historical record.   I was working in Vienna, Austria and picked up some sheet music written by Wolfgang Amadeus Mozart  for my daughter who plays the piano.    Mozart’s lived 250 years ago and his language was German.  My daughter who is 15 years old does not speak German, but can pick up this sheet music and play it on her piano.  While the content is different the symbols are exactly the same for a contemporary piece like Linus and Lucy, the recognized Charlie Brown theme song written by Vince Guaraldi.   The same could apply to two different software functional specifications, they should be written in a consistent manner.  I do not expect a software documentation to transcend 300 years, but it should transcend the entire life of the software application.

There is nothing on sheet music, which is not necessary.  Even though sheet music varies depending on the instrument being played the symbols all have consistent meaning.  A typical piece of music contains all types of measurements, symbols and directions.  A whole note is always a whole note and a quarter note is always a quarter note. Without all of this structure and rules it would be difficult for a musician to perform a piece of music.  It would be impossible for an orchestra to come together and play as a symphony.   When documentation is written inconsistently it is hard to communicate what is desired because inconsistently written documentation inhibits communication and causes confusion. The same is true for software.   When individuals write documentation inconsistently, it is difficult for everyone to understand what was meant. Naturally this hurts productivity and quality.

While it is common for a person writing documentation for a software project to decide on how to write the documents, a composer of music does not decide to develop his own vocabulary or develop their own symbols.  The idea of music composition is an advanced mature industry.  Individuals that write music are trained to write music and they are trained to read music. There are special courses required for those musicians who write and transcribe music.  It is possible for a person to get a Masters Degree in Music Theory (M.M. Theory) or Masters in Music Composition (M.M. Composition) .  It is possible at some universities for an individual to earn a PhD. in Music Composition.  Think about it, music is so advanced in its notation individuals can obtain Master (and sometimes PhD.’s) in the composition of music.   Granted a person can earn a Masters in Software Engineering, but this is analogous to earning a Masters in Music.  A Masters of Software Engineering is a generalist degree.  The required course work to earn a Masters of Software Engineering varies from university to university.   Even the term software engineer is vague.  Typically a software engineer encompasses everything from a programmer, software architect, software designer,  and manager.

In Mozart’s day music was hand copied by an apprentice because there was no such thing as a copy machine. This was one of the problems with printing and reproducing sheet music because sheet music requires special symbols which are not part of everyday language.   Printers who printed sheet music had to have the capability for music engraving.   These printers had special characters not typically used in everyday life.  Today, scorewritter software contains all the necessary symbols for a composer to write music.   If a software organization decides to use symbols to communicate then it is important to be able to type those symbols.

Since there are no standards for coding like sheet music, the code cannot be the documentation.
Published in: on June 12, 2009 at 01:01  Comments (1)  

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: ,

Are software developers like the janitorial staff?

I think everyone remembers being a kid at the big Thanksgiving or some other family get together.   It is pretty common for the adults to sit at one table and the kids to sit at another table.   I always wanted to sit at the table with the adults, but my grandmother told me I could sit at the adult table only if I acted like one.

The following video was put together by a young film maker named Jordan Kerfeld.

Today the business is at the big table and software development is at the kids table.  When software developers have no desire to learn about the business and especially when your team has no desire to learn about the business, then why would the business ever invite you to be part of the business.

Software development is the only industry we have where workers move from industry to industry. It is time software developers learn and study the core business.

Read More at Reboot! Rethinking and Restarting Software Development.

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