Guiding principles

Guiding principles

These are some guiding principles for developing components that will help us with deployment.

Useful quickly

Focus on building things that will deliver real value to real users early. The litmus test should be "does this actually make things easier for the user?".

Components must be useful and usable in isolation.

To the greatest degree possible each component should be usable in isolation. There must be as few required couplings between components as possible.

Components must be suitable for building on.

For every problem we spend resources on solving we must ensure that it results in components that we can build on in the future. If we fail to do this we will be doomed to solve the same problems over and over or we get conflicting implementations of essentially the same functionality.

This means:

• Quality is a focus from the first line of code. Things must work. No hacking up of ratty code and then spend time debugging it into shape.

• Implement things in the shape of Java libraries so that solutions have proper APIs, proper documentation and can be re-used.

• Document as if an open source project.

Must be usable in multiple contexts.

We need to solve both how to deploy things in AWS and on developers workstations. Components that only work in one environment and not the other are not very useful.

This is also important in case we need to adapt to a new provider.

Must be easy to replace.

When designing components we should plan for obsolescence -- meaning that we try to avoid creating components in ways that makes it hard to get rid of them later.