Some of you reading the posts in this series might be thinking, “This all sounds a bit familiar”. And you’d be right.
“AI” coding assistants built around Large Language Models may be a relatively new technology, but we’re discovering that the best ways to use them are decades old.
Some teams have been working in small batches – solving one problem at a time – and testing, reviewing, refactoring and integrating their code continuously for decades.
Some teams are cohesive, cross-functional and largely autonomous – adapting and self-organising to address problems in the moment, instead of waiting for permission from above.
Some teams have been using examples to pin down the meaning of system requirements, and driving the design of the software directly from executable interpretations of those examples (you may know them as “tests”), since the 1950s.
One software development methodology in particular encapsulates all of the principles and practices we’ve explored in this series: eXtreme Programming (XP).
XP was born in the mid-1990s, and is most closely associated with Kent Beck. It’s a shining example of what can happen when you get the right people in the room.
It was undoubtedly the main inspiration for the Agile Software Development movement that started at a ski resort – where else? – in 2001, but was subsequently somewhat overshadowed by it after. But for many of us, when you say “Agile”, we still hear “XP”.
If you look carefully at the group photo on the Agile Manifesto’s home page, and check the original signatories, you’ll see that most of the people attending that summit – like Ron Jeffries and Ward Cunningham – were closely involved with the early evolution of XP.
In this new age of “AI”-assisted programming, XP is experiencing something of a renaissance – although many folks currently rediscovering the approach might not realise it already has a name. So let me fill in the blanks.
eXtreme Programming brought together key lessons about what works and what doesn’t in developing software learned by programmers over the preceding 40 years.
Core to the technical practices of eXtreme Programming is a micro-iterative process we now call Test-Driven Development (TDD).
In TDD, we work in small steps – solving one problem at a time. We specify using examples (tests). We test continuously. We review the code continuously. We refactor continuously. And when we’re refactoring, we make one small change at a time, testing and reviewing the results at every step.
Many of us build version control into the TDD micro-cycle, committing changes whenever the tests are all “green”. Some even revert if any tests fail and try again, perhaps taking a smaller, safer step. And many of us push our changes directly to the trunk branch multiple times an hour, rather than waiting until a feature’s been completed.
XP teams will often work in pairs so that, as well as having an extra brain for problem-solving and providing direction, there’s also an extra pair of eyes reviewing the code as it’s being written.
XP teams tackle architecture in a highly collaborative and ongoing fashion. Always striving for simplicity, XP teams will have short design sessions throughout the day, using simple modeling techniques to visualise, understand, plan and communicate software design. (A very common misconception about XP is that teams “don’t do any design planning”. They’re doing it all the time.)
XP teams tend to be small and cohesive, encapsulating the skills needed to deliver customer requirements end-to-end whenever possible.
They are also highly autonomous and self-organising, making decisions together when they need to be made, instead of sending them up the chain of command. In XP, the team – working closely with the customer – is in command.
eXtreme Programming works by minimising uncertainty, and it does this by minimising the amount of work in progress – solving one problem at a time, maximising focus and minimising cognitive load – and maximising objective feedback. Basically, they turn the cards over one at a time, as they’re being dealt.
In terms of team productivity, the small batch sizes, fast feedback loops and continuous – rather than phased (blocking)- design, testing, review and integration tends to minimise bottlenecks and maximise the flow of value. Skilled XP teams tend to have very short delivery lead times, produce very stable releases, and are able to sustain the pace of delivery for years on the same product.
When we’re using “AI” coding assistants, uncertainty is even more in play. We can minimise uncertainty in pretty much exactly the same kinds of ways. Smaller steps with less ambiguity, and faster feedback.
Many “AI”-assisted developers are learning that a process like TDD can significantly reduce the “downstream chaos” that DORA data shows plagues most teams using these tools.
Working one test case (one example) at a time reduces context – the LLM equivalent of cognitive load – and specifying with tests minimises semantic ambiguity, dramatically reducing the risk of models misinterpreting our requirements.
It also gives us many opportunities to test (and re-test) the code in smaller feedback cycles, as well as many more opportunities to review generated code and refactor – again, one small step at a time – if there are problems (which there will be, and often!) We can use a process like TDD to keep the model on a very tight leash.
Combine TDD with merciless version control – commit on green, revert on red – to keep the code base on the path of working (shippable) software in every small increment – and do frequent merges to the release branch, and you have an approach that is, in most key respects, eXtreme Programming.
You can call it “eXtreme Vibing”, if you think that will look better on your CV.
Codemanship's Blog 