11 reasons users still hate your software

Did Lincoln say that we hate all software at least some of the time and we hate some software all of the time? He would have. Thank goodness we can’t hate all of it all of the time because, after we stumble on the right combination of clicks and keystrokes, most of it does magical things. Too bad the path to these results can often involve cursing and pulling our hair — especially when the code is homegrown.

Even if we hate the experience of using major products, apps and websites, the software development ecology is often unfair to the custom projects that handle special tasks for enterprises. After all, there are hundreds if not thousands of developers working on the major software and services consumers depend in their daily lives. There are entire teams devoted to the credit card billing section alone and entire buildings of workers devoted to solving how to get people click 1 percent more often. But it’s hard not to judge the smaller in-house projects by the standards set by these brigades of programmers.

Many enterprises have a handful of developers, or just one beleaguered soul, working part time on a software project while juggling several others at the same time. The company’s end-users, fresh from clicking on a major retail website or crafting a bit of wit for social media, switch tabs and expect the same level of polish from the in-house accounting shim running on their desktop.

Developing software is hard, but it’s even harder when your customers are down the hall and eat in the same cafeteria. When they hate your code, you feel it deep inside. It’s easier to recover emotionally from a bad bug if you don’t have someone mentioning it at the company softball game.

Here are 11 reasons why users hate your software. Some are simple to fix. Many are just consequences of scale. Bigger teams are able to build simpler products and devote the time to polishing.

Too much user influence

Do you want to talk with your buddies from elementary school, or read updates about your kids’ school soccer game? You’ve got no choice but to log into one of the few major social media sites and play by their rules. If you worry about your privacy, want to express an emotion more complicated than a heart button, or upload a longer video in a different format, you’re out of luck. The major platforms define their terms and the users must adjust.

Smaller enterprise projects don’t have that power. Their users aren’t stuck with a click-wrapped Terms of Service. The team’s boss answers to the big boss and the hierarchy can twist some arms when bonus time comes. It all adds up to a very different power dynamic when users don’t have to take what they get and find a way to like it. Users must acquiesce when the big social platform sets the rules, but with local software, they can effectively push back. And if they can push back, they will start to obsess about details.

It’s slow

Not all enterprise software is slow. Some of the old stuff actually screams on the new hardware because the development team hasn’t larded it up with features. But when new features roll out, it’s not uncommon for everything to bog down.

Speed is just one tradeoff developers must juggle, and when demand for features grows, responsiveness and performance often suffer. Big teams can redesign along the way but smaller teams can’t.

The only solution is to push back against some feature requests that will bog down user experience. If the new SQL queries will be filled with complex JOINs, push for something simpler. If the clever new button would require a chain of slow AJAX calls, say no. Time is the one thing that we can’t make more of.

It looks old

Old computer programmers often like to visit stores whose checkout software hasn’t been updated since the green screen era because it’s a nostalgia trip. No animated GIFs or really any colors at all. The screen is a matrix of monospace characters in a 25×80 grid. Plus, response time is outrageously fast because the network isn’t jammed up with cool icons and splash screens.

But it’s still a green screen. The bosses may like it because it works without major investment. The bean counters may love it because the development costs were paid off years ago. But the users are stuck living in the 1960s and some are going to complain. Oh sure, power users can memorize all the function keys to blip around the various screens, but the rest of us can’t figure out just how to pull down on a menu — if that square over there is actually a menu.

If the bosses don’t want to fix something that isn’t broken, continue to remind users that it’s superefficient. Print up cheat sheets to help people who can’t remember what the function keys do. Another solution is to build a graphical shell that looks pretty but does nothing but generate commands to be sent to a hidden green screen session. It adds a beautiful facade without changing the guts. And if there are some folks that just love the old green screen, well, they can keep using it too.  

Too much security  

Some local projects suffer from too little security but often the problem is too much. The company isn’t big enough to support a full tiger team, so they err on the side of extreme caution. Maybe someone once inserted a thumb drive with a virus and ruined that feature for everyone. Now USB ports are blocked. Someone downloaded a virus and now all downloads are banned forever. Many small teams act like “Dr. No,” turning down requests and supporting only the most innocent features.

