Simple Lessons Learned in Software Development and Support

As an industrial engineer in IT and having completed more than a dozen Six Sigma projects in IT, I’ve learned a few simple lessons through a decade of software development and software support.

What should you consider before adding that new software feature? What new functions take priority when you have limited time or resources? What should you do to maximize the odds of a successful software migration or upgrade?

This simple "lessons learned" list will make your software development and support functions run more smoothly.

Your software doesn't have to do everything. In fact, it can’t. You can't include every function everyone wants in the product, and you shouldn’t try to because complexity increases the odds of missed defects.

There will be someone upset that the software doesn't include a pet function they've petitioned for. Don't let their continual crusade lead to new defect reports and software changes associated with the new release, regardless of the cost or value added. The primary goal should be ensuring that the software app does what it needs to do and does it well.

Focus on improving and - if necessary - fixing core functions over adding bells and whistles or debugging a new, cool feature that isn't mission critical. For example, a financial app with interfaces to a rarely used niche tool and poor reporting both in need fixing should have the reporting fixed first. A cool new feature is less important than the functionality that is critical to its users.

Do you want to improve your software? Consider reviewing the use of various functions and whether rarely used ones could be removed. Simpler is usually better, and the application will run faster if there is less code to run while development is sped up by removing functions.

Research alternatives before creating a brand new report on top of the long list of reports your application or website already has. Instead of creating niche, rarely used reports, can the same data summary be generated with an Excel Macro or report within MS Access from reports already created by your tool? Use existing resources before you create a new report.

First do what your customers would like to see, not what the programmers think would be cool to do. For example, don't recode your app in the latest hot programming language if it works fine as is. You don't have to make everything web based, and it might not be a good idea to do so due to security concerns.

Check in with your customer base when setting priorities. While security patches and software changes to keep up with operating system changes are important, don’t forget to poll the user community to determine what their most important fixes would be. This should be like asking your customers for their definition of ease of use before you change the user interface.

Focus on the value of new features you gain with the software migration or software release, not the quantity of new features. When setting the priorities of which features or functions to include in a release, give top priority to those features that are most valuable or value added from a customer’s point of view. To paraphrase from “Rework” by Jason Fried, customers aren’t going measure your product on the quantity of new features but how well those features make it easier to do their jobs.

Balance between racing to put out fires during a software migration and troubleshooting moderately severe issues. The mid-level problems may be signs of bigger problems, and throwing everyone at a burning platform means that smaller fires will grow larger until they are resolved.

Limit the changes made during a software migration or new release. For example, avoid migrating your existing database to another Oracle version while migrating to another software application. Complexity in the form of simultaneous migrations or two subsequent migrations increases the odds of failure.

Resist the temptation to classify new software bugs as future enhancements before or after a software migration. If people think it should work, it looks like a bug, acts like a bug and may result in bug reports. If it doesn't work, don't make it available to customers.

Have at least one application developer on hand during the software upgrade to handle problems that may arise during the migration.

Ensure that application developers are available in the first week or two after a software roll-out or upgrade to fix problems as they are discovered.

Assuming you can fix any problems that arise on the first day or two of a software release or migration usually goes badly. Why is it a bad idea to rely on fixing software right after it has been rolled out?

1.This reasoning increases the odds you'll go forward without adequate testing, making problems more likely.

2. This reasoning shortchanges customers who receive inferior product, while hurting your product's reputation.

3. It is easier to delay a software upgrade to review potential concerns than go live while hoping that it works. When you delay a release, you can give yourself the time needed to fix the problems you think you have. And these are in addition to the unknown bugs that often do arise after a software roll-out.

4. Your team may be swamped troubleshooting compatibility problems and installation problems after the software release, and thus not have time to fix newly discovered bugs among the standard user tickets.