We’ve helped a number of organisations successfully adopt pair programming, giving their teams the ability to increase productivity, improve knowledge sharing and enhance the quality of their software.
Test Driven Development is the practice of writing a test for a piece of required functionality, before writing any implementation code. This test should fail when first run, and then, you write the code to get it to pass. It doesn’t have to be the most perfect code, just so long as the test passes. Once it does, you can then safely refactor your code.
A pipeline is a set of steps that your code takes to get from a developer’s local machine through to a production environment. This pipeline is managed by a tool that lets you define these steps, what they do, and how and when it proceeds onto the next one.
It can be challenging to get sufficient infrastructure set up to enable you to practice Continuous Delivery, but the biggest challenge may be changing the way you (and your team) think about releasing software.
Software anti-patterns are a well covered topic, but I thought I would highlight some of the ones I’ve encountered most frequently. These may seem obvious and at times innocent looking but make no mistake, they are sinister and will sabotage your efforts to add features to a codebase. I’ve gone ahead and made up my own names for some of the more specific anti-patterns.
We have an almost continual dialogue on how to improve the quality of the software that we’re involved in delivering. One of the conscious decisions that we’ve made is that we don’t make use of a dedicated QA or test role.
One of the riskiest parts of software delivery is the production deployment.
The value of a test suite can easily go down when complexity goes up, and a lot of the time this complexity can be prevented. There is a great discussion on SO about this.
We love writing tests at Made HQ. They are part of the foundation on which we work to provide our clients with stable deliveries. We work fast and deploy daily so we test vital paths of our applications using feature tests. We also unit test, albeit less, when we need to cover a range of edge cases.