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.
Leadership is neither assigned nor selected. People choose whom to follow and a leader thereby emerges.
“The led must not be compelled, they must be able to choose their own leader” - Albert Einstein
We always have a choice. We may not like our options. We may feel we are choosing the lesser of two evils, but nevertheless, we follow at a minimum because we choose not to do otherwise.
“The man who lets a leader prescribe his course is a wreck being towed to the scrap heap.” - Ayn Rand
It is nearing the end of the year and we at LeanDog are wrapping up our fiscal year. We're looking at the potential tax benefits of spending some of our reserve and we're mulling over other ideas related to the spend of money. We are not, however, discussing our bonus objectives. We aren't discussing them because we don't have them. I, for one, am happy that we don't.
Plenty of companies have bonus objectives. Many of those companies are spending a great deal of time (and money) trying to make sure that those objectives are met (or at least appear to be met). To some, this sounds like a good idea. To me, it sounds like rampant dysfunction.
A client was looking for a way to introduce code quality standards to their development teams. There had been a few meetings prior to our involvement. The prevalent line of thinking was to draft a standards manual for dissemination to the teams. This would consist of a comprehensive set of rules and clear specifications to which all teams need comply.
Davey Brion wrote a post not too long ago warning developers about the dangers of specializing in a particular technology.
Davey concludes his post with the following paragraph:
"Keep your ears, your eyes and your mind open. If you notice that a group of people gets excited about something new, then figure out why. If you notice that something appears to be working well for others, then figure out why. If you notice an increasing stream of criticism on the technology you’re using, then figure out why. You’ll need information like this to make well-founded decisions about your future."
A former coworker of mine, Jim Highsmith, has recently written an article on The Financial Implications of Technical Debt. Jim states that recent studies indicate the cost of technical debt is near $1 trillion in the U.S. I would like to see these studies. I do know that not too long ago, Gartner released a report indicating that the worldwide cost of IT Debt will be $1 trillion by 2015. Regardless, the point he makes is still valid - technical debt is egregious.
Jim states, "Unfortunately, by the time many organizations are paying attention, all the solutions are bad ones: 1) do nothing and it gets worse, 2) re-place/re-write the software (expensive, high risk, doesn’t address the root cause problem), or 3) systematically invest in incremental improvement."
Of these three (bad) options, I think the second is often a better choice than the third. The first represents failure to make a necessary decision.
Here is the slide deck to my SCNA talk, "Training Software Professionals, Just What the Doctor Ordered". In the past, my slide decks stood on their own. That is, you could thumb through the deck and easily glean all the key points of the talk. But I am trying to move away from that presentation style to one where the slides offer visual support, but the speaker (me) tells the actual story.
The following just hit my inbox. It is a post on the Software Craftsmanship Google Group.
My question is, "what can be done to fix the reputation [of elitism] and change the conversation before craftsmanship is deemed irrelevant"?
As a craftsman I am dedicated to improving myself; and therefore I realize I am deficient. As someone who is admittedly deficient, I am not interested in pointing out someone else's deficiencies.
In general, whenever someone asks "what can we, as a group, do to ...", the best answer is going to be of the form: "Each of us, as an individual, should ...".
So, to deal with perceived elitism, each of us as individuals should remember that we are not elite.
During the speaker panel at SCNA this past weekend, Chad Fowler (@chadfowler) asked, "How many projects fail because of the code?". Given the context, I assumed he was making the point that projects fail due to business issues, not code. The room was silent. While one might have assumed this meant the entire group thought it rhetorical, I concluded everyone agreed with Chad. Projects fail not due to code, but due to business issues.
A recent article by Tobias Mayer has been getting a lot of attention. "The Scrum Compliance" is an accounting of why Tobias is moving on from the Scrum Alliance. This article is not the first on the ugliness that has become the Scrum Alliance.
Esther Derby put together a nice post on the importance of design for a web site in which she asks, "Are we aiming too low?"
Agile methods manage business risk. They can bring back enjoyment and pride in work for development teams. For the people who use our software, they make work life maybe less frustrating, because the software isn’t buggy, and maybe a little easier because the software does what it’s supposed to do. But I think we are aiming too low. Can we also make software a pleasure to use?
