Get your eyes off the bottom line

Dollar signs Bottom line only goals create software glitches says Colin Armitage, CEO of Original Software.

Software reliability is a critical business issue that impacts market share, customer loyalty, privacy, security - all of which eventually hit the bottom line. Unfortunately, the industry's track record for reliable applications is dismal. Glitches, bugs, flaws.... we've all witnessed the pain, productivity losses and frustration caused by them. So why does this continue?

To stay competitive, management rush new applications and services into the market or demand legacy applications be forced into uses not originally architected for. IT departments are not given the proper freedoms to adequately adjust (i.e. money, staff, resources). Result: virtual duct tape, bubble gum and a 'patch mentality'. This is wrong and companies will pay the price; short term or long term it will catch up to them.

The industry has mistakenly invested in a 'patch mentality' as a short-term solution to stay competitive and line up with the constant demand for better tools. The development team takes the responsibility (often the blame) for failure at any point in this chain.

This is also wrong and management who accept this do a great disservice to their companies. IT and development teams increasingly react to management-driven goals and pressures, with dwindling resources to do the job properly.

As the CEO of my own company, I appreciate that market pressures are a healthy part of business, in fact crucial to survival. However rushing to adapt to these pressures without making sure the house is in order is a mistake.

Software applications dominate our lives. Email, digital cable, ATM and credit transactions, stock market, business systems, even your car's diagnostics system that generates the WARNING lights... all are susceptible to software glitches. Faulty software can cause major headaches and business problems as we demand they do more.

For example, moving backend systems, processes and closed-loop applications forward to rest on the web has a massive impact on business flexibility, adaptability and profitability.

Until, that is, the impact of all the cost cutting and time-to-market reduction reveals your new applications are as porous as Swiss cheese and your customer base walks away or, worse, explores taking legal action.

Management from the top down needs to take a hard look at how to streamline product development. Yes efficiencies are gained by cutting development cycles, staff and manipulating testing practices, but these changes must be counterbalanced by solid processes and innovative decision making.

Every development cycle is as unique as the intended application. Focusing on development frameworks such as the Software Testing Maturity Model (S-TMM) is a good start for management concerned with adjusting their development cycles without a complete overhaul as suggested by other models.

The S-TMM lays out a self-assessment plan and offers strategic adjustments companies can make to increase efficiencies gradually while removing underperforming practices. In brief, the S-TMM identifies five levels of testing 'maturity' that most companies fit into. Level one typically equates to mayhem, while level five represents streamlined, well-oiled testing practices.

Agile software development practices have been all the rage recently and provide management with the clearest pathway from concept to profit with minimal glitches. In part, the process of planning, mapping and developing 'chunks' of an application allows the test vetting process more time to be completed. This is due to the emphasis on test-driven development (TDD).

By clearly mapping out an entire product then breaking it down into marketable 'mini-products', revenue generation can start much quicker by periodically releasing the chunks as individual products or modules without holding the entire release up for months or even years.

This process allows development and QA teams more time with each 'mini-product' versus testing the same set of functions as a subset of one big product. I've found this is an effective strategy.

Management needs to listen to the development teams and pay attention to their needs. Adopting either the S-TMM or agile software development processes is not quick and easy, but will pay off. Before making the decision to adopt a system like these or any other, make sure your team isn't crushed by the weight of the shift.

Ask them the hard questions related to process, practice and methodology. Do they have the ability (i.e. time, resource, knowledge) to design testing practices into development cycles? Can they handle the shortened testing cycles with current staff?

Are the various application life cycle management, testing and project management tools a good fit for their current operations and what would it take to move to a position were these tools would speed the time-to-market? What's the best model for your particular outsourcing structure?

When profits are up, glitches and their impact are easy to overlook, however what happens when the competition releases a more stable plug-and-play alternative and revenues start to dwindle? What's the impact of a faulty customer service application, or the liability of a failed business application or leak of your customer’s confidential data?

Check out the testing nightmares at to see some real world examples. The industry needs to take a hard look at the importance of proper software testing and acknowledge the business, even liability, issues poor testing processes can reek on a company's reputation, services and bottom line.

Colin Armitage is the founder and CEO of The Original Software Group.

July 2007