What kinds of problems are most likely to occur? (question rewritten)

Question

If I wrote

1) a C# SQL database application (a simple program consisting of a GUI over some forms with logic for interfacing with the SQL database)
2) for home use, that doesn't do any network communication
3) that uses a simple, reliable, and appropriate SQL database
4) whose GUI is properly separated from the logic
5) that has complete and dependable input data validation
6) that has been completely tested so that 100% of logic bugs were eliminated

... and then if the program was installed and run by random users on their random Windows computers.

Q1) What types of technical (non-procedural) problems and support situations are most likely to occur, and how likely are they?

Q2) Are there more/other things I could do in the first place to prevent those problems and also minimize the amount of user support required?

I know some answers will apply to my specific platforms (C#, SQL, Windows, etc) and some won't.

Please be as specific as is possible.

Mitch Wheat gave me some very valuable advice below, but I'm now offering the bounty because I am hoping to get a better picture of the kinds of things that I'm most reasonably likely to encounter.

Answer 1

It never ceases to amaze me what real users will do. Get ready for anything and everything.

Answer 2

• Never Trust Unvalidated User Input

• Build great error logging (and possibly an error auto-submit feature) into your Application. Have the ability to increase the logging level dynamically, so that verbose logging can be turned on at a user's desktop.

• Report errors to users in a friendly way; don't blame them!

• If your application is dependent on many environment settings or third party addins/libraries that might be changed by other software, consider running an initialisation step that checks for and logs expected and found versions. This can save you pulling out hair!

Answer 3

Q1) What types of issues would still come up?

Bugs, design flaws, feature requests, and usability problems, same issues as any other application.

Q2) How much time and knowledge would resolving those issues require?

More than you want to spend.

Q3) What things could I do in the first place to minimize the amount of user support required?

Tests, tests, and more tests. Hiring full-time testers is the best thing. Otherwise, make sure you set up a support database for yourself so you can easily look up past issues and pass this knowledge onto other support staff.

Use a good bug tracking/ticketing system, preferably one that lets you expose or integrate with some sort of user-accessible knowledge base. If you're lucky, that will help cut down on a small number of support requests.

---

If you want to be really proactive, build a behaviour-tracking system (preserving user anonymity, of course) into the application, so you can see what features users spend the most time on and understand the areas where your mental model of the app does not jibe with theirs.

Oh, and try to make the program fail gracefully. A cryptic exception dialog helps no one; have a screen that explains at a general level what went wrong and what they can do to solve it ("try again in 30 seconds", "restart the application"). Some unexpected error conditions actually can be dealt with this way, such as connection timeouts. Make the same screen have an option to either automatically submit an exception report or copy the debug info to clipboard so they can e-mail it. Your job will be a lot easier if you have a stack trace.

In one of my apps, I modified the global exception handler to display a special message for certain kinds of network timeouts and it drastically cut down on the number of timeout "bugs" submitted. As long as you track exception reports, over time you'll learn which types of unhandled exceptions/unexpected conditions come up frequently and be able to... well, handle them.

Answer 4

We had a customer once that didn't want to use the software, because of the fear that the software will replace him.

He used a forklift to crush the pocket PC that the software was running on.

Answer 5

If you're asserting that your logic is correct and validated (per your question) that leaves basically state-based issues to deal with.

So, the things you'd have to worry about would include:

1. Hardware failures

2. Critical files being nuked on the machine at unexpected times, and not by your program.

3. Dependency updates that break you.

4. Overall system state - things like the hard disk getting full

5. The database being stopped

6. Dependencies getting uninstalled

