Make the Support – Software Connection
by Henry Goettler and Kristine Vallila
     

Imagine one of your favorite support engineers, let’s call him Gerhard, came up with a wish list for your software company’s R&D department. That list would likely be driven by the general tasks of the two main deliverables of software support: software maintenance and support service.

In this case, software maintenance includes all goods that help keep the software up to standard. This includes all patches, updates, and upgrades for the software. Support service would include all help customers can receive from your support department when help is needed with the usage of the software or in the case of concrete technical problems.

Of course, helping customers with technical problems wouldn’t involve bug fixing if a company delivered bug-free software -- but bug-free software doesn’t exist. Alfred Aho, professor of computer science at Columbia, provides an estimate on errors in software that shows that we should pursue proactive support and avoid errors, but must not forget the reality of null pointers and JDBC-errors (Gerhard certainly does not!)

In addition, most of the application environments aren’t frozen, but are constantly changing. Small changes here, a hot fix there, some minor updates for the operating system, additional functionality for the database, and on it goes. Then your application needs an update or upgrade and has to fit into the changing environment.

To deliver excellent software support, you need excellent software. The quality of the software has a tremendous impact on the level of quality you can deliver in customer support. So let’s have a look at what Gerhard learned about the software quality requirements when he met with R&D.

Software quality criteria

ISO9126 provides a good overview of the six building blocks of software quality. We fed those criteria to our Quality Sixtopus (figure 1).

Figure 1: Software quality criteria according to the Quality Sixtopus (and ISO 9126)

Every one of the six tentacles also has a set of sub-criteria. Table 1 shows the sub-criteria presented with a differentiation between proactive support and reactive support. The distinction made between proactive and reactive support doesn’t exactly reflect the difference between the two main support deliverables but proactive support is more strongly linked (though not restricted) to software maintenance, whereas reactive support has a lot to do with direct troubleshooting.

Table 1: The sub-criteria for ISO 9126’s building blocks for software quality.

Gerhard’s company has a high quality commitment and the development of software is governed by quality guidelines. When Gerhard talked with his R&D department, he found out that the quality requirements for R&D and customer support were nearly the same. This is not a big surprise - one group builds software, the other fixes the software for the same customers.

With so many characteristics to deal with, Gerhard decided to prioritize them and address his top three criteria first.

• There’s nothing worse for a support engineer than digging into a customer’s problem and finding a nice little black box into which he cannot look. Being the investigator he is, Gerhard prefers systems that he can analyze by using logical measures, tests, and software tools to identify and solve the problem rather than hovering over his Hungarian grandmother’s crystal ball for a hint at the solution. To be able to analyze customer problems Gerhard and his colleagues need access to the system’s processes and be able to observe the system’s behavior. High-quality software allows support engineers to analyze the software’s behavior (and even more, its misbehavior) by providing measurable insight.
  
  
• Gerhard’s happiness about the highly analyzable software ends abruptly, when, after quickly identifying the error, he finds that the code is as flexible as a steel-trussed girder. It would be far better if the software were easy to change without risking the overall quality. That would put Gerhard in the position to fix the problem as quickly as possible (and as expected by the customer).
  
  
• Finally, Gerhard needs to be able to test the fix to know if it works correctly or not. Providing a customer with an untested fix isn’t a good idea and ideally, that testing would be done in the same environment as the customer is running it on now. The testing also has to be done quickly to get customers up and running.

To deliver excellent software support, support engineers need developers to create high-quality software. As long as software environments continue to change quickly and bugs continue to exist in software, Gerhard’s wishes for analyzability, changeability, and testability are hopefully heard and realized by your R&D department.

About The Authors
Henry Goettler is Director of Customer Support Global at Intershop and has been working for the last 11 years as a process engineer and manager in the most exciting part of the IT business – Technical Support. He’s also a beardless Bavarian with an English appearance who speaks Chinese.

Kristine Vallila, currently a Customer Support Process Engineer with Intershop Communications, started in the IT business after completing a degree in literature. After four years in the industry, she has learned to combine these two seemingly conflicting worlds by emphasizing clear communication as part of her daily work, and making efficiency her hobby at home.