I am becoming increasingly frustrated by the lack of technical documentation produced by software producers, particularly concerning the use of the file system and registry.
I am sure that it would not take too much effort to provide details about the folder structures used by an application and the registry keys it accesses and stores (and what their relevance is).
In environments that are locked down according to best practice, having access to this information is invaluable. It can help in determining what security rights need to be given to certain folders and registry keys, without having to resort to tools like RegMon and FileMon.
I'm also irritated by how many software producers dictate where they will store their information, without offering any alternatives.
For instance, it seems that Microsoft ActiveSync 4.2 insists on a set location for a user's file synchronisation folder, which ActiveSync 3.8 at least allowed to be changed (albeit by a poorly documented registry hack). Certainly, there doesn't appear to be any documentation on the latest version's configuration. There is no apparent key-by-key description of its registry entries, stipulating the meaning of each and the security permissions it requires.
Another example is that some versions of Hewlett Packard's scanner software seem to dictate where they will deposit scans, which is less than ideal in a corporate environment.
A further example is the Olympus digital dictation system, which suffers from very poor technical documentation and also seems very inflexible about where and how it will store its files.
Good technical documentation would save many systems engineers hours of painstaking analysis and would simply be implementing best practice from the developer's perspective. I'm wondering whether this documentation even exists in rudimentary form outside of the source code of these tools (and even then I wonder whether the developers will have documented them inside the source).
We should really expect higher quality from our software producers...