Dave Farley is a software engineer/author/consultant, as well as a co-author (along with Jez Humble) of the 2010 book Continuous Delivery. After decades in the tech industry, Farley recently took to YouTube to share his “exploration of seven common excuses that software developers make for doing a worse job.”
It’s a compelling presentation, helped by Farley’s disdainfully calm delivery of his strongly-felt opinions. He starts by noting that flat-earth proponents are excluded from serious scientific discussions, adding that “I think Waterfall Development is flat-earth thinking for software development.
“It doesn’t work, and it tries to address only some of the problems in what are fairly naïve ways, while ignoring others.”
Farley acknowledged that’s his opinion — although backed by some data for the success for waterfall “in terms of efficiency, quality, and basic measures of success, like projects ‘Did it deliver what people really wanted?’”
And before long, it becomes apparent that there’s one unmistakable theme running through Farley’s video: his faith in the powers of continuous integration, continuous delivery, and test-driven development. Farley argued at the beginning that these Waterfall alternatives “are disruptive and challenging — but they work better.”
So if these methodologies work better, then what excuses do developers use for why they aren’t implementing them?
Merging and Managers
First, there’s Developer Excuse #1: “You can’t do serious work without feature branching.”
Yes, feature branching involves temporarily forking code so developers can optimize new features in their own separate silos. But Farley mocks the idea that “two copies of data that are changing independently of one another get easier to merge together the longer you leave them to diverge….”
Instead, it’s the Continuous Integration methodology that brings regular and ongoing checks for conflicts with the larger codebase, and Farley argues there’s proof this is better than the alternative. Specifically, Farley cites data from Google’s State of DevOps report which “says that you create worse software, more slowly, when you feature branch — or at least when your feature branches last for longer than a day.”
Farley then turns to another common excuse made for skipping things like testing, refactoring, and even prioritizing good design: “My manager says I don’t have time for this.”
Farley acknowledged that “There’s always the chance that any one of us ends up working for a dumb manager. But while I think that this can be a nasty systemic problem sometimes, I think that this is always the wrong response — trying to offload this responsibility onto other people.”
Because, in short: “We software developers are complicated in this decision.” Farley has a theory about why this is true. He lowered his voice to say pointedly that “Some of us really don’t like testing very much. And don’t really want to do the hard work of doing a good job of design and refactoring. So we pass the buck onto somebody else — the manager…”
The other cause is a lack of faith that testing and good design will speed development. But Farley argues that “You trade off a bit of extra work now for much less work later on by focusing on the quality of your work now. By doing that you dramatically reduce the amount of work spent later dealing with buggy or low-quality code.”
And about that manager? “It’s not somebody else’s responsibility to give us permission to do a good job.”
How to Improve
The video is the first in a planned monthly series for the YouTube channel of GOTO conferences, which will feature “ideas about continuous delivery, DevOps, test-driven development, behavior-driven development, software engineering and software development in general.”
And Farley clearly enjoys pontificating about how to improve your programming skills. He’s also recently launched the Modern Software Engineer’s Companion for his supporters on Patreon, according to a December blog post. Farley calls it “a kind of curated guide to what I think works in software development” in a format enabling searching and exploring.
So as the video continues, the developer excuses start to become handy foils for delivering Farley’s own thoughts on best practices. For example, there’s Excuse #3: “Writing tests is a waste of time.” Farley concedes that writing tests “is clearly more typing. But if you really measure your work by the number of characters that you type, then you’re doing it wrong.”
But then Farley goes on to point out there’s advantages beyond simply catching bugs quickly, since test-driven development also changes how the code gets structured. “Testable code is more modular, more cohesive, and has better separation of concerns” — ultimately making it easier to manage a codebase’s complexity.
Along the way, some excuses prove easier to debunk than others. Farley has a ready response for people who insist “We’ve always done it this way, and it works for us.”
“Well, that’s nice — but wouldn’t you like to be able to do better? If we never question our approach and practices, then we’ll never improve.”
And Farley is also ready to tackle the myth that “You can’t do code review with Continuous Integration.” Farley’s response? “Yes, you can. Of course, you can. Pull requests aren’t the only way to do code reviews.”
But then Farley goes even further in his critique of pulling requests as a form of code review. Inside an organization, “gatekeeping people’s commitments is slow and inefficient, and more than that, it doesn’t really teach people how to do a better job.”
Pair programming is a better solution with many advantages, Farley argues — and not just by providing a better way of reviewing code. He applauds the way pair programming involves even junior team members in thinking carefully about changes — and at the moment when they’re making those changes. “This is a much better way to learn how to take responsibility for their changes, and the importance of doing high-quality work.”
And of course, Farley then cites more data confirming pair programming’s effectiveness.