Development

"Fast food" software full of flaws

Cheap fast food software comes at a cost. Software companies can sometimes be negligent in testing, and accept flaws for cost reasons – leaving the users to deal with the results. But customers also make mistakes.

12 Apr. 2016 Michael Kurzidim
Fast-Food-Software-01
Software that is programmed quickly and cheaply often has far too many bugs. (Photo: Allies Interactive / Shutterstock.com)

Cost-saving horror stories

If data is the oil of the digital economy, then software is the engine. It must be smooth, strong and fail-safe, as well as intuitive to operate. No driver would buy a sports car if he needed to read a 500-page manual just to start it up. The same goes for software these days, particularly mobile apps. Nothing is possible without end-user buy-in.

"Today we're in the era of acceptance-driven computing," says Michael Sambeth of SAP. In other words, applications that don't get the users' blessing will go nowhere. The user, i.e. the customer, has a much stronger influence on software than even just a few years ago. And today's software developers work very closely with customers to reveal and correct mistakes at an early stage.

Even so, more than half of the more complex software projects fail, costing more than expected and taking longer than planned. Customers even have to give up on desired functionalities more often than necessary. Something doesn't seem to be working here. So we asked software companies and customers what kinds of mistakes typically cause havoc with planned schedules and costs. Because business software providers and customers have the same goal: intuitive, secure software that can perform its tasks efficiently and as well as possible.

Fast-Food-Software-02
Mixed success: The more complex the project, the more frequently it fails. (Photo: SwissQ)

The customer's cardinal mistake

Customers underestimate the effort and complexity of software development, says Gert Brettlecker, Enterprise Solutions Technology Director at Ergon Informatik. Apps in mobile stores might have low price tags, but high-quality business software cannot be made with a fast food approach.

The cost goes up with the need for quality. Customers could greatly reduce a project's complexity, and therefore its cost, with careful requirements engineering and a focus on the key needs. "Better a little less, but good quality" – this motto applies to software as much as to preparing a good meal.

Chaos is the norm in software development

Customers generally do not seem to have a precise idea of what they really want at first, and therefore pack everything possible into their requirements list without really thinking about it carefully. "The ideal situation, where we would know exactly what a product should look like at the end, is almost never what happens," observed Kerry Lothrop, Principal Consultant with Zühlke, adding that while many software projects in aeronautics and the automotive industry are exceptions, these rarely occur in most other sectors.

Frequent flaw: Testing errors

Software goes through a three-stage development cycle – requirements engineering, development, testing – and typical errors also creep in during testing. "Customers implement and test the software in an environment that is not that of the future target environment in which the system will be deployed for production," notes Christian Gasser, Senior Vice President Architecture at Elca. This causes many flaws to be discovered too late, and error correction to cost more than it should.

Fast-Food-Software-03
Gert Brettlecker, Enterprise Solutions Technology Director at Ergon (Photo: Ergon)

Another frequent problem is when system errors – flaws in the software – are manually removed during production, without generating a change log. Software development is teamwork, and without tracking other team members know nothing about the improved source code. More care in preparation and extremely precise work in testing – this sums up software development companies' advice to their customers, to make software better and more secure.

Mobile challenge

But this well-intentioned advice is not that easy to implement in practice. Mobile apps in particular need to work with many different operating systems, devices and versions, as well as added functions like fingerprint scanners, cameras and push notifications. This drives testing needs and costs dramatically up.

Employees left to suffer from bad software

Usually the full spectrum of possibilities is not even tested, reveals Johannes Bergsmann of the Austrian company Software Quality Lab. More resources are devoted to testing – up to 80 percent of the total project budget – if people might be hurt or human lives could be at risk. Core banking systems must also undergo an enhanced testing process, for similar reasons.

Fast-Food-Software-04
Johannes Bergsmann, Software Quality Lab: Teams only test 20 percent. (Photo: SQL)

Generally all the functionalities that are customer-facing are considered critical, and subjected to correspondingly more extensive testing. Whereas inward-facing functionalities such as reporting are neglected, leaving the company's employees to suffer, because "taking a few seconds more or less to generate a report doesn't hurt the company's image," says Bergsmann. "Standard testing only covers some 10 to 20 percent of all use cases, but the typical ones that 95 percent of end users utilize."

Four programming approaches

That leaves plenty of scope for error. Companies apply hard-core cost-benefit analysis and decide how much high-quality, intuitive and secure software is worth to them. Some customers choose to accept malfunctions that might show up in rare use cases, because otherwise the project becomes too expensive. Cost considerations not only influence testing quality, but also the development process.

There are four primary approaches to developing mobile apps for different devices and operating system versions, says Zühlke's Kerry Lothrop. The most expensive and lengthy is for software architects to use native code – Objective-C/Swift for iOS, C# for Windows Phone and Java for Android. That means the app needs to be programmed three times, but makes optimal use of the features of each platform.

Elegant: Cross compiler

A second, more economical approach is currently falling out of fashion, in which the user calls up the app on a browser, so it is more like a mobile website. The third, more elegant option uses a cross compiler (such as Xamarin), allowing programmers to develop the application in the language of one platform, and then compile it to the others.

Most popular: Hybrid cross-platform method

The fourth is the hybrid cross-platform approach, which exclusively uses web standards such as HTML, CSS and JavaScript to display a native app via a toolkit. The app then runs on all platforms. Native functions that are only available on Apple or Android devices are added using natively programmed plug-ins.

"There's no clear winner. Usually we put together a feature matrix and then make our decision for or against a given development method," says Bergsmann diplomatically, while admitting: "If the app needs to run simultaneously on all platforms, the hybrid cross-platform approach with a reasonable cost-benefit calculation is the quickest way."

Problems in team coordination

His colleague Gert Brettlecker from Ergon Informatik takes a different view. "Hybrid applications seemed to be the magic formula in recent years. But today we see that native applications always provide the best user experience, and that smartphone users invariably expect this." According to Brettlecker the most expensive approach – native programming – is always the best. In other words, software quality, which includes performance and scalability, simply has a cost.

Fast-Food-Software-05
Comparing agile methods: LeSS, SAFe and DAD coordinate multiple agile teams. (Photo: SwissQ)

Difficult team coordination

Before development begins and then later during testing is when the decision is made as to whether the end user will have to live with a given flaw here or there, or can look forward to excellent software.

More complex software projects that often spiral out of control also suffer from another flaw that is more organizational in nature. Many software companies use agile programming; according to SwissQ's "Software Development 2015" report this share is 41%. This means using methods such as scrum, but scrum is an approach suitable to a single team, and is not well suited to coordinating the multiple agile teams that are generally involved in complex projects, says Sascha Czudek, Head of Agile for SwissQ.

Agile models such as SAFe, LeSS and DAD are designed to resolve this problem. But these models are young and relatively untested so companies generally manage their team coordination individually. Software development, it seems, is itself still under development.

Development CEBIT RSS Feed