What kinds of problems are most likely to occur?

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

• 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 2

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

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.