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: flow
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.
Disaster, rescue and recovery: Kickstarting delivery
70% of projects fail to deliver — and the cost is more than financial. Few broken programmes crash in a spectacular fashion. Most just quietly stall. You’ve got a roadmap. You’ve got people. You’ve got the rituals. But… nothing’s really moving. Instead you have sceptical stakeholders, wincing delivery teams, endless meetings and no actual decisions. Everyone is busy, but no one is sure what they’re delivering or why. Sound familiar? You’ve stalled.
Continue reading
Choosing the Right Nearshoring Location: 9 Essential Criteria
I’m based in London, UK, but I’ve had teams in South America, USA, Eastern Europe, the Middle East, South Africa, and India. Some of those locations worked for me and some didn’t.
In 2017 I opened a software development operation in Sofia (Bulgaria) for one of the world’s leading news organisations, headquartered in London (UK). Sofia met our criteria for selecting a nearshore location (and still does). I thought others might be interested in the nine criteria we used to select a nearshoring location. Particularly since I’ve inherited teams in other locations that did not meet these criteria.
Continue reading
Leaders Turn Up
I’m proud of all my teams – good people doing great things. But I’m particularly proud of my current team because it was the hardest to form, being split between London and Berlin. I formed this team by turning up. A simple message although quite painful for myself and my family. Actually that pain is part of the reason my approach works. Leaders turn up and the team appreciates that.
Continue reading
Software Management Triumvirate: Delivery, Product and Technical
I view Delivery, Product and Technical as the three legs of software management stool. I have people responsible for these elements at both programme and project/team level.
Continue reading
PDCA – Plan Do Reflect Improve. Um, sorry, I mean Check Act
I’m a huge fan of the plan-do-check-act (PDCA) cycle. It was originally intended for process improvement within manufacturing but I now see it everywhere. But, being an Agile kind of guy I wish Deming had put “Reflect” and “Improve” into the name.
Continue reading
Are Sprints Just a Way to Organise Releases?
Are Sprints Just a Way to Organise Releases?
I’m increasingly convinced that some teams cling to Sprints / Timeboxes because they facilitate release planning. A Sprint = a mini-Release = real simple. However, continuous delivery means these “Sprints” are not real Sprints.
Continue reading
Contracts do not fix incompetence
“Contracts are the least powerful in getting people to do something. A contract does not fix incompetence.” Not my words, they come from Rajesh Mathur, but I completely agree.
Continue reading
Albert Einstein would have liked Retrospectives
I believe Albert Einstein would have liked retrospectives.
Continue reading