From the archives: Software bugs

This article originally appeared in Micro Decision in 1990. Back then, we thought of software bugs as  annoying. But that was a pre-Internet era. Now we know bugs to be dangerous, as they are the material with which malware works.

Yet while software bugs today undermine our security, can we honestly claim that software is actually any less buggy? Probably yes. You don’t get nearly as many savage, fatal bugs requiring recourse to the Big Red Switch as we used to suffer in the 1980s. However, software has also grown hugely more complex, so flaws – and the vulnerabilities they engender – are found lurking in the corner cases and obscure parts of the code where only cyber-criminals and intelligence agencies can find them. Or something…

This piece ends rather abruptly, and there’s no [ENDS] at the end of the file, so I suspect that it’s been accidentally truncated at some point. Oh well, we all know how that feels…

 


SOFTWARE BUGS

Take a look at the software running on your PC. If it’s anything more than the simplest utility program then you can practically guarantee that there’s a bug lurking in it somewhere. You may never find it: the bug may require a complex, convoluted and highly unlikely combination of circumstances before it rears its ugly insectoid head. But it’s there somewhere. So how good is the software supplier at dealing with that?

The likelihood of running across some kind of ‘undocumented feature’ increases as software becomes more complex. Even packages that have been around for decades aren’t free of the problem. A working version of WordStar once fitted comfortably on a 360K floppy disk: WordStar 6, with all its font and peripheral support files, supplementary programs and added features, is distributed on a fistful of floppies and only the most perverse user would try to run it from anything but a hard disk.

Each new generation of the software introduces its own faults. And even maintenance upgrades, designed to eradicate known pests, can bring new ones with them.

Naturally, software publishers do their utmost to cleanse their products of faults, using debugging tools and extensive alpha and beta testing. Yet they are under commercial pressure to start seeing a return on their investment and that means getting the product out on the street.

When a company decides to rush a buggy program into users’ hands, everyone suffers. It’s the users themselves who are stuck at the sharp end of the problem: having spent significant amounts of money on the software they find themselves committing valuable time, effort and further funds in a futile effort to install and use software that isn’t up to the job. Even worse, the product may work for a while before crashing catastrophically.

Dealers and distributors suffer because they find their resources tied up in efforts to keep customers happy. Indeed, dealers often bear the brunt of software support. Customers quite reasonably expect the product they’ve bought to do the advertised job and if it fails logic and law suggest that one’s first port of call to make a complaint is the shop where you purchased the goods. And yet the dealer may have no clearer idea of how to solve the problem than the customer.

Finally, the software manufacturer suffers. Word soon gets around when a program is fatally flawed. Sales drop off. Potential clients look elsewhere, so even if you do kill off the bugs and arrive at a perfect product it may be too late. In any case, your reputation is forever sullied.

Ashton-Tate has learned this the hard way with dBase IV. ‘It definitely came out too soon,’ says Joan Chesney, technical product manager for dBase products at Ashton-Tate’s dBase Technical Support Group. Her group bore the brunt of user dissatisfaction as the world began to discover that the new version they’d waited so long for had serious problems. And was up to her group to find ways of helping struggling users overcome the problems.

‘Obviously, in Tech Support we realised quite quickly that there was a problem,’ she says. ‘First we put people on researching the problem, because to begin with it was quite difficult to get the clarity. We started producing text files quoting what the problems were we found and how we could get around them. And once we’d started that process we delivered an update to those text files about once a month. We actually put them on disk in the end and distributed them – there were eight different versions of that support disk. We would distribute them to places like the user group, who would put it on their bulletin board, we distributed to dealers and end users who rang up with problems.’

Tech Support also provided software patches. ‘There are different templates within dBase IV for different functions in the control centre,’ explains Chesney. ‘We produced several templates for curing problems within dBase IV and those were distributed on the support disk as well.’

In addition to measures designed specifically to overcome problems with dBase IV, Ashton-Tate has regular support facilities. It distributes the Baseline newsletter to registered customers once a quarter, and this often contains question and answer sections that provide solutions to difficulties. Ashton-Tate also provides hotline services. Letters and faxes are answered free: the telephone hotline is free during the 90-day warranty period and this may be extended by paying a fee.

