Having fewer lines of code is desirable β itβs easier to maintain and understand β but we have seen examples where developers go too far, creating extremely terse programmes that have a very low line count, but are incredibly difficult to decipher. We want less code, but not at the cost of clarity.
We keep the software we build as simple as possible, from the code we write to the technologies / libraries we recommend. However, an uncompromising pursuit of simplicity can risk the wider context being overlooked. The simplest thing that could possibly work for you or your team might not be the simplest approach for the rest of your team or the other teams you work with. We strive for simplicity, but always consider how our choices will impact the simplicity of the overall system.
We drive technical innovation and thinking about new technologies, tools and practices for the benefit of our clients. At the same time, we only introduce new technologies when it makes sense for the client, considering the entire lifecycle of the technology. We are careful not to treat client engagements as opportunities to learn a new technology; when we identify technology that we believe will bring real value to a client, we take a responsible approach to introducing it, ensuring relevant measures are in place to prove it not only works as intended, but can prove increased value to the client.
While we recognise the importance of leadership and a technical leadership role on a team, we also recognise that we are all experts in our profession. Taking autonomy and responsibility away from the team can destroy cohesion within the group and is a recipe for disaster. It is therefore important that the team collectively owns the technical solution and the delivery of any system. This value also mitigates the risk of any single individual putting a project at risk when moving on.
Software delivers little to no value unless it is deployed and running in production, with real users using it. We therefore need to understand how the production environments work, what monitoring is in place and how our software is deployed to production. By understanding the existing processes for monitoring and maintaining software in production, we can ensure that we deliver value to our customers and avoid problems at what is traditionally the most stressful time of a project.
We value the use of rigorous software development techniques that provide fast feedback and assurance that our code works in the way we expect it to. Where others may rely on wishful thinking and assumptions, we strive to prove our design theories are correct using pragmatic, lightweight tests. This value encompasses our wider development processes, too β for example, frequently demoing to our customer to verify that we are building the right thing.
Everything we do is delivered with a healthy dose of pragmatism. This does not mean that we will sacrifice our other values for expediency, but it does mean we avoid hard and fast rules that offer little return for disproportionate cost.