• National IT Manager
• Application Support Officer
• Head of Business Intelligence -...
• Calling All C++ & AI Game...
• Solutions Architect

Seven reasons why your software is so slow

Neil McAllister, Information Age

04/01/2008 20:15:34

In terms of computing power, we've come a long way since 1981. Today's average desktop CPU is more than 600 times faster than that of the original IBM PC. Throw in blazingly fast graphics cards, mind-boggling amounts of RAM, multimegabit network connections, and hard drives that spin faster than a Ferrari engine, and you've got a machine that's powerful beyond the imaginings of the original PC pioneers.

So why doesn't it seem that way?

By all accounts, we live in a digital Golden Age, and yet for many of us, our day-to-day computing experience is more purgatory than paradise. Slow startup times, unresponsive applications, delays, crashes, and reboots bog us down at every turn. Upgrades seem to bring short-lived bliss at best, followed by a brand-new crop of frustrations. Our machines keep getting more powerful, but our experience using them hardly seems to have improved at all.

Why does computing have to be so painful? Where have we gone wrong? And more importantly, what can we do to get back on track? Unfortunately, there are no easy answers and no quick fixes. But because forewarned is forearmed, we present here a collection of top pain points experienced by enterprise PC users everywhere.

These seven computing pitfalls aren't going away any time soon. The solutions must come from hardware manufacturers, software vendors, and ICT managers alike. Still, with luck, by recognising the problems, we can avoid the most serious traps -- while doing what we can to steer the industry toward a more efficient, enjoyable computing experience for all.

Security saps system performance The tremendous benefits of computing in the Internet Age have come at a price. Viruses, worms, Trojan horses, DDoS attacks, spyware, phishing -- the list of network-based threats seems to grow longer every day. In response, ICT managers pile security countermeasures onto servers and workstations, malware authors find ways around them, and the cycle continues.

Will we ever see an end to this arms race? "Probably not," says George Myers, director of product management at end-point security vendor Symantec. "To be certain, antivirus technology alone does not provide adequate protection for today's threat landscape."

Securing network end points takes processing power, however -- cycles that could otherwise be devoted to running applications. Loaded up with spyware scanners, active virus screening, personal firewalls, and layers of encryption, a PC that was designed to be a racing car ends up feeling more like an armoured personnel carrier: It's safe, but hardly nimble.

Still, the cost of having too much security is outweighed by the consequences of having too little. Advanced, modern malware, including rootkits, can be extremely difficult to detect, and once it takes hold, it can be even harder to remove. With not just productivity but also sensitive data potentially at risk, locking down workstations is easily justified.

So what to do? How can ICT organisations ensure that employees' PCs are protected without bogging them down with too much security?

"The right balance is really specific for each individual customer," says Myers. "Security is important to everyone, but the cost of security has to be weighed. Some security technologies are too costly to maintain and burdensome for users, but others are both simple and effective."

In other words, cross your fingers. Security vendors must constantly revisit and rethink their approaches to stay abreast of the latest threats, but they can only do so much. So long as the nature of network-based security threats is in constant flux, formulating an appropriate security policy for any given company will always involve trial and error -- with end users caught in the crossfire.

Lack of standards stifles agility If you aren't happy with the performance of your software, the solution should be simple: switch to different software. In practice, however, jumping ship is seldom that easy, and vendor lock-in is a reality with which most ICT departments are far too familiar.

The company we love to hate remains one of the top offenders. "Microsoft talks a lot about listening to its customers," explains Andrew Updegrove, principal at technology law firm Gesmer Updegrove and author of The Standards Blog. "But the fact is that without competition it can pick and choose from what the customer says."

Microsoft Office is the most obvious example of how proprietary document formats end up limiting customer choices. Once a company has committed a large amount of data to an application suite and its accompanying file types, migrating to a different platform can be too costly to contemplate.

Lack of interoperability can be a problem for enterprise apps, too, -- particularly in loosely coupled SOA (service-oriented architecture) environments. When disparate legacy applications are linked haphazardly together in an SOA, data might need to be translated back and forth between incompatible XML formats or databases multiple times for each transaction.

The best solution to the ICT interoperability blues is to standardise, preferably using industry-supported open standards. Unfortunately, this isn't always an option. Because standardisation requires consensus -- often between competitors -- developing and ratifying workable standards can be a tedious process.

Even when a standard is finalised, early revisions may not cover all the conditions and features that individual customers may require. Often, businesses can't afford to wait for a robust standard to emerge before deploying technology.

