An Open Letter to Business Software Developers

letter to software developers

Written for members of the Association of Software Professionals in 2004, a trade group of software developers. There’s a 2023 update after the article.

©Jerry Stern 2004, All Rights Reserved. As seen in ASPects, December 2004


Does your software sell to businesses? Could your software sell to businesses? Business users, especially small businesses with a few workers or a few dozen, need better software, but getting anyone in a networked office to look at new products requires that you make the product easy for business users and system administrators to use, and remembering that those users and administrators are different people.

Every industry, and every office, has one program that everyone loves to hate, and that is absolutely essential to the operation of the office. These are vertical-market products that typically were very expensive, difficult to install to a network, and painful to keep running. That said, the pain level involved with replacing these monsters is pretty much intolerable. As I write this in 2004, my clients have gradually gotten rid of most of the MS-DOS programs in this category. Most. Not all.

If you want to create a highly-lucrative vertical-market product, go visit offices with a system consultant, and ask what program they can’t live without, but would really love to dump. You won’t hear answers you recognize. In floor covering stores, you’ll hear “RFMS.” In insurance offices, “Choices.” In appraisal work it’s “Real-Easy.” For property management, it may be “Magic” or “Skyline.” These aren’t all current products, but they won’t go away, because the old data is in the software, and no one has gone to these offices and offered a new program that will import the history.

Most of these creatures from the pits of character-mode screens are databases, and are based on products that you’ve heard of, like FileMaker Pro and Clipper. Some are specialized form-fillers. Yes, fill-in-the-blank forms. Paperless offices are still a myth. For example, in the vehicle insurance industry, applications are still filled out on forms, provided by the insurance company as downloadable TIF files or sent by fax. A few send PDF files, and the agent offices are left on their own to convert all these forms, or not, to electronic files that can be typed in.

Here are some starting guidelines to writing software that is actually usable for networked offices:

1. Install desktop shortcuts, menu shortcuts, and system settings to the ‘All Users’ folders and ‘All Users’ registry areas by default. System administrators don’t appreciate or encourage the use of software that has to be installed as an Administrator, and then won’t run as any other user. Don’t ask the sysadmin to try to manually copy your shortcuts from c:\Documents and Settings\Administrator.Domain\Start Menu\Programs to c:\Documents and Settings\Workstation Zebra\Start Menu\Programs.

2. Don’t auto-install anything that autoruns. Always get permission. You’re writing software applications, not hardware drivers, so there is no possible convenience feature that is worth slowing a computer down for. To automatically install any autorun program, for any good reason or bad, will result in a recommendation from the system administrator to buy something else.

3. Program registration on a client workstation is pointless. Newsletter signup makes no sense. Forcing a user name into the workstation settings is just plain silly. There is no way that a system administrator is going to type a user’s name into a registration screen, forced or not. On a notebook PC used by an officer, maybe. For an hourly employee, never. Don’t make me type “Secretarial 0451” into your software as the user’s name. If you must have some sort of product registration, tie it to a choice of either the company name or the user name, but never both.

4. Store program data anywhere the user needs it, and provide an easy way to remember that location, but never place data in the same folder as the software or a subfolder beneath it. The program is probably installed under c:\Program Files\YourCompany\YourProduct, and ordinary users on a client/server network can’t write or change files under the ‘Program Files’ hierarchy. This includes program settings–write nothing at all to the program files folders during software operation. Don’t assume that the local documents folder is yours to play in–it isn’t.

5. The office system administrator won’t run your product. Your business users won’t install your product. Don’t confuse them; they’re different people. If your product has extensive sets of settings that reflect how your product is used, ask your user on first program startup to specify settings for data operations, and allow for an ‘Ask next time program is run’ option. Don’t ask those questions during Setup; the system administrator will have to stop working, and ask. We frequently build multiple workstations at once, and pre-install a dozen programs; leave operations questions for operators.

6. Printers are on the network. Plural. They may be shared, or they may be using a TCP/IP port. Don’t assume that printouts go to the local default printer–allow a choice, and remember it.

7. Assume old hardware and old employees. Businesses always have quite a range of ages of hardware and staff. Data-entry applications should be runnable at 800 x 600 resolution, and still have all the buttons and data areas visible and usable. Offices with 21″ monitors and 20-something staffers will appreciate having the higher-resolution settings available, but for most professional offices, the decision-maker wears reading glasses.

8. Make life easy for the system administrator. Some of us are outside consultants, and we never run software, except to install it or patch it or try to figure out why it won’t print. Make sure the software will run for the type of client-server user that will have to run it. For data-entry products, that’s an ordinary user. For file management, probably a power user. For data recovery, an administrator. Test it, on-site, at a target office.

9. Recognize that spyware is, for now, where the venture capital is. It’s not called that by those who publish it; it has some other label, like ‘targeted topic-based marketing software’ or other double-speak, but the label doesn’t change that system administrators and office managers are taking steps to stop users from installing software–all software. That includes shareware trials, but applies especially to freeware and peer-to-peer products. At the business level, they’re watching licenses for warning flags, and they’re seeing plenty from major software publishers. They want to get away from known bad players, but they’re even more determined to not become reliant on any new programs from hell. Behaving professionally is key; businesses like to do businesses with companies similar to their own, in behavior, in style, and in size.

10. Finally, help the businesses to act like businesses. I offer the computer policy below to my clients as a starting point, and suggest having the final product signed by every employee, and reviewed occasionally. Those who actually follow-through have fewer spyware and worm cleanup bills, and get more work done. If your products act like they belong in a business, by making it easy for employees to comply with common policies, and easy for system administrators to find and fix exceptions, you can close more office network sales.

2023 Update: Not much has changed. Monitor resolution in item 7 is not affected by new technology–it’s still a matter of creating software that works for low-vision users. Large software products targeted to enterprise offices are still written in the mode of “Our product is the last one you will ever need, so no, you can’t back it up or move the data file location to some drive other than C:.”