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.

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 Agile Wedding!

My son is getting married  this weekend and I suggested the entire wedding should be Agile.  That means there is limited planning up front because the bride does not really know what she wants and she keeps changing her mind.  The  wedding and reception does not have to be delivered all at once because it could be delivered in iterations.  If it works for software development then it should work for other things, too.

On the other hand they could take some simple advice from wedding planners.

1. Before going completely into debt for your wedding, create a budget.

2. Allow plenty of time to plan; the more rushed you are the more money you’ll spend.

Perhaps it is a better idea that software developers take some advice from wedding planners instead.

Published in: on May 28, 2009 at 01:01  Comments (1)  
Tags: ,

I manage *$#%! programmers

A friend of mine sent me the following cartoon.    It reinforced what a software manager told me,  “I don’t manage programmers, I manage freakin prima donnas!!”  He was discussing his trials and tribulations of managing a technical team.  A prima donna is the first lady of the opera.  Prima donna’s are egotistical, unreasonable, and they have a high opinion of themselves.   The term is used to describe a vain, obnoxious and temperamental person who, although irritating, cannot be done without.  Sound familiar?


The perfect lawnmower

It is summertime and I need a new lawnmower.   Lucky for me a friend of mine named Bob is selling lawnmowers.  Bob use to be a software developer who specialized in gathering requirements and became an advocate for Agile Software Development.   I felt bad for Bob because he was recently laid off  from Megatelecommunications  Company With Way Way Too Many Employees, INC.

I went to the the lawnmower shop where my friend was working and met up “Bob.” After the obligatory greeting of “hey, how’s it going,” “how is so and so,” and “who is working here and there,” we got right down to business.  Bob said, “How much horsepower do you want?”  I thought, “What is horsepower and how does that relate to cutting grass.?” so I responded, “What are my choices?” Bob said, “2, 5, 6, and 7.”   I stood and kind of stared at Bob and he said, “David, if you can’t tell me how much horsepower you need, then I can’t really help you.”  I figured that more was better so I responded, “7.”  Bob said, “Good choice!”  I started feeling better.

“The next thing you need to tell me is how big you want the cut diameter.”  I said, “cut diameter?” Bob rolled his eyes and said in a condescending  manner, ” Yeah. the cut diameter.”   Bob said, “Your choices are 20, 21, or 22 inches.”  This time I choose a number in the middle and said, “21 inches.”  He chuckled and said, “You can’t get a 7 horsepower with a 21 inch cut diameter.”

Bob asked, “How many speeds three, six or variable speed?”  I asked, “What do you recommend, Bob.”  Bob quipped back, “You have not done your homework have you?”  He continued on and started lecturing me and said, “David this not hard.  You need to go home and start doing your research.  There are plenty of online resources.  When you have figured out what you need come back and talk to me.”  I felt a bit stupid and  left the lawnmower shop.

I was driving home and noticed another lawnmower shop and thought I would pull in and do a bit of research.  As I walked in a nice man greeted me with a big friendly, “Howdy! I’m John what brings you in today.”  I said, “I am looking for a lawnmower and I need to do some research.”

John said, “Can I ask you some questions?”


He asked, “How big is your yard?”  and I responded, “Oh about 3/4 of an acre.”

“Do you like to cut your grass?”

“I hate it.”

“Are you trying to get some exercise when you cut your grass?”

I looked at John in a sort of curious manner and he said, “The reason I am asking these questions is to figure out your needs.  If you want to get some exercise while you cut your grass then you may need a push mower.  If on the other hand you just want to get it over with as fast as possible you may  need a riding mower.”

I nodded and said, “Oh, okay.”

John kept asking questions like, “Will your wife and kids use the mower or will it  be just you.”  After sometime and a bunch of questions John smiled and said, “Let me make some recommendations for you based upon your specific needs.”  He walked me over to a mower and explained to me how it would benefit me.  I thought this guy knows his stuff.

I was really excited and purchased the mower from John.  Then I thought about Bob.  I thought, “I never really liked that guy.”

Published in: on May 20, 2009 at 01:01  Comments (1)  
Tags: ,

May the Force Be With You

I don’t know why I waste my time teaching statistics and quantitative methods when I could be teaching people how to use the force instead.  Do you remember how Obi-Wan Kenobi (Ben), teaches young Skywalker how to use the force?  Luke is training against some type of floating ball.  Of course Luke can’t hit the small beams coming at him from inside the floating ball.    Obi-Wan blindfolds young Luke with a helmet and says, “act on instincts.” Obi-Wan encourages Luke to ignore his eyes. Once Luke is blindfolded and uses the force he is able to hit all the small beams coming at him. In software development we call act on instincts expert opinion.  It seems like software developers use the force.