To achieve the best results, Updegrove recommends developing a master plan that outlines how standards fit into your organisation's computing needs. "Take a systemic approach, apply that approach to the enterprise, be realistic and flexible," he says, "and then go to it."

By deploying open standards early and often, ICT departments stand the best chance of forestalling vendor lock-in before it happens. In the long run, the only alternative is an ICT organisation left with no alternatives.

Centralising ICT gives rise to bureaucracy When you're having problems with your enterprise laptop or workstation, who do you call? Is your ICT staff just down the hall, or are they on the other side of the globe?

At one time, staffing each branch office with its own ICT manager and techs was standard practice. Today the pendulum has swung the other direction. With technology now a mission-critical component of most businesses, the trend is for ICT to account directly to senior management. Centralising ICT has become the norm, and in some cases, ICT functions are outsourced completely.

Unfortunately, ICT organisations often handle the transition poorly. Where once they were free to concentrate on desktop support, now they are saddled with additional burdens such as regulatory compliance, management of zero-day security threats, and the need to generate real-time business performance metrics. Often they respond by taking an authoritarian approach, locking down workstations and establishing cast-iron ICT policies.

Things only get worse from there. As more and more user requests require intervention from ICT, bureaucracy sets in. Soon even the most basic reconfiguration requires a trouble ticket.

Ironically, heavy-handed ICT administration can sometimes backfire. End users, fed up with the burdensome restrictions of corporate ICT policy, react by installing their own IM clients, P2P (peer to peer) software, application servers, and wireless LANs. Similarly, inadequate licensing policies can lead frustrated users to install pirated software -- all of which encourages ICT to take an even heavier hand.

Reversing this trend will take serious effort. ICT policy should not be drafted haphazardly, but instead with careful consideration of actual business needs and objectives. Senior management must stop viewing ICT as a "business partner" and instead recognise it as an integral part of the organisation. Greater emphasis must be placed on individual user needs, with a renewed focus on desktop support.

Of course, these measures will cost money. And that's the bottom line -- until businesses are willing to invest in ICT commensurate with its role in day-to-day operations, we shouldn't expect ICT to help improve our computing experience. In fact, it might even hinder it.

Usability remains an afterthought

Have you ever tried to do something with your PC only to discover that you couldn't? It isn't that the software can't handle it -- the function you need is in there somewhere, as advertised on the packaging or in the long e-mail chain of functionality added to an internal app. The problem is that you simply don't know how to find it.

Welcome to a new era in poor usability. As much as software vendors skimp on QA (quality assurance) testing these days, user case testing is being overlooked with even greater regularity. As publishers and ICT departments race to meet shipping deadlines, too much of the overall product or project ends up being designed by programmers, rather than user interface experts. Unfortunately, that often means the software suits programmers' sensibilities better than our own.

Where software vendors do pay attention to appearances, the trend is to design flashy interfaces with lots of eye candy. Yet slick graphics don't necessarily translate into a pleasant user experience -- and it doesn't help when developers pile on feature after feature.

"In designing any user interface, one of your key decisions concerns the tradeoff between features and simplicity," writes usability expert Jakob Nielsen in a recent blog post. "The more features, the more complicated the system inevitably becomes."

Ironically, feature creep is coupled with another disappointing trend: the elimination of printed manuals or user guides. Users are expected to understand how software works, right out of the box, even as the user interface grows steadily more complex with each new version.

According to Nielsen, the problem with complex UIs is that the user is seldom really motivated to figure out an unfamiliar program. "To determine how much complexity you can afford in a user interface, you must analyse user engagement levels," he writes. "Do they care deeply, or do they just want to get something done as quickly as possible?"

And how can you tell when users will be adequately engaged with your software to allow you to pile on the features?

Nielsen's advice there is simple. "Typically, users care less than you think."

Code bloat abounds Application vendors love to wow customers with bells and whistles packed into each new version of their software. But after a few successive releases, the sheer number of features in an app can start to weigh it down. As "code bloat" sets in, user experience inevitably starts to suffer. It's little wonder why corporate users -- especially those unlikely to alter their application habits -- are growing increasingly reluctant to comply with ICT mandates to hit the upgrade button.

To be fair, writing applications is a lot more demanding than it used to be. Developing software that performs effectively in a multithreaded, multitasking environment isn't easy. Neither is juggling all the elements of a windowing GUI. If it weren't for sophisticated frameworks that automate these chores, developers would spend a significant portion of their time reinventing the wheel. Too much reliance on these tools, however, can encourage lazy programming practices and poor design.