There is no simple solution. Users will hate being constrained by draconian rules but they’ll be the first to freak out if their employee records leak out. The best you can do is concentrate the sensitive data in better protected systems so you can allow the users some flexibility.

No dogfooding

Testing enterprise software is always a challenge and it grows in complexity when developers share few skills with everyone else. Perhaps your business is flower arranging, axe sharpening or butchering meat for creating gourmet dog food. Odds are high that the person building your scheduling software or internal database will know nothing about the work everyone else does.

One solution is to have the developer swap jobs for a week, but that doesn’t fly when the jobs involve serious skills like long haul truck driving or airplane maintenance. Sometimes shadowing can suffice. Sometimes there are smart employees who can do a good job writing the specs.

The developers, though, are going to need to reach out and communicate. They’re going to need to listen to their users and let the users tell them how to remove the rough edges and ill-conceived workflows of the tool. Improving these channels are essential. If the developers can’t be forced to use their own code, they’re going to need to talk to those who do.

Changing the business is expensive

You can change the business to fit the software or write the software to fit the business. Often, the first would require retraining thousands of people and reworking many strange and arcane workflows that developed over decades. So the managers often try to get the new software to fit the old business and that means it mirrors the complexity that’s evolved over the years. Sometimes when people complain about the software, they’re really complaining about some odd practice that began decades ago and has now been immortalized in software.

There is no solution to this except recognizing that the software may just be revealing a bad or overly baroque practice of the business. If your users hate using the software because some part is too complex, maybe that’s because the business is too complex. Use the hate as a signal for bigger changes.

Fewer rewrite cycles

Many programs can be improved by a complete rewrite. I know one team that starts a new version each January 1 and generates an entirely new version each year. It’s expensive but it fixes the bloating and the kludgy cruft that accumulates.

Most companies can’t afford this and if they can, they are often tempted to invest the money elsewhere. So the software gets older and older. There is no solution but budgets big enough to support a full rebuild. Until then, the users just need to accept what can’t be rebuilt.

Aging frameworks

Once upon a time when the software was new, the developers chose a framework for the new code. The choice was smart — then — but the steam ran out. Maybe the framework company was acquired by someone who didn’t care. Maybe it went broke because the framework management was squandering the profits on fancy trips to Europe? Maybe the open source community was poisoned by some toxic haters.

When your team decided to stake the future of the company on this framework, it was a smart decision because the framework was amazing. But now it’s being held together with strings and beeswax while the hacker wolfs circle the camp at night looking for the untended security holes. There’s little that can be done to fix old mistakes like this. You can try to plan ahead for the future by choosing bigger, better supported companies or open source projects with broad support, but there’s a limit to predicting the future. All you can do is consider a rewrite. With luck, you can save much of the business logic.

Extra features

The company building the basic framework tossed in every feature they could imagine to satisfy the needs of hundreds of companies. Your company, though, doesn’t use most of them, but they sit there gathering dust on the menus and, worse, confusing new users who always ask why the features are there. You can have too much of a good thing.

Sometimes these can be edited out or graceful shunted to a submenu out of sight. It may not be cost effective to rewrite the business logic, but often it’s possible to clean up the menu tree and prune the options available to the average user.

Error handling

Exceptions and errors creep into the workflow all the time. Sometimes a link to a key database is broken. Other times the forms contain inconsistent values. Giving the user the ability to understand, work around, and overcome the problems is key.

Smaller projects lack the debugging cycles to flag all of the possible errors and ensure there’s a graceful way to recover. It’s hard to know what is worse: no error message or a cryptic one with a strange number.

Time is a big part of testing and debugging. The best solution is to create a good error reporting framework to encourage users to report their problems. Careful tracking and good documentation is the first step toward fixing these mistakes.

Lower budgets

Even the most successful companies can’t afford enough developer time to produce something in the same ballpark as the vast consumer products that serve almost half of the world. Large banks, trading multinational conglomerates and pharmaceutical companies are rich by anyone’s standards, but they don’t have enough spare cash to support serious development.

Sometimes the users just need to be reminded that the tools are built with a small budget. If the profits are healthy and the bonus pool is fat, maybe that’s the price of using software that’s less than awesome.