Paradoxically, owning up to a program’s faults is one way of maintaining users’ confidence. Most people are grown-up enough to appreciate that no software can be entirely bug- free, and openly discussing your software’s shortcomings allows users to avoid weak areas – particularly important with something like dBase that is used as a development tool rather than an off-the-peg application.

These sentiments are echoed by Colin Budgen, product marketing director at distributor P&P. ‘I’ve been using dBase for many, many years – in fact I brought it into the country originally on the Apple,’ he says. ‘The big difference was then that the manual came with all the so- called ‘features’ listed in a big document at the back…

For a development language, if one does that then I find it very acceptable. The problem nowadays is that they feel they can’t tell you about these things. Ashton-Tate is a good example: when dBase IV version 1.0 came out, everyone knew there were a lot of bugs. It was fairly easy to get a complete bug list because they did publish it on computer services – which in the US, of course, is brilliant but which is not so brilliant in the UK because hardly anyone has got access to these.’

To some extent this has been fixed in the latest version. In dBase IV 1.1 the README file and tech notes include details of how the program might ‘work differently’ under certain circumstances. It’s still some way off a proper bug list, however.

Paul Morrison of the dBase User Group feels that it has something to do with nervousness about admitting one’s faults in public, particularly for a company like Ashton-Tate that is feeling the pressure from competitors.

‘All of us who are technical feel that publishers should publish bug lists, and would like to see them publish bug lists,’ he says. ‘I would see it as a sign of confidence. But I don’t know any publishers who do it.’

He adds that it’s natural for any manufacturer to feel some reticence towards owning up. ‘It’s very easy to get on your high horse and be very moral about dBase IV,’ he says. ‘But sometimes I look at it by saying to myself: “OK, how do I handle screw-ups?”. Sometimes I run away from it: other times I keep hoping that maybe it’s not as bad as it is. But eventually it kind of nails you and you have to admit that it is worse than you originally thought. And then there’s finally getting to grips with it.

‘There’s a lot of users who actually managed to use the product. And there’s a lot of people who had a really tough time. It’s like a car: it might have a bad shudder at 90, but if you shuffle along at 70 you never hit that. I think dBase IV was fine providing you didn’t push anything. I do know developers who got through the development process with it and worked round the things they bumped into.’

Ultimately more important than support services, however, Ashton-Tate has given the software a thorough working over. One of the biggest problems with 1.0 was the memory management system. It needed 520K free at the Dos prompt: if you didn’t have that it might run but then cause problems. It also called on a whole suite of overlays, many of which had to be loaded in their entirety even if only small portions were required. In 1.1 there is only one overlay file, and the program loads only the bits that are needed. It was a major piece of redesign that should have solved the memory problem but Ashton-Tate wasn’t risking anything this time. It beta tested the new version at over 2000 sites worldwide. That resulted in the upgrade being slow to appear on dealers’ shelves, much to the dismay of users struggling with 1.0 and those who had put off buying dBase IV altogether until the bugs were ironed out. And that further compounded Ashton-Tate’s problem with lost sales and market share, but the company couldn’t afford to have its reputation take another battering.

ATTITUDE

As it was, Ashton-Tate didn’t escape unscathed. There are people out there who still spit blood when the company’s name is mentioned. This unhappy state hasn’t been created entirely by the product itself: it’s conceivable that the bug problem has been overhyped, although there was also some disenchantment with lack of promised features and performance. But what was the final straw for some was what they saw as Ashton-Tate’s attitude.

‘The attitude of the software producer is very important,’ says Simon Haigh, marketing director at Debug, an IBM systems centre. ‘Frankly I’ve found Ashton-Tate to be a little bit arrogant – not in touch with the marketplace.’

DISTRIBUTION/BULLETIN BOARDS

‘My feeling is that nothing’s changed,’ says Budgen. ‘Bugs are a reality. What I’d like to see is a responsible attitude to them, a responsible attitude being that if a bug is found there should be some freely available method of finding out about that. And there should be a level of proactivity in telling people. If the cost becomes prohibitive then they won’t do it, and that’s why their not doing it anyway. So they have to find something that is reasonably available to most users, and that’s the big difficulty.’

