Default Requirements

One common source of confusion in software development comes from ‘default requirements’. Since we don’t explicitly add them into the analysis/design, people mistakenly think they are ‘optional’. They are not.

If you are going to build and maintain a computer system, no matter what it does, there are some default requirements that must be met in order for the system to be stable.

User Requirements

• The system should never lie to or mislead the users.

• The system should do what it is told to do, when it is told to do it.

• The output should always be deterministic.

• Any work/effort should never be lost or forgotten.

• The system should be up and available when the users need to use it.

Operational Requirements

• Installations and upgrades should be simple and safe.

• Untested code should never make it into production.

• All code/configuration upgrades can be rolled back.

• Any resource outages will be tolerated.

• Operations can be monitored for errors.

• Reboots will always work. 

• 100% guarantee that the matching code is easily identifiable in the repo.

• All data imports are idempotent.

Development Requirements

• It should be easy to set up a dev environment, all devs should use the same setup.

• The code in the main branches of the repo should always run, but never be dangerous.

• Everything needed to build and run the code is either in the environment or in the repo.

• The repo contains each and every ‘source’ file, even if that file is binary.

• There can be more than one instance of the development on the same machine.

• No work should ever be lost (code, config, documentation, or build)

• Anything that is not obvious, should be documented along with the system.

• Most bugs should be reproducible. All code/functionality is fully testable in at least one test environment.

• The code edit/build/run cycle should be as short as possible.

• Dependencies should be fixed, updating them should be manual.

• Everything should be named/labeled properly. Devs can’t lie to the users, they can’t lie to other IT people either.

These requirements aren’t optional, they don’t depend on language, OS, or tech stack, they are not legacy and they are not negotiable. For each one that is missed, there are problems that degrade the quality of the system and/or the ability to keep it running.

Given the rather frantic state of the software industry, it is getting harder and harder to freeze the development of a live system. Some very old technologies that are isolated can do this, but most of the newer ones, at minimum, will gradually become less secure.

It should also be noted that if you build a system that depends on technology like a relational database, for persistence, you have two systems, not one. If a dependency is self-standing, then it is external to the system, even if the system is inoperable without it. Everything that applies to code or configuration in the system also applies to schemas and default data in the persistence technology.