Sluggish Applications: Is it a Software or Hardware problem?

There’s a fine line between software and hardware, and it can difficult to tell which one is causing your computer’s sluggish behavior. In this post, I present two case studies in which one was being blamed but the other was the cause.

Redesigning Sluggish Excel Files

TL;DR? Sometimes you need to rethink how you’re using the resources already at your disposal. A simple redesign might be all you need to better support your business process needs.

A finance team was struggling with a slow Microsoft Excel application. This application brought in data from multiple database sources, and utilized PivotTables to explore, analyze, and summarize that data.

Unlike many of their other Excel files, this one was particularly slow.

All of these folks were well-versed in Excel, as evidenced by their use of databases and PivotTables. They had developed, in-house, a myriad of applications that used these types of integrations. So it was natural for them to assume that a slow Excel application meant they needed faster processors or more RAM.

They first asked their IT department for computer upgrades to satisfy both perceived needs (processors and RAM). Their IT department said, “No, your computers are good enough.”

The team then asked for just an upgrade to RAM, to which their IT department replied, “No, you have enough RAM.”

Stymied, the team decided to buy new RAM as personal out-of-pocket expenses and install it themselves, which they did successfully.

In line with the determination of their IT department, these upgrades had no effect on the performance of their application.

This is when the finance team reached out to me.

I was able to determine that the slowness of their application was due to the way they had designed the application, not the hardware. Many of the techniques they were using had worked well with smaller data sets, fewer database integrations, and fewer data manipulations. It was bringing them all together into a single workbook, without streamlining, that was causing the problem.

The bonus of bringing me in as a consultant was that I not only helped them streamline this application, I was also able to integrate a few new features that had been on their “wish list” that either they had decided they couldn’t add to an already slow application, or they weren’t sure how to do on their own.

The final application added a little bit of VBA to speed things along, and broke some of the functionality between different workbooks, which was in line with the process of how they were reviewing the data in stages anyway.

One of the best things about the “new” application was that it better utilized resources they already had, and required no new resources.

A SOP to Fix a Sluggish Microsoft Access Database Application

TL;DR? It’s easy to become frustrated by the application you use most, and decide that it’s the thing that needs an upgrade. In fact, it might just be the place you notice the problem the most, and the cause is elsewhere. (And you might need a new preventive maintenance SOP.)

An organization was using a Microsoft Access database application as its central data repository for daily operations and client services.

This application was designed by a company that had since gone out of business. I was hired to help the organization transition this application from the old MDB format to the new ACCDB format so that they could upgrade their entire Microsoft Office Suite.

As part of the transition, we were also working together to eliminate some bugs from the original application as well as add new features. One of the issues they wanted address is how sluggish they felt the database was, which was leading to some poor practices like not signing out at night because they felt like it took an inordinate amount of time to log back in in the morning; this left their data insecure overnight. They also had to wait – sometimes several minutes – for new screens to open within the application.

While it was true that the database application could be made more efficient, I had no problems opening the application immediately on other computers outside their network (e.g., my own laptop). Nor did I have problems switching between screens, including those that pulled together a lot of data (e.g., searches and reports).

I decided to investigate for other symptoms.

As it turned out, folks had a habit of also leaving their web browsers open with an unbelievable number of tabs open. This was certainly something to address, but it didn’t completely solve the problem.

Further investigation revealed that they were relying on a Wi-Fi router rather than Ethernet connection to connect to the shared drive that housed their database application … and they had never rebooted the router.

I worked with the client to develop a preventive maintenance SOP to address this issue and help to prevent it in the future. It included features like:

• assigning a “point person” who was responsible for executing this SOP
• scheduling this SOP to be executed every two months, after close of business so that the reboot wouldn’t affect business operations
• explicit instructions on how to perform the reboot on their router (and avoid a factory reset)

Everyone in the organization noticed the speed with which they could now use the database application after that first reboot.

Have a story of your own to add?

If either of these cases helped you troubleshoot your own sluggish applications, I’d love to hear about it in the comments!

Have you experienced a problem like this yourself, and were able to resolve it? Please share!