What to expect from a professional software product

During the years I've been in the business, I've seen a lot of different software applications, and installed, configured and managed at least dozens of them. Sometimes, especially as a software developer, I start to think: why on Earth did the developers implement things this way? Sometimes, there are ground for "non-standard" implementations, but oftentimes, it is just a matter of laziness from the developer's part.

I thought I'd compile a quick list of things that I would like to think as the base level of a professionally used (enterprise) application. I'm not saying this is a complete list, so feel free to send me your comments.

Here are the things I'd like to see, in rough order of preference.

1. Installation and setup. Your application must install correctly into a clean machine with the latest patches on. If I take a clean, fresh Windows operating system installation from MSDN media, and your application fails to install there (provided the operating system is supported in the first place), thumbs point down.

Tip: make sure your setup application can detect service packs, OS versions, etc. that might affect your application. If you cannot support certain OS/service pack/patch combination, let the user know. But do not block the installation if this is the case. Let the user choose whether to take the risk or not.

1B. If you application is complex and requires extensive configurations before it will work (for example, ERP systems), create a pre-checking utility that checks OS versions, firewall configurations, IP addresses, etc. This is much more helpful than having a 35 step precheck list in your manual. If you setup application proceeds, the user assumes everything is fine.

2. Documentation. Most commercial applications do have documentation in place, but often the most important piece of information is missing: the installation architecture. For instance, you are creating a test environment for a n-tier application. You know you need a client application, application server and a database. But which TCP ports do these applications use to communicate? What kind of security settings do they need? Are they implemented as client applications, Windows applications, web applications, etc.? All this information should be clearly given.

3. Diagnostics logging. This is especially important for multi-tier applications. Your log should display (when enabled separately) about client and server communication, whenever exceptions occur (see #4), and if there are warnings for example about security settings. The log must be detailed enough to aid in debugging your application. However, the most important thing: remember to clearly document how to enable this logging. The worst you can do is keep things undocumented, and only let the administrator know about this feature after the fifth support incident.

4. Exception handling. This is the year 2011, and today, it is not OK to: a) let Windows show a generic message that your application has stopped working, or b) simply vanish from the screen. Both cases are symptoms of poor exception handling. Keep your stack clean.

4B. Error messages. It is okay to keep end-user error messages free of technical jargon, but never disable the administrator's ability to see more details about the exception. The worst you can do is display error messages like "Operation failed" or "Cannot access database" without any further technical details. It is OK to hide the technical details for example behind a button.

5. Audit features. If your application is a multi-user solution and uses a database, you should provide features so that application usage can be audited. As a bare minimum, you should log who has created a particular record and when, and secondly, who has modified the record (if any) and when. Technically, you can implement this with four fields: CreatedAt, CreatedBy, ModifiedAt and ModifiedBy. Not every table needs these fields, but at least the high-level ones do.

6. Performance. If your application manipulates data, it should support multiple threads. That is, it should be able to distribute its workload among the multiple cores of modern processors. It's a waste to have a new six-core server and notice your server application only uses a single core.