Too often when  someone  is asked, “How did you come up with your estimate?” they reply, “expert opinion.”  They are acting on instincts instead of using quantitative analysis.  Don’t get me wrong often instincts can give you insight into estimates and understanding projects status, but it should not be a substitute for quantitative methods.

The best part of the movie Star Wars Episode IV is when Luke is making his final approach to destroy the Death Star.   He is flying at a couple times the speed of sound and he has to hit a small target which is about one foot by one foot.   Time is running out and all the other attempts have failed to destroy the Death Star.   Luke hears the voice from the other side (Obi-Wan), the voice says, “Use the Force Luke.”  Luke looks around and thinks about it and the voice tells him, “Luke trust me,” so Luke turns off all the quantitative instruments.  Of course, Luke launches his rockets guided only by instinct and they are right on the mark and the Death Star is destroyed.  My advice is when creating an estimate, or when asked about project status it is best to let the force guide you.  When asked how you came up with your estimate simply respond, “The force was with me” and refer them to the Star War movies or this blog.

Just imagine how your next performance review could be worded.  In the Stars Wars movie Darth Vador says about Luke, “The force is strong with this one.”  Now wouldn’t it be great if your boss would write that about you.  That is something you could put on your resume.

Read more at Reboot! Restarting and Rethinking Software Development.

I want be an average software developer

Several years ago my sister called to tell me about my niece.  My niece, who was in 2nd grade, had taken some standardized tests and  she scored average.  My sister was distraught.  I tried to explain there is nothing wrong with average.  Average means there are 50 percent of the below.  Yes, my sister responded, “but it always means there are 50% above too.”

I am surprised at the number of people who write me asking what is the average productivity rate of software development.  The average productivity rate happens to be 42.  It is if they want to strive for the numerical average.  They are asking, “We know we are not very good, so we want to become average.”  These same organizations benchmark against average software organizations instead of best in class organizations.

The other day when I left my house to catch a flight my wife kissed me good bye and said, “Have an average trip.”   No she did not really say that.  She said, “Have a great trip!”  Software development organizations should strive to become great not average.   The leaders of software organizations need to understand what are the specific things best in class organizations do.  They need to be asking the question, “What are those specific things they do that are different from average and especially worst in class software development organizations?”

My niece recently graduated from Marquette University with honors and will be attending dental school.  It turns out she is above average after all.

Have an average weekend!

Read more at Reboot! Rethinking and Restarting Software Development

7 Deadly Sins of Software Development

A few years ago, I was asked to present a paper at a software conference in Manchester England on Best Practices.    I thought it would be more interesting to present the 7 worst practices of software developers.  Later on I decided to call these worst practices the 7 Deadly Sins of Software Development.

The Seven Deadly Sins of Software Development

1. Estimating with no historical data (a.k.a. just making stuff up).

2. Failure to monitor and report status

3. Creating analysis documentation after coding (The point of analysis is to do analysis).

4. Excessive and irrational schedule pressures (closely related to #1).

5. Failure to understand the business (the client does not know what they want and neither do you).

6. Reduce testing time to make a schedule (my personal favorite)

7. Treating your clients like they were ignorant/stupid.

So do you recognize any of the  deadly sins?  This could be like one of those surveys in a teen magazine. If you answered yes to more than 3 of the items then we can safely conclude you are not world class.  If you answered yes to all 7 items, then we can conclude your organization is worst in class.

If your organization is committing any of the above sins, then it should stop.  It is a pretty safe bet that if a person smokes they are not a world class athlete.    If your software organization does not estimate based upon historical performance, then it is a safe bet your organization is not world class.

Read More at Reboot! Rethinking and Restarting Software Development

42! Again.

My mobile phone rings, so I give a typical, “hello, this is David Longstreet.” There is no “good morning, my name is…, how are you,” but the voice gets right to the point. The voice on the other end asks, “What is the average cost of software development?” Without hesitation I respond,”42!”

There is a long pause and the voice asks, “42 what?”

I say, “42 whatever you want, you fill in the units.”

The voice, “What do you mean?”

I respond, “42 hours, 42, 000 dollars, 4,200 euros, 42 million whatever works best for you.”  I did not have the heart to tell them there is no such thing as the average cost to develop software. 

The voice, “Wow, I like this. I think I will go with 42,000 hours.”

I say, “Sounds good to me.” There is a long pause, so I assume the voice is thinking.

The voice asks, “how many software developers?”

Quickly I respond, “42.”  I decided not to point out that software developers have a lot of different roles on a software project. 

The voice, “How many months?”

In a rapid fire fashion I say, “42”

The voices says, “42,000 hours, 42 people, 42 months.”

I say, “I think you got it!”

The voice says, “I really want to thank you for helping me out on this.”

I gleefully respond, “No problem.”

The voice just hangs up. There is no typical good bye, just silence on the other end of the phone. I think to myself, “42, it is really the answer to all the questions of the universe.”