The emergence of AI coding assistants such as GitHub Copilot, Amazon CodeWhisperer, and Claude 3.5 Sonnet has stirred debate about their long-term impact on software development. I’ve been in this game a while, which means I approach software innovation with a healthy dose of scepticism. I have seen lots of fashion trends — waves of developer productivity tools — some impactful, most not. From 4GLs to IDEs to low-code — each one promising to change the game, then fading into the background. Sound familiar? Every year there is somebody claiming they have a tool that can write your code for you. Is AI just the latest wave? I wondered if looking back at those old patterns — the hype, the crashes, the survivors — might tell us where this one’s going. Do those patterns from history tell me anything about the current trajectory of AI coding tools? The answer? Yes and no. Which, if you’ve ever worked in software, is probably the only honest answer you’ll get.
Continue reading
Tag Archives: technical practices
What Software Development Can Learn from Double-Entry Bookkeeping
Double-entry bookkeeping revolutionised business by introducing a self-checking system of financial integrity. In the world of software, Behaviour-Driven Development (BDD) does something strikingly similar — pairing each feature with a clear, testable description of how it should behave. Double-entry bookkeeping and automated software testing might seem worlds apart – one emerged in Renaissance-era accounting and the other in modern software development. Yet conceptually, they serve a similar purpose: both introduce systems of checks and balances to ensure integrity and accuracy in their respective domains. In accounting, double-entry bookkeeping requires every transaction to be recorded in two accounts (debits and credits) that must balance, creating an internal self-checking mechanism. In software, automated tests act as a parallel record of expected behaviour, continuously verifying that the code produces the intended outcomes. This post explores how a 500-year-old accounting innovation revolutionised financial record-keeping and how its spirit lives on in the way we write and test software today.
Did HeartOfAgile emerge from PDCA?
I don’t know if it was Alistair Cockburn’s inspiration but I’ve noticed a striking similarity between Cockburn’s HeartOfAgile and the plan-do-check-act (PDCA) cycle of TQM.
Continue reading
Going back to basics with Agile, what would we find? The Heart of Agile
In a world with non-software Agile and Agile at scale, what is Agile? I think Alistair Cockburn has hit the nail right on the head with his recent HeartOfAgile.
Continue reading
Make BlackOps development the Corporate Standard – Embrace Microservices
Contrary to how they are perceived in the media as lumbering dinosaurs, most large organisations have loads of clever people and good ideas.The trouble is these organisations can’t deliver against the ideas. The answer is not “Blue Sky” R&D departments or “BlackOps” teams. The answer is to make the BlackOps approach standard; create an innovation platform built from microservices with new services deployed swiftly into production.
Continue reading
Test driven architecture – use your tests to inform architecture
As test-loving development teams, we are all painfully aware of the complexity of getting an application into the zen state of development – quick, test-driven red/green feedback for developers, software designs that are functionally on-the-money from a test-led, “outside-in” approach (from BDD), and a nigh on seamless continuous delivery process as a result. Very few teams achieve this, and those that do are frequently gifted a green-field project in which to engender them.
As test-savvy teams, when tests start to hamper the release process, we often assume our approach to testing needs an overhaul, but that might not be the case. Here we look at the role of architecture in test-driven applications, and examine whether we should listen to our tests to examine our macro design.
Continue reading
Don’t use the Formal User Story Format for Minor Modifications
Kim Daubney asked what to do when the story isn’t a new requirement but a UI change. Kim wanted to know if the “as a, i want, so that” format is still required? Short answer is “no”.
Continue reading
Seven Things to do When Starting Specification by Example with Cucumber
I was asked “What to do in terms of training and practice when starting to use gherkin to define requirements?” Although I’ve written quite a lot of material on Specification by Example I haven’t written about how to start doing it.
Continue reading
I always work with a Technical Lead. Always
They might be called an Architect or a Tech Lead or just “Bob” but I always work closely with a senior technical person.
Continue reading
Five things to do when people don’t to see the value of automation
Not everybody sees the value of automation, specifically test automation. But I believe effective software development demands test automation. What to do?
Continue reading