A few weeks ago one of my clients told me that he was going to launch an e-commerce solution that was provided by his accounting software and it operated out of a port in his in-house server.
In response, I sighed in an impolitic way and he snapped back at me with, “You programmers always assume everything is crap unless you didn’t make it yourself.” While I admit this has the ring of truth to it, let me explain what makes bad software so you all can avoid it, regardless of who developed it.
Bad software only works for “some” people.
If your software solution can only be accessed in-house or via a configuration that your IS Manager has to set up individually on every single machine in your office, you’ve either got a high-security scenario (read: you work for the government on issues of national security) or you’ve got bad software.
Bad software tells you “no” a lot.
If you load a set of images (for example) and your software will NOT let you choose whether or not those images display with some ugly default text, you’ve probably got bad software. You’re supposed to be the boss of your software. Your software shouldn’t necessarily dictate how you do things (unless it’s process management software, in which case you should probably listen to it).
You’re having a hard time getting support.
Developers can smell bad software from a mile away. If you ask a few developers to help you maintain your system and they stop returning your phone calls immediately, you’ve probably got bad software. Seriously, we have to walk away from several projects each year because the software the project is created in is so bad. We know that it will take a thousand hours just to understand what’s going on there, and then we will still need to rebuild it. You’ll never be able to afford our support, so you might as well start over, friend.
Every time you try something new, your software breaks.
See No. 3.
The Software’s output is incompatible with everything else in the world.
In the scenario I described above — my client’s e-commerce solution — I caved in and agreed to try to enter the store’s contents into Google Products for them. The output from their database was so corrupt, however, that Google rejected it 25 different times. I then ran a script on the store to try to build an XML sitemap and it sent my script into an infinite loop. This means that their 1,500 item storefront generated 70,000 lines of URLs before I finally stopped my script.
We’ve all been lured into a software trap by low cost or free software. Even I’ve been suckered in more times than I care to admit. The key with all things technical is to pay attention to the warning signs, and make sure you talk to people about what you have planned before you fully deploy and populate the software so that it’s too late to make a change.
And there’s nothing a developer loves more than to help someone dispose of bad software and redeploy in a robust, awesome system. Any of us would take a job like that any day of the week. And we’d return all phone calls. (See #3 above) And even though it costs some money, you’ll be grateful in the end. Promise.
Marci De Vries is president of MDV Interactive, a web consulting firm in Baltimore. Reach her at firstname.lastname@example.org.