Our Engineering Manifesto

Here at ONZO we have committed to an engineering manifesto. This sits at the heart of how we deliver software and systems. We revisit this once every 12 months as the manifesto of today will not necessarily be right for tomorrow, as our teams & product evolve.

How We Function as a Team

• What are we trying to achieve? Frame the problem correctly. Capture key decisions in a lightweight manner. Have a single accountable decision maker. Include your stakeholders. Ignore your biases.
• Have fun together. Treat your team mates as professional friends. Trust each other. Don’t take things too seriously!
• Evidence driven decision making. Don’t make decisions based on feelings, beliefs or hunches. Don’t come to a solution before first defining the problem. Do make decisions based on understanding the problem, data and facts.

How We Build Things

• Don’t sacrifice quality. If we sacrifice quality in favour of deadlines or features we accrue debt. If we accrue debt it will manifest as problems visible to our customers. If we accrue enough debt we will not be able to move forwards without rebuilding.
• If it is difficult, do it more often, earlier and automate it. Automate builds. Automate tests throughout the pyramid (including static analysis). Automate provisioning. Automate deployment & configuration. Put feedback from all of the above in the eye-line of engineers.
• Measure and Report. Measure appropriate metrics across delivery, software quality and system operation. Any metric that is captured should drive a decision. If a metric does not drive a decision don’t bother capturing it. Be conscious that metrics drive behaviour. What behaviours do you want to drive?
• Clearly Communicated Coding Standards. Have a clearly documented set of coding standards. Apply them using automated tools. Whenever you touch something leave it in a better state than when you found it.
• Test Driven Everything. Have a clearly documented approach for how you test everything. Consider unit, integration, component, contract, end-to-end and performance testing. Taking a test driven approach will reap rewards in quality and design.

And most importantly

• Occam’s Razor. Favour simplicity.

How We Run Things

• Standard build, deployment, metadata and monitoring. Standardise as much as you can in the system you run. This will remove the need for duplication & bespoke implementations in the infrastructure codebase. Standard builds, deployment, metadata and monitoring allow us to deliver more repeatably and at higher speed.
• We find issues before the client does. We need a solid test approach to assure the quality of software before it is shipped to production. We need a thorough definition of done to ensure new features are ready for release. We need the right level of monitoring and alerting so that problems are highlighted to support staff.
• Keep stack simple enough to be managed by the team. If we take on too many technologies we spread ourselves too thinly. For each new technology consider how it fits to the current ecosystem. For each new technology consider whether the team can take the cognitive load. For each new technology consider if it is really necessary.
• Feedback on how the product is being used. The rest of the business needs feedback on how the product is being used. This will allow them to make roadmap decisions and identify opportunities. Reports should be automated and valuable.
• Monitoring and alerting. The four golden signals of monitoring are latency, traffic, errors and saturation. Choose a resolution of measurement that is appropriate to the system aspect. Monitoring systems should be as simple as possible, no simpler. Each actionable problem should lead to a single alert

Summary

We think that an engineering manifesto is deeply personal. It suits a given team at a given point in time. We therefore don’t expect anyone to adopt ours wholesale but hopefully it will at least provide a little inspiration!

Check out our careers page if you want to help us solve hard problems