You know your software is bad if...

Here is a list of traits of (mostly) modern software, which are not a good sign and/or contributing to our eventual downfall.


Slow off the mark...
Your software shows a progress-bar on its splash screen
Nielsen's Usability Heuristics state that you should always provide your user with feedback on the system state. This especially applies when performing operations that will take a "long" time (i.e. anything over 10 seconds).

Consider then, what it means to have a progress-bar on a splash screen. It means that starting up your app will take a long time. That is, it will take at least 10 seconds at the best of times, even on the developer's infinitely fast machines (as they recognised that there was going to be a wait). And like a self-fulfilling prophecy, your program WILL take greater than 10 seconds to load.

The typical ones I've encountered are between 20 secs and 1 minute. Examples here are GIMP (usually 20secs, but from time to time, it will throw a freak and that slowly reparse every plugin, and every single last bloody font on your HD), Open Office (20 to 30 seconds), and JEdit (10-15 seconds + a further few seconds due to its Java-ness). Ultimately, this will cost you users (or customers), as these waits become increasingly frustrating. Of the three listed here, two of them I don't touch anymore, with loading times being part of but not the whole list of problems I've had with them.

Also, from personal experience, I've found that having a progress bar can in some cases even SLOW DOWN an operation. Once I was working on a tool which I had predicted would take a little while to complete, so I tried adding a progress bar for it to show the how long it was going to take. However, by doing so, I slowed down the tool by at least 2-3 times.

Ignoring the progress bar though, we still have a problem, which leads to number 2...

Your program has a splash screen that hangs about for a long time before your main window even shows up
Typically, if you have the first, you'll also have this second one. Though, that is not always the case, as Office 2007 is only affected by this second point.

In a way, this is even worse, as now you don't have any feedback in general. On some though, you will get to see that it's busily loading up heaps of files from disk. Like in the number 1, users are still not going to be happy, as once again your program takes a while to get its arse in gear.

At least though, we can hope that if it doesn't need a progress bar that it is still faster than the first category ;)

When your user goes scouting around the program files to find a misplaced file, they find heaps of .dll's and extensions that need to be loaded on startup...
Extensibility is nice. Plugins are neat when you need some functionality whose absence is otherwise a deal-breaker.

What's not cool though, is when the fact that the app has to load all these libraries and plugins on startup and take a long time to do so starts wasting the user's time. In fact, it's even worse that most apps in this situation get into a bit of a tangle spending time searching through multiple places to find these files in the first place before they can even attempt to load them.

It's kindof telling then, that most of the apps that are identified via 2, and most certainly 1 have this characteristic.

Handles like a pregnant whale with a swim-bladder infection...
Your program crashes easily and often
Perhaps this is one of the most cardinal sins for programs. Do not crash!

Crashing means bad code; code that's been badly written, untested, or just plain sloppy. It also means that users lose their work, get files corrupted (sometimes), and are interrupted from their task at hand. It also loses you (the coder) brownie points at the end of the day, as users come to hate working with your software, dreading the next time it'll crash on them at a critical moment.

From what I've seen, it seems that the code written by some people is more prone to crashing for inexplicable reasons than others. They are also those who have a habit of using "caterpillar-ifs" and other questionable code style practices.

Sadly, big corporates still manage to make sick amounts of money out of their products that are filled with these problems (*cough* *cough* AD).

Your program is a memory hog
Unfortunately, the abundance of memory these days has led programmers to generally be much more lenient about memory usage. To the point that they entrust cleaning up of large wads of data to a builtin/background garbage collector that might be too busily counting its own toenails than worrying about unused data.

Yes, it's much nicer not having to optimise everything to the last bit. Yes, a lot of algorithms are made a lot simpler to write. All I'm saying is that care should be taken not to now thing its perfectly fine to have 5 copies of the data lying around (typical example, using string concatenation instead of more efficient string-builder-type methods, with all the temporary instances that creates).

This slackness also tends to come with heaps of crashes.

A lot of functionality is accessible more than 2-3 steps away
I should clarify that this is only a relative guideline that does NOT apply across every single last feature that a software has.

What this point was meant to address however, is that there are often times when (particularly software, though digital cameras also often suffer from this) tends to end up requiring going through layers of menus/popups/etc. to get to the controls that you need to use quite a bit. Fundamentally, this was a failure of the designers to correctly identify their userbase and their actual needs, as most of the time, such decisions would not correctly take those perspectives into account (in terms of the amount of wasted effort necessary to attain frequently used states).

One of my personal definitions of usability, or to be more specific, "easy to use", is NOT that a system should show as few controls as possible to the user. This may seem a bit counter-intuitive at first. However, the reason I say this, is because there's a big difference between having absolutely as few controls as possible around, and showing the minimal set of tools which satisfy the functional requirements of primary tasks.
- The first version means that there is an aversion to adding controls at all unless an existing one just can't handle any more, resulting in heaps of buttons are overloaded with multiple meanings/purposes. This actually forms a greater barrier to learnability and progression from novice to expert while making life more long-winded than it need be for those expert users.
- The second version on the other hand, means that although novices MAY be presented with a few more controls to get their heads around, if we have designed everything right, then actually those controls will become self-evident. Their convenience will encourage active learning of their functionalities, which should now have a narrower scope thus being easier to get the hang of, and expert users will not be encumbered by the restrictions.

This is a point when an inevitable question comes up: What happens if I have too many controls that I can't present like this?
Well, firstly consider if much of those functions are actually used by actual users. Are they used by all workflows? Do some workflows actually not overlap that much or at all, and can be separated into separate interfaces althogether?

But sometimes the answer still won't present itself in those cases, in which case...

The system's scope is too broad... scope creep stikes again!
As much as it'd be theoretically nice to have "unified" systems, at times they can just get all a bit too much.

Take the physicists for example: they've been slaving away for at least a century (and probably ever since physics was "invented" as a discipline) searching for "the grand unified theory of everything". Theoretically, it'd be great to have, but in practice, probably it won't happen (and when it does happen, I pity the undergrads who're going to have to learn to coax whatever hideous 10-part differential equation that has to be solved in n-dimensions to calculate the velocities of moving objects of various sizes).

Anywhoo, back on topic. It seems that in software, we have a bit of a preoccupation with trying to find "new features" we can add to our products constantly. However, it's starting to become apparent that many classes of program have actually become "mature" already: that is, there really aren't going to be any new wizz-bang developments there, just tweaking of the existing functionality to make it better. Unfortunately, the "engineer"-tendencies seem to think of how much fun it'd be to hack something new (but useless), leading to scope creep and bloat. Now, a bloated whale ain't fun, right?

Your software must be "installed" to run at all
There is a time when most users believe that they have to "install" their software to have it work at all. This is a sign of weakness (on the part of the software), and once again of the fear that big corporates have about not being able to control distribution. It cannot be expected to run self-contained, but must bring along its own entourage of cooks, maids, and toe-nail massagers.

Sure, some stuff DOES have to be installed (namely operating systems), but most things are actually fine without. It's just some extra convenience gained in one or two cases, but otherwise, it's completely superfluous, yet many users are led to believe that it must happen.