I don't think we have five years before agentic coding becomes the mainstream context in which professional software development happens. I think we're talking about two or three. Possibly less.
If that sounds alarmist, I'd ask you to consider how it would have sounded in 1983 to tell a mainframe developer they had about eight years before their core expertise became a niche. Or in 1994 to tell a desktop developer they had about four years. Both of those statements would have seemed extreme at the time. Both were accurate.
When leaders ask teams to "go faster," they're usually not asking for better outcomes. They're asking for more output. More stories delivered. More code shipped. More visible progress.
Implicit in that ask is a pretty big assumption: that we already know exactly what needs to be built, that the plan is correct, and that execution is the only thing standing between us and success.
So "go faster" becomes shorthand for "execute the plan harder."
That's where things start to go wrong.
The problem with "fail fast" is that it too often becomes "move fast." Failure is hidden or spun as success, speed is rewarded, and the learning part gets lost entirely. At its worst, "fail fast" is an excuse to rush into the next thing without pausing to understand what just happened.
What I want to promote instead is Observe Often. The shift in language is intentional—when we say “observe,” we bring focus back to what matters: seeing, measuring, and learning from what we do. And “often” reinforces frequency over haste. It’s not about reckless speed; it’s about small, deliberate moves and frequent feedback loops.
When I say I’m joining Test Double as their new VP of Delivery, I’m not just making a career move—I’m making an alignment move. This is a company that already values the things I value. They’ve built a strong culture, a strong team, and a strong set of practices. I’m not joining to overhaul anything. I’m joining to help make something great even better.
Today, I’m excited to announce the beta launch of Collaboration Contracts, a lightweight app designed to help teams—especially distributed ones—quickly define and manage their roles in decisions. Whether you're using it to bring clarity to one-off decisions or baking it into how your team operates every day, the app is built to support alignment, accountability, and smoother collaboration.
The bottleneck of developer speed is disappearing. Agentic systems can produce robust solutions quickly in ways that would have taken a team of humans weeks. The friction that made "build it small so you can change it easily" such critical advice is evaporating.
But the principle behind small steps was never really about code size. It's about maintaining optionality and creating feedback loops. That part isn't going anywhere. It's just shifting in emphasis.
I don't think we have five years before agentic coding becomes the mainstream context in which professional software development happens. I think we're talking about two or three. Possibly less.
If that sounds alarmist, I'd ask you to consider how it would have sounded in 1983 to tell a mainframe developer they had about eight years before their core expertise became a niche. Or in 1994 to tell a desktop developer they had about four years. Both of those statements would have seemed extreme at the time. Both were accurate.
I was recently asked to answer a question on Quora about the challenge of keeping up with change in a software project. The answers were a resounding cacophony of “yes” - change is a real problem in software development.
Inspired by discussions with Jess Kerr and others, I took a different stance. Here it is:
A cluster of parameters often indicates an object in hiding. By creating a Parameter Object, you are making the code more flexible and you may discover a new object that was hiding in plain sight. In many cases, not only will you end up moving the parameters into a class, but you very well may discover that some of your code will move into the class as well. In this way, parameter clusters can be an indication we have a Single Responsibility Problem.
I was asked to answer the Quora question, “Why is the Agile model the best”.
I’m not comfortable with the notion of “best”. Maybe “better”, “leading”, or “fit for purpose”. But most of this is so contextual and ephemeral, I tend to avoid the label “best”. That nit-pick aside…
Agility focuses on working in teams together with the customer to deliver high-quality working software in rapid cycles.
The debate over comments in code is ongoing. At least once per year for the last 30 years, I’ve been involved in a discussion on the subject - often accidentally and reluctantly. To be honest, my perspective has changed over time. I used to comment every method, I used to comment any line of code that was “weird”, and I used to comment any blocks of code that were too complicated. Today, I rarely comment, if ever. Over time, I’ve come to realize that most comments are unnecessary.
This blog post is inspired by another Quora question; “What metrics do you use to track Agile Efficiency?”
To begin with, I want to state that if I had to choose between efficient and effective, I’d choose effective. Efficiency is often about output (how many widgets per hour), whereas Effectiveness is often about outcome (was the purpose consistently met).
Agility is about responding to change. Efficiency is achieved by driving out variation. An over-focus on efficiency will lead down a path of standardization and control, making for a less agile system.
That said, given the question was specifically about agile efficiency, I’d look at a few things - Throughput, Cycle Time, Deployment Frequency, and Mean Time to Recovery.
Today’s offering is another post inspired by a question on Quora about when to refactor away duplicate code.
The specific question was, “What is the limit for duplicate code to start refactoring?”
I took this to mean, “How much duplication needs to exist before you should refactor it?”
And I’m not sure that’s really a great question. So I decided to start with clarifying what duplication needs to be cleaned up and then when might that happen.
For me, refactoring is when we change the implementation of a piece of code without changing the behavior. That’s the entire definition - Change the implementation, but not the behavior.
As a result, I will generally not refactor code unless it has a solid set of tests around it. If I see code that needs refactoring, but has insufficient tests, I will add character tests.
I recently worked with a team on a fairly significant refactoring. I paired with different team members each day over a three day period as we moved code around, pushing responsibility into other classes, reducing complexity, and make the code more expressive. On the fourth day, I put together some notes on the things we saw and general guidelines for the team to keep in mind. Nothing herein is new to the community, but it might be new to you.
