You are not doing Test Driven Development

Test Driven Development can be a business process, not just a development workflow. It can start much earlier in the software engineering process than when implementation starts and code is first written.

Quite a few engineering teams confuse TDD for doing any testing at all, but even teams that know TDD is a stronger process than that still limit its potential by confining it to an implementation workflow detail that is trivial at the level of the business or software team.

TDD can actually be a business-level methodology for successfully producing and maintaining software. As the name suggests, the “test” comes first and foremost when working on software in any way. But this does not just refer to test code that is executable on a machine. It means a verifiable description of a behaviour or process, which is actually what software is all about.

Start with a test case. That doesn’t mean do selection, planning, sizing and design first, then hand it over to a developer who might remember to try and write some test code first. It means start with a strong behaviourial description as the starting point.

Some organisations half-ass this with acceptance criteria that occasionally appear on a minority of tickets when the organisation is paying attention, but even then might be added at any stage of development. The boat has usually sailed by that point as vagueness and ingenuity seep into the project.

This behavioural description does not need to be actual test code in a programming language; that is not the point. The point is that the idea of the desired behaviour is kept controllable from the beginning. Successful software is about control, not just of machines but of meaningful processes and business behaviour. If we can’t control this, the difficulty is dramatically increased and failure becomes more likely.

Simpler systems are easier to control and they fail less often. Focusing on controlling behaviour and process from the start (whether or not you call that TDD) keeps things simpler and increases the chance of success.

Focusing on verifiable descriptions of behaviour as the primary driver of software development can control this – we are forced to produce controllable systems if we are going to consistently prove that they work in a meaningful way.

With this mindset, the shiny new technologies are suddenly less appealing, as we sacrifice control by handing it over to them, and are left with much weaker options to demonstrate and maintain the desired functionality of the system.