On Software: Some Golden Rules

Here are some rules of thumb for program authors.

Some of them are just best practices/good behaviour, others come from my experiences with rogue software that I migrated from Windows XP to Vista/Windows 7 or had the pleasure to install on some heavily locked down workstations (due to Corporate IT Security):

  1. Do not require administrative privileges for normal execution (initial installation and maybe update installation excluded). This depends of course on the type of software, but a text editor shouldn’t need those rights.

  2. Do not use hardwired paths, it will just make you and the user miserable when it’s time to move to “Windows 56”. If possible, avoid any hardcoded values in general (like paths, names, numbers, etc.).

    One pitfall example from a former dayjob of mine: Localized operating systems.
    In Windows, the built-in group for administrators is called “Administrators” – but on a german system, it’s called “Adminisrtatoren”; similarly, “Users” is called “Benutzer”. Better use the well-known security identifiers (SIDs) instead…

  3. Do offer at least a basic command line interface for your program, makes scripting easier.

    Example (not just for programs or scripts, but also functions in code/APIs): A switch or parameter to enable a ‘silent’ mode; may come in handy if the program/script/function will be called from another program/script/function, with its own user interface.

  4. Related to the previous point: Do offer a switch for silent installation and parameter(s) to pre-configure the package (e.g.: /c=config.ini). Very helpful for deploying your software with a package management software like “DSM”.

  5. Do not prepend directory paths or registry keys with your organization name if you’re just a small developer with one well known application; it just makes it harder to find that stuff if it’s hidden under C:\Program Files\UnknownPublisherName\PopularProgramName.