In the old days, programmers optimised code by hand, byte by byte. Today it's a different story. Whether they're building software for the desktop or the datacenter, modern application developers rely on huge libraries of third-party code, often with very little understanding of their inner workings.

Modern development environments are different, too. Languages such as Java and C# relieve programmers of the burden of housekeeping tasks, including memory management and security, but they further conceal the internals of the system behind layers of abstraction. It's hard to optimise code when you don't know what's going on at the lowest levels; no wonder so much software seems sluggish and cumbersome.

But developers shouldn't shoulder all of the blame for bloated upgrades that perform more slowly than their predecessors. After all, when software development cycles are driven more by sales than by sound engineering, it only makes sense to expect the worst. Rushing a product to market to meet a published ship date is a recipe for disaster, yet it happens so often that customers actually expect it. Massive bug fixes, service patches and suboptimal out-of-the-box performance have become a way of life.

Will high-quality software ever become the norm? In part, that's up to us. As customers, it's time we voted with our wallets. So long as we're willing to skimp on code quality for the sake of the latest, up-to-the-minute upgrade, software vendors have little incentive to ship us anything but second-best.

Computing trends overburden the network Don't call it "client/server". Today's database-driven applications are a world apart from the green-screen terminal apps of decades past. And yet, in this age when "the network is the computer", more and more data processing tasks are handed off to remote resources. Server-based applications, centralised content management, SOA and SaaS (software as a service) are all part of this trend -- and all put increased burden on enterprise network links.

Unfortunately, the network isn't always up to the task. Last year, top SaaS CRM provider Salesforce.com stumbled with a series of intermittent outages that deprived customers of access to their data. Not being able to read the news on your favourite Web page is one thing; when lack of access translates into lost sales, it's a serious problem.

Whether you lease them from a SaaS vendor or host them in-house, networked applications share the same basic weakness: The network is a primary point of failure. If your application uses a "fat client", at least the UI exists locally on your PC. With Web-based apps, on the other hand, every mouse click depends on a reliable connection.

Mobility only exacerbates the problems of the new, network-centric model. Intermittent connectivity means mobile employees' data is often poorly synchronised with the central data centre, especially where security is a top concern. And current wireless networks are inherently less reliable than traditional ones, adding to user frustration. Many businesses may simply be asking too much of their networks, too soon.

Still, there's no turning back. Distributed, network-based applications are simply too useful. To truly succeed with this model, however, calls for significant adjustments. Multiple, redundant network links are just the beginning. Network administrators must become full-fledged participants in application deployment strategy.

Most important of all, however, is education. As enterprise apps increasingly go online, users must recognise that, though their PCs are faster than ever, the day when they can expect fast, consistent access to all their tools and data may still be a long way off.

Chip advances leave developers in the dust Ever since Gordon Moore's 1965 proclamation in Electronics Magazine, we've come to expect processing power to double every two years. So why don't the latest CPUs seem significantly faster than those made even five years ago? Has the lease on Moore's Law run out? Or has the science of silicon left software developers in the lurch?

Part of the answer lies in a popular misconception about what Moore's Law actually says. Moore never predicted that chips would steadily gain gigahertz, only that each new generation would be capable of holding more transistors than the last. He was talking about increases in complexity, not clock speed.

Current CPUs are certainly more complex than their predecessors, but chip designers are butting heads with the laws of physics when they try to push the envelope of overall speed. More cycles per second mean more heat. Too much heat and the circuits start to break down.

As a consequence, electrical engineers have had to tweak chip designs to improve the processing power of CPUs running at modest clock speeds -- in short, to create chips that do more with less.

The results are marvels of electronics, to be sure. But the new chip designs, with all their performance-enhancing tricks, are unfamiliar territory for many software developers. As Bjarne Stroustrup, designer of the C++ programming language, explained in a recent public talk: "If you look at machine architectures, especially the really advanced stuff, you'll see I'm not exaggerating when I say it's weird."

When it comes to dual-core chips, that weirdness doubles. Etching two or more complete CPUs onto a single piece of silicon offers great potential for performance increases -- at least in theory. But to take advantage of these advances, software must be designed with multiprocessing in mind.

Applications written by coders who have not been trained in parallel processing, for example, will see little benefit. What's more, developers need new tools such as those proposed by AMD to properly adapt their software to multicore chips. Unfortunately, very little of the software we use today measures well by these standards, including the leading operating systems.

Computer scientists predict that quantum computing may one day render today's silicon CPUs obsolete. Even if that happens, however, the software development downside will remain the same. Until the developer community can fully tap the latest hardware advances, much of the promise of these new technologies will go unrealised.