Compared to the drubbing Ashton-Tate got from the people we contacted, Lotus got off very lightly. The first version of 1-2-3 Release 3 contained some irritating and occasionally fatal bugs, most of them connected with memory management and poorly optimised database routines. Some of the faults were elusive and specific to IBM PS/2 model 70s and 80s.

As with dBase IV, some of the faults can be traced to Lotus’ need to get the software out quickly. By the time it appeared it was already running a year late. According to Simon Moores, chairman of the Lotus User Group, Lotus reacted fairly quickly in bringing out fixes, although there was still some inertia to overcome.

‘Where any manufacturer is concerned, the knee-jerk reaction is to deny there is a problem,’ he says, ‘especially when the product has just been launched – they’re cagey about it, then there’s a reluctant acceptance later on.’

Upgrading from 3.0 to the fixed version 3.1 costs £35. While this is essentially a maintenance upgrade, with the known bugs removed and some of the sharp edges smoothed off, Lotus’ decision to charge for it is not only justified but actually represents extremely good value for the end user. That’s because the new version comes with some exceptional new features not found in the original. Most notable of these is the Impress graphics package that, as a stand-alone product, retails for £150. True, some people were disappointed at Release 3.0’s paucity of graphics and font support, compared with upstarts like Excel and Wingz, and the addition of the Impress wysiwyg features simply turns Release 3 into what it should have been in the first place. Nevertheless, it means that the upgrade is far more than a simple bug fix, and with the £35 representing not much more than Lotus’ costs on the transaction, the new features are effectively free.

In the short term Lotus may be losing some potential revenue. In the long term, however, the company is gaining from ensured customer loyalty and a (largely) untarnished reputation. As Haigh explains: ‘If they’re giving it away they’re not doing it for nothing – it’s for future market share.’

Haigh was generally impressed with Lotus’ response, and points to Microsoft as another good example. In Microsoft’s case, however, there was an even greater need to maintain a good public image. When the firm launched Word 5.0, Microsoft boss Bill Gates rashly – and, as it turned out, inaccurately – promised that it would be bug-free. Fixes for the problem were sent out quickly.

Microsoft also had problems with people’s perception of MS- Dos 4. Haigh explains: ‘I think the very early versions of Dos 4 had some problems, but they were dealt with very quickly. I think people have stuck to 3.3 out of habit. With Dos 5 on its way, hopefully that will clear up the myths that Dos 4 is unreliable. There were some problems that meant it got a bad reputation, and it offered people things they didn’t really want, like a form of windows environment.’

He points to Microsoft’s ability to sort problems out as one reason why he’s confident about Windows 3: like many others he’s discovered some problems with it, but isn’t unduly concerned.

Indeed, Budgen believes that most software suppliers are up to the job. ‘We do get, from the vast majority, fairly good communications, certainly on any major problems. And on minor problems we are logged into CompuServe and things like that. We get most of the bug listings and then we choose, if we think the bug is important enough, to inform people we know need to be informed – although they are so many and so varied that it’s difficult to keep track of who has got the product.’

Online systems are potentially a valuable channel of dissemination. In the US, Apple used commercial systems and enthusiast-run bulletin boards to distribute its System 6 software – and the patches that were announced 20 days later to fix the bugs! But there is a high level of modem use in the States that simply isn’t emulated in the UK.

‘We did a survey to find out how many people would be interested in a bulletin board,’ says Chesney, ‘and it was such a low response that it wasn’t actually taken up at the time. The number of modems out there and being used was so small that it wouldn’t have been worth our while doing it that way.’

REGISTRATION

‘Quite often people don’t fill in cards,’ explains Chesney. ‘We quite often have a smaller percentage of people registering than have actually got the product. Because we are offering free updates from 1.0 to 1.1 to all our registered users we’ve just found that our proportion of dBase IV registrations have gone up considerably!’

‘Most people who have registered their software will tell you that it has been worthwhile doing so,’ says Budgen. ‘They get informed of updates and how to obtain them, and most manufacturers do inform people of major bugs – not minor ones because they’re happening all the time – and in some cases send them out an update disk automatically.’

 

Leave a Reply

Your email address will not be published. Required fields are marked *