Complexity and self-evident simplicity

A common complaint with computer system design is overcomplexity. Overcomplexity makes computer systems difficult to understand and maintain and leads to unreliability. This violates the accountability and robustness principles.

It does not hold however that a system must be very simple in order to work well. Neither classic Mac OS nor pre-95 versions of Windows had any specific location for software installation. If you moved a program folder on a PC, you would have to open WIN.INI and redo all the file associations by hand, as well as update the program icons in Program Manager. On a Macintosh, if you moved a program binary, all file associations and aliases (shortcuts) would stay working as though nothing had changed. File search was very fast, as the file system was built in such a way as to make locating files by name very efficient. Experience with Apple System Software 7 showed that a system could be elegantly engineered to function smoothly without the overcomplexity that one might expect.

Complexity to some degree is a necessity of a high-quality system. Accommodating human behaviour and takes extra work on the part of the developer and the computer, be it erratic operation or learning by exploration. Making a computer “just work” feels like magic but in reality is a lot of advanced algorithms. For example, Windows XP introduced natural filename sorting at a cost of additional complexity, but that does seem to “just work”.

Various technologies described within these page are quite obvious complex. One could easily ask why a simple approach couldn’t be adopted instead. Moreover, one cannot avoid wondering whether the implementation is going to be so devious that reliability will suffer.

One goal with designing any implementation is self-evident simplicity. That is to say, it should be readily apparent to anyone reasonably technical as to how something works at a basic level. This runs counter to proprietary software where the implementation is often treated as a trade secret. The implementation details must be made public so that people can learn and understand. Keeping the design self-evident helps ensure robustness.

Practices such as hidden files, unreadable binary files and undocumented algorithms must be avoided. System data should be effectively self-documenting. As noted under robustness, if the system needs to convert system data into an efficient opaque database for efficiency, it must be possible to flush this database at any time. For example, the details on installed packages will likely be cached into a database, but should it become corrupt, the master package data can be re-read and the cache rebuilt. The bitmap cache used to speed up display rendering can be cached should that somehow fail. The application and file association caches can be rebuilt also.

Old Mac users will remember that the only action needed to install a system extension on the Mac was to drop it onto the System Folder or into the Extensions folder and reboot; to uninstall a system extension, one need only remove the file and reboot. The same applied to control panels, contextual menu modules and Control Strip modules (although there was some limited dynamic loading and unloading capability). There were no configuration files: what you could see in any of those folders was what was installed. This was completely self-evident.

This will not be a simple system, but it should also be a well-engineered self-healing system along the lines of the classic Macintosh, just several decades more up-to-date and without the lack of protected memory or API call safeguards, or the need to reboot to make system-level changes.