Also, any place in your code where you assume that an external process is running and available is just a problem waiting to happen. You should always assume that any external process is flaky, and that it going down arbitrarily is expected behavior (that's part of why you have things in separate processes). In fact, relying upon any state that you do not completely control is inherently risky. While you can get overly paranoid going down this road, it's good to at least consider what you're depending on, and being very careful and explicit about what you make assumptions about (probably safe to assume the .NET framework is around, as if it's not, it's probably beyond your scope to fix that issue).

Answer 6

The biggest problem you will encounter is a DUMB/AIRHEAD/LAZY user.

Answer 7

Forcing a user to install Microsoft SQL Server Express is a huge dependency. I would recommend using something more light weight like SQLite.

Also, if you don't heed my advice and use SQL Server, then please make it configured so that it will only accept connections from 127.0.0.1

For making the whole process easy on the user, use as much scripting as possible for the installation. Don't try to force the user to configure some complex piece of software to work with your application. Make sure they have a 1-click default install that works just like that.

Answer 8

First, if you are building a Windows app, you need to account for the fact that everyone's Window's installation is going to be different. Some might have additional security applications running. Some might have UAC on; some off. Different OS's, different OS patches installed. Some users might only be in the Users groups; others in the Administrators group. Just getting users to have the needed .NET framework installed properly could be a challenge if their system is partially fekawied. In addition, you are going to have machines with different physical capabilities. In short, you need to be careful about making any assumptions about what is on the user's machine.

One thing you can do to reduce the change of security software getting in your way is to develop your application to run with the most restricted level of trust permissions as you can muster. Look into .NET trust levels. The more restricted trust levels under which your application will run, the lower the odds that some other security feature or application will balk at its usage. In addition, you should get a full code signing certificate to sign your assemblies.

Another decision you should consider is your use of the database engine. While SQLExpress is nice, it creates an installation maintenance issue for the type of application your are proposing. What if they have an older version installed? What if they have a new version installed? What if the version you are using requires a patch? What if their security software stops the service from running? You haven't mentioned how much data would be involved in the application, but you might consider a more portable database format like SQLite or even Jet (Access) (although Jet has other issues with which to contend) just to avoid having to install yet another service on the user's machine.

As you have stated, minimizing user support is the big issue with something that will have numerous installations. As others have suggested, in order to cut down on support calls and help you make corrections to the application:

1. Testing. Specifically, automated testing both unit and functional. 75% of the code written for this app should be test code.
2. Logging. In addition to a mechanism to log errors, you are going to need to build a mechanism that allows the user to ship those logs to you for troubleshooting.
3. Rock solid installation routine. You need to make the installation as bullet proof as possible. If users cannot install your app, they can't use it. So, along with testing on your app, you'll want extensive automated testing on the installation routine. Ideally, your app would be so encapsulated that it could be deployed via xcopy.

Answer 9

In my experience of 20 years, the most common problem in your scenario is not about building the software wrong, but about building the wrong software.

What I mean is that it's quite likely that, as you introduce the software product into the users' routine, this routine changes. If it didn't change, your sowftare would be a failure, since that would mean it didn't have an impact (i.e. no added value). So, assuming it does change the users' environment, we can also assume it will change the users' needs, and therefore their requirements, and hence the suitability of the software product itself.

By definition, a successful software product is doomed to turn an awkward fit after some time. In my experience, this happens every single time, and there's not technology or method that can go around it. :-)

Answer 10

I started writing code in a spare bedroom in 1988 and built a company essentially typing on a keyboard and answering calls. Since we're still growing 20 years later, I guess you'd say we've done pretty well. I don't take tech support calls very often any more but I pick up the tech line every once in awhile just as a way to stay in touch with customers.

What follows is a kind of compendium or classification system for the most common calls that I've taken over the years. Your results may vary but the list should give you some insight.

---

The most common class of complaint that I've seen over the years dealt with the installation of the application. I went through enormous effort to automate every aspect of the installation but people still have trouble.

1. Inability to Follow Instructions: Some people just won't follow instructions and they'll call you when things don't work. For example, the installation of our app has three steps (database server, database and application). Despite very clear instructions, some people will do just the third step because they have some theory as to why they don't need 1 or 2. Workaround: use a professional installer (e.g. InstallShield) to simplify the process as much as possible. InstallShield and Wise both had tools that offered an amazing array of tools for dealing with almost any contingency. They are pricey but well worth the investment. The simpler the better - assume nothing and you'll minimize your calls.

2. Database won't install: There are some computers that simply will not run the SQL Server express installation. No good reason why, they just wont. There is no good workaround although you will want to make sure you aren't just seeing an instance of case #3...

3. Database already installed: Some people will already have SQL Server (in some form) so your install won't work. Workaround: use a named instance with a unique name.

4. Installer doesn't have privileges: The person attempting the installation can usually figure this one out and will go for help to the group that administers the computer. So this one isn't common. Workaround: No good workaround to avoid the calls altogether but you can keep them short by simply explained that you don't have the ability to override the restrictions placed on them by their Admin so they will need his or her help.

Despite these experiences I would not hesitate to recommend that you use SQL Server and .NET even for a moment. The number of computers that won't run SQL Server has become vanishingly small (if was worse in the late 90s, early 00s) and I've never had trouble installing .NET. It is a great database for local applications and it lets you evolve if you ever want to scale up.

The next class of calls comes from people who simply have a different model of the software than you do.

1. Metaphor Confusion: Our software uses a "Folder and Page" metaphor interface and is widely lauded for its ease of use. But some people used to just got confused by all of the selections we provided because they had a very simple model of what they were looking to do. Workaround: I built a multimedia demo into the help system and the "Getting Started" topic explained the user interface metaphor. Calls on the topic dropped to zero.

2. New Feature Requests: you'll also have a significant number of calls from people who want new features but who, surprisingly, express their desires by telling you that you have a "bug" in your software because you don't support their desired feature! Workaround: Listen! Whenever I got a request from two different people OR I really liked an idea, I built it. I was very aggressive about this. In the end, people loved the product, loved the business, and recommended us to friends. I often say that our business is built by the ideas of our customers (even if they are cranky and unreasonable sometimes).

3. Needs More Detail: Our software offers a broad range of fitness tests that people can perform. At the beginning, we used to field a lot of questions about the tests themselves, the source of our information about the tests, etc. Workaround We built a complete description of our tests and their source into the help system. The broader lesson is that your help system isn't just about how to use your software. It is a very important means for communicating directly with your customer about the whole range of processes that you are trying to automate! It won't eliminate all of the calls but they are a lot shorter when you can say: "just open the help system and click on topic X."

4. Found a bug: You may believe that you have no bugs but it isn't very likely. Users do strange things to software and they will call when they get an error message for doing things they should be allowed to do. Workaround: Have a method for recording bug reports (I can recommend FogBugz!) and be aggressive about fixing them. Of course, you'll also need a means whereby clients can upgrade their systems easily or your fixes won't be much help. Most of the commercial installation packages have tools that permit you to post updates on the web for automatic download and installation. If you want to be successful, though, you must listen to users and respond to their pain.

The next class of support calls comes from people that are moving to a new computer.

1. Moving a Database: People don't know how to back up a database (even if you provide a tool) and they'll often be scared to even try because their data has now become too precious to risk. Workaround: We created a number of very highly detailed documents dealing with these tasks and posted them on our site. It didn't eliminate the calls but it reduced them significantly.

2. System Crashes: "My computer suddenly died in a puff of electric sparks. The hard drive has been making loud grinding noises for months and I never made a backup because I didn't feel like it. How can I get my data back?" Workaround: Only one - have a good sense of humor and remind them to make backups.

The next class of support calls that we deal with are those related to the license.

1. Registering: Will someone using your application need to register? Even if they can do it online, some will call you anyway. Why? In 50% of the cases it is because they want a free copy and want to tell you a lie to get it. The other half aren't connected, have an unexpected message, are moving to a new computer, etc. Workaround: None, these are people who are just determined to talk to you so they can use the app even if they have to have brass balls to do it.

2. Honest People: Some honest people will call you just to ask whether it is Ok to do one thing or another (can I use this on my laptop?) or because they aren't supposed to do something but they hope you'll let them do it anyway. Workaround: Make your license as clear as possible - especially in the first few lines since that's all they will read.

3. Finally, there are fans. People who just love what you do and who want to talk to the company that built it. This is less common now than in the 90s but they are the most fun to talk to. No workaround there, just enjoy it while you can.

Good luck building your business!