Software, Bugs and Enhancements. Guidelines for Success

In the 1980's engineering companies had in-house development to enhance and customize software for their needs.  As software matured and became more integrated, the in-house support could not be maintained.   Key enhancements were still needed to get a strategic advantage in business.  One small part of my job for 35 years was reporting bugs and asking for software enhancements.  It was thousands of reports in 35 years.  I averaged  50%+ of the bugs being fixed and around 30% of my enhancements being implemented. This is about 30 times the average.   Some tips are listed below. 

Some recommendations to assure you can successfully report problems.  This is derived from my experiences with hundreds of software vendors.

Software Bug and Enhancement Reporting

Complaining in a user forum, telling the salesman or even a VP about a problem will not get it solved.  Turn the request in on the customer support system.  Even small software companies have a method for reporting problems.  Find out what it is and use it.   Then keep a record or track of all the problems you report.  Check on it quarterly if it is a long term fix.   If you forget about the problem so will they. 

Complaining, name calling and insults are great ways to have your problem dismissed.  The goal is to fix a problem, not to satisfy your ego.  When writing, talking on the phone or in person remember you want people to be your helpers.  Apologize quickly when you do something stupid.  Treat people with respect and show gratitude.  Many will work hard for you once they know you are someone worth dealing with. 

Learn to apologize.  No matter how hard you try about 15% of the bugs you turn in will  be misunderstandings or user errors.  Apologize and move on.

When reporting a problem, don't write the technical details in the first part.   The first part needs to be written for a decision maker.   The decision maker often knows more about golf than software.  Give them information so they choose to fix your problem.  Explain time lost, economic and competitive impact.  Point out how it will help them to sell more!  End with an expectation that the problem will be addressed soon.  Praise them into agreement.  You want your problem on the top of the stack, not lost in the myriad of poorly presented problems.  It needs to be complete, accurate and concise.  Long reports will not be understood.

The second part needs to explain the technical details.  All of the details.  Versions of software, hardware, firmware and OS.  Steps to reproduce the problem are critical.  Provide examples whenever possible.  If support groups can not re-produce the problem, it will not be fixed.

Software is international.  Avoid cultural phrases in your communications.  The reports may be read by support people in other countries.  Language translators may be used.  Meanings of phrases like "in a pigs eye", "house a fire", "night and day" or "the moon and a snapping turtle"  confuse more than help.

Proof read what you wrote before submitting.   Read it aloud to make sure it makes sense.  Use a spell checker.  If you were angry when you wrote it, wait a day, re-read it and fix as needed. Focus on the problem, not the emotion.

What priority should your reports be?  Always high.  Demoting to anything other than high means it will not be fixed.  Don't play the rating game.

One motivating trick:  When you can show a logic error in the software, it motivates developers to fix the problem.  Many developers want to be logical, like Spock.  Something like, "A plus B is not equaling C as it should..." may work wonders.

Reports will take time.  2-4 hours per report.  If you don't want to invest the time, the problem isn't important enough to you.

Even I forget to do all the steps from time to time, but keep working at it.  Success is worth it.

Strategic vs. Tactical problem reporting

99.9%+ of customer requests are short term or tactical.   Bugs and minor enhancements.  Customer support groups are designed to handle all these tactical requests.

Companies are like a battleship with a charted course.  A strategic change is often a course change and it is not easy to get the captain to change course.  You must overcome the blindness the charted course induces and the lack of understanding of management.

Companies that support cooperative development and round table discussions do much better with strategic recommendations than companies that leave customers out of planning.

Strategic requests need careful consideration and support from your upper management.  Strategic requests need data, examples, pictures, charts, studies or anything else you can come up with to convince the developers of the needs.  This will take more than one paragraph.  Be careful, too much text and it wont be read.  Get your writing and presentation skills in order.  Getting a strategic change takes time, patience and a firm resolve.

The difference between Strategic and Tactical

My friend was a designer in the early days of computer gaming.  They would get thousands of requests a week.  More arrows, change the maze or add a new level, all tactical.  None of the requests told them what the next big thing in gaming should be. 

The strategic change came from an argument.   The developers argued about who was best at playing the new game.  One took it so seriously he worked all night to add a network interface.  This allowed 2 or more players to play each other in the game.   They had so much fun playing it they put it in the official release a few weeks later. It was a strategic change that lead to the online gaming community we see today.  It seems like a simple thing today, but it was a revolution in the early 1990's.  It was something that had not been requested at the time. 

Switching Software

Sometimes the only way to fix a problem is to switch software vendors.  What I believe are the signs that a software company may not be a good strategic choice.

• Lying.  This happens in many forms, but the worst is when the software sales tells a customer their users are inept or should be fired.  A sure sign to me they are covering many of their own problems.   This is often followed by sales going up the management ladder to find the manager that believes the lies.
• Software demonstrations that can not be altered.  If they promise and cannot show it, be warned.   Ask questions, change the demonstration.  You need to see the software do it, not be told it will.
• Poor quality.  No matter how advanced it is supposed to be, what doesn't work is useless.  It is very costly to the users.
• Poor service, customer support and resistance to customer feedback.
• Software companies employees have little to no experience in the field they are supporting.
• Long development cycles.   In the 1980's 18 months to 2 year development cycles were normal.  That often meant 18 months to 3 years before the customer touched the software.  As one developer stated, "it was obsolete before the customer got it".  Today more, short development iterations and working with customers to guide the development is key.
• Wordy claims that obscure the function.  I once read a 2 page report claiming the software was intelligent manufacturing.  Once I removed the adjectives, repetitive statements and catch phrases it ended up being one sentence.  It was a speed and feed table for machining.  Nothing new and no where worth the asking price.

  last updated July 15, 2023