We're Hiring!

Engineering Principles

Before dealing with the practicalities of building software, it’s important to understand the broad 10 principles we follow when approaching any project.

  1. Understand the user’s needs
  2. Design with real data
  3. Use feedback, Iterate rapidly
  4. Build services, not tools
  5. Understand context
  6. Favour simplicity
  7. Be consistent
  8. Embrace Reuse
  9. Document
  10. Deliver with confidence

1. Understand your users needs

If you don’t know who your users are you can’t build the right thing. Users come in many forms: end-customers, to companies, through to other developers.

Do research, collect data, and don’t make assumptions. What users ask for is often not what they actually need.

Breadth is often just as important as depth when it comes to understanding users. It is rare that any service is used by only one type of user.

2. Design with real data

Data should drive your decisions. Not hunches or guesswork.

Analytics should be collected right from early prototype stages so you can understand the strengths and weaknesses of the service.

Using the correct data, and the correct tools is vital. Data analysis should always be tied to a business-goal, or user-goal.

3. Use feedback, Iterate rapidly

Using agile continuous delivery and rapid prototyping lets us start small, test, iterate and improve constantly.

The goal should always be to put a service in the hands of it’s users as soon as possible. Consider the true MVP. Do alpha launches.

Avoiding big releases, avoids big failures. Using feedback and data lets us catch problems early.

4. Build services, not tools

We build services that help achieve a goal. Those services may span many platforms, and manifest in many different ways.

At the end of every service, there is a user trying to achieve something. It is our job to guide that user to success as invisibly and simply as possible. When we stop thinking about individual websites, apps and APIs and instead think of broad, harmonised services it becomes much easier to focus on addressing the underlying user needs.

5. Understand context

Don’t build for a single device, or screen. We are building services for people.

Where they are, what they are doing, what their goals are, what their expectations are and which devices and tools they are using all come together to create context.

Without understanding that content, it’s difficult to know why we’re evening targeting a specific device or addressing a specific problem.

6. Favour simplicity

Making something simple is much harder than making something complex. That’s because most systems are inherently complex, so abstracting that complexity away and presenting a simple model of the system to the user can require a lot of thought and work.

This is true on many levels. Not only in tackling how end users interact with a system, but also with how we architect solutions.

Complexity breeds complexity. Often the simplest solutions are the most elegant.

7. Be consistent

This extends over many areas. From documentation, to user interfaces, to coding patterns.

Consistency reduces the cognitive load of having to try and understand something new. Humans think and understand in patterns. Users consider consistent interfaces to be intuitive. Developers can navigate consistent codebases faster.

Technologies and features change, so we must be pragmatic about consistency - but breaking a pattern should be a measured decision, not an accident.

8. Embrace Reuse

This goes far beyond writing DRY code. It econmpases using open standards, open sourcing entire projects and cross-pollinating ideas between teams.

If we don’t reuse tools and ideas we can’t build on past lessons and improve upon them.

A good rule is the rule of 3s. If something seems like it is being used 3 or more times in the business or codebase, then consider finding a way to harmonise this, and bring visibility to the solution.

9. Document

Having reliable documentation is crucial. It helps with troubleshooting, lowers onboarding friction, and improves confidence.

Documentation comes in many forms, from inline comments, to readmes and wikis. Documentation should follow 7. Be consistent. Fragmented and out of date documentation has little value.

Writing documentation takes time, but it’s an upfront cost that will pay itself down over time.

10. Deliver with confidence

Delivering with confidence comes from building within a good process.

From understanding underlying needs, to designing solutions. Following Quality Assurance guidelines and delivering and iterating quickly. Each part of this blueprint lays out ways we increase confidence in delivering the right solution, at the right time.

QCon London

QCon London is a conference for senior software engineers and architects on the patterns, practices, and use cases leveraged by the world’s most innovative.

March 4-6, 2019 Find out more