This is the fourth and final post in my series on the Trainline way of developing great software products at scale. If you haven’t already done so, you may want to check out the others:

PRACTICES

All of the Trainline Way of developing software is put into action through great practices. To have great software, takes great coding practices. It simply would not be possible to move fast enough if we were not able to trust our engineers to produce code of the highest quality. Any kind of centralised policing would result in a stifling bottleneck.

To achieve this, we believe that it is vital to instill in our team the need to take professional pride in one’s work. Everyone knows that they have the permission to do things the right way and not to cut corners.

Below, I will highlight the key practices which we insist upon across the team.

WE REVIEW CODE VIA PULL REQUESTS

The benefits of reviewing code via pull requests are:

1. code quality is checked early and often in a manageable and sustainable way
2. no piece of code ever reaches production without at least two people having seen it
3. knowledge is shared and siloes are minimised

Carrying out code reviews is essential as it ensures a high standard of code quality and consistency across our code-base, spreads knowledge and distributes ownership of our code base, facilitates an environment of continuous learning and growth for our engineers and allows us to catch bugs early on before they get into production.

WE PAIR SMARTLY

Pairing is a natural extension of code reviews, as it serves the same principles and addresses the same challenges. When working on a particularly complex feature, it can be very hard to review by someone external to the project. Pairing eases the process and dramatically accelerates the review and improvement of the code. Taking it a step further, code pairing is of a tremendous value when it comes to business-critical features or laying the ground work of a new system.

Sharing knowledge in a squad is essential to avoid bottlenecks and single points of failure and to help every team member deepen and broaden their expertise. Pairing is a great tool for this. But experience has shown that pairing indiscriminately can be overkill.

We don’t always pair. We’re smart about it. We encourage pairing particularly in the following contexts:

• for complex work
• new work where sharing knowledge is particularly important
• for training / on-boarding

WE ADVOCATE TEST-DRIVEN DEVELOPMENT (TDD)

Contrary to older approaches, which considered testing as a later stage in the development cycle, completely distinct from the development itself, TDD radically turns this premise on its head. TDD demands a different mindset of developers. Rather than thinking: “how do I test this code?”, TDD requires developers to start with the question “how can I develop this feature to pass these tests?”

Development starts by writing a test for a given feature which will fail — since the feature hasn’t even been coded yet — and then writing the code to get the test to pass. Besides the obvious quality benefit it provides (e.g. fewer bugs, organized code, interfaces, dependency management), tests are a key asset as they provide a living documentation of the code. From the test, we can see what is expected from a piece of code which has the added benefit of easing refactoring as well.

NO WORK SHOULD EVER BE DONE WITHOUT A JIRA TICKET

Every piece of work should be represented by a JIRA ticket in order to maintain transparency and assess priorities of work being carried out. This ensures that we manage our work efficiently and avoid the “whoever shouts latest and loudest” trap.

WE TREAT STAGING LIKE PRODUCTION

We consider other teams when merging into shared environments. We should be sure that a change going out to production will work as expected. The staging environment is as similar to production as practical to support effective testing and reduce surprises. We also need to remember that our colleagues will be blocked if we don’t immediately jump on any issues we see in staging, as issues there will block the path to production. We also host and test the alerting and monitoring systems in staging to verify operational supportability.

WE CARRY OUT REGULAR CHAOS TESTING

Currently via Quarterly ‘Game day’ approach to make sure that our software and systems are production ready.

We build resilient software and systems. We ensure that we are not surprised by ‘edge case’ events e.g amazon instances dying, slow response from dependent services, or running out of memory/disk space. We regularly run activities to simulate the exception conditions, and observe how effective our resilience is. These tests are currently ‘game day’ tests run in staging on an approximately quarterly basis. We should incorporate any genuine production issues we have seen in this testing. We are looking at how to improve this.

These are the aligned software practices that we expect every member of our Engineering team at Trainline mto adhere to.

Haran Rasalingam is Trainline’s Agile Coach.