Principles
The Technology Team does its best to hold itself to a set of principles, which we’ve summarised here. Some guide how we work as a team; others guide how we design, build and choose technical systems.
Working principles
These principles guide how we work as a team.
Prove the concept
Where we’re investigating if we can do something new, we try to prove the concept quickly with a prototype. This means we invest a minimum of time, effort and money into something which may not be worthwhile or viable.
Do it right
Once we’re proven that a concept works we will make the effort to implement it properly, rather than throw something together or keep using our prototype. It will often take slightly longer or cost slightly more, but it will almost always save time and money in the long run.
Keep it open
We work in the open whenever we can, sharing what we are working on, our successes and our failures. We need a reason to make something private, not a reason to make something public.
Zero blame
We understand that things go wrong, and believe that when they do nobody is individually to blame. Instead, we should collectively figure out what allowed things to go wrong in the first place and fix it.
Continuous improvement
We can always do things better, and should be constantly reviewing what we do and looking for ways we can make improvements both big and small. We welcome and encourage feedback – both positive and negative – on everything we do as part of this.
For the future
We always keep an eye on the future in what we do, making sure we consider things like long-term maintenance and costs over their entire expected lifetime. We also consider what might come next, making use of open standards, adding spare capacity and future-proofing where we can.
Design principles
These principles guide how we design, build and choose technical systems.
Make the right thing easy
Systems should make the normal, correct thing the easiest and most obvious thing to do.
We prefer sensible defaults, clear interfaces and automation over procedures that depend on somebody remembering the right sequence of steps. If people repeatedly make the same mistake, we should first ask whether the system can be redesigned rather than whether they need more training.
Design mistakes out
Where possible, systems should prevent incorrect or undesirable actions rather than merely warn people not to perform them.
A switch labelled “DO NOT TURN OFF”, for example, is usually evidence that the design can be improved. If something should never normally be switched off, we should consider whether the switch needs to be accessible at all.
Where an action must remain possible but should not happen accidentally or casually, we should add appropriate friction so that it requires deliberate intent.
Signs and labels still have an important role in identifying equipment, communicating genuine hazards and explaining unusual procedures. They should not be used to compensate for avoidable weaknesses in the design.
Prefer boring technology
We prefer well-understood, widely used technology over clever or unusual solutions where both solve the problem adequately.
Novel technology can be worthwhile when it provides a real benefit, but novelty itself is not a benefit. A system which can be understood, repaired and replaced by somebody else is usually more valuable than one which is technically impressive.
Use standards and interchangeable parts
We prefer open standards, common interfaces and readily available components.
Where practical, parts should be replaceable without redesigning the whole system, and equipment should not depend unnecessarily on a single vendor, product or person.
Fail gracefully
We assume that equipment, software, networks and people will sometimes fail.
A failure in one part of a system should have the smallest practical effect on everything else. Where a system is important, we consider sensible fallbacks, manual operation and ways to recover without specialist knowledge.
Make it understandable
Someone encountering a system for the first time should be able to form a reasonable understanding of how it works.
We prefer clear layouts, predictable behaviour, consistent naming and visible connections over hidden complexity. Where complexity is unavoidable, we document it.
Design for the next person
We design on the assumption that the person maintaining a system in future may not be the person who built it.
That means avoiding unnecessary cleverness, documenting decisions, labelling things consistently, leaving sensible access for maintenance and choosing solutions which can be diagnosed without relying on undocumented knowledge.