At Equal Experts all of our developers follow what we call rigorous development practices.

A number of these practices were popularised in the software development community by the Extreme Programming methodology, but we find they are absolutely fundamental to ensuring quality and reliability of code no matter what software development process you decide to follow. They are simply good practice and should be followed by any team developing software in a professional environment.

Test automation

The majority of testing should be automated. Asking people to manually step through a test script time and time again provides zero value and can actually cause more delays when bogus issues are raised. This doesn’t mean there is no place for manual testing, humans are great at finding edge cases and exploring scenarios that aren’t coded into a machine. However, the box checking grunt work should be performed by machines.

We take a pragmatic approach based on the technology and the state of the current project. Not every scenario will be automated on every project as sometimes it’s not cost effective to automate everything. The approach you take to test automation can make or break your project. We favour a standard test pyramid approach with more low-level, fast running unit tests and just enough integration or end to end tests to give the team confidence that the various components of the architecture are working together correctly.

Ultimately your tests have to be fast to execute, can run on a developers machine and give consistent results that a machine can decide whether your code is working or not.

Continuous Integration

Build and test all your code whenever anyone checks in. This means you always know whether the latest version of the code is working or not. Each successful build creates a binary deployable artefact, which can be used to release, so you never have to go back and build anything when you want to release a change to production.

Refactoring

Writing simple code is hard, writing complex code is relatively easy. Changing complex code is REALLY hard, changing simple code is relatively easy. We focus on writing simple code in the first instance and then refactor that code when we figure out a way to make it even simpler in the future. By constantly driving for simplicity in the code base we create systems that continue to be relatively easy to change over time.

Check out and build

A developer should be able to check out the source code from the source repository and run a simple command to be able to build the software and run the automated tests. By ensuring that everyones development environment looks the same new developers can join the project and be productive on day one. We also eliminate the “it works on my machine argument” and allow developers to validate their changes locally before pushing to the central code repository.