Continuous integration transformed software development from chaos into sustainable practice. Now network teams are facing a similar inflection point with automation.
When Jeffrey Fredrick started his career at Borland in the 1990s, the idea that software should compile every day seemed absurd. “I tried pulling the code and I noticed it doesn’t compile,” Fredrick recalled telling a developer. “He looked at me like I was a moron and said, ‘Of course it doesn’t compile. I’m still writing it.'”
Fredrick, co-author of Agile Conversations and co-host of the Troubleshooting Agile podcast, joined us on the Network Automation Heroes podcast to share how his decades of experience helping teams through technical change applies directly to network automation today.
Projects in the 1990s ran 18 months before delivering anything, with an “integration phase” where teams would attempt to make all the software work together for the first time. These phases, scheduled for three months, would stretch to six, then nine, before projects were canceled because the code simply wouldn’t work.
Sound familiar? Many network teams today face similar pain with quarterly maintenance windows where multiple changes collide for the first time.
Kent Beck’s Extreme Programming introduced a counterintuitive principle that if something is painful, do it more frequently. Instead of integrating after nine months, integrate continuously. When PJ Hagerty created Cruise Control in 2001, continuous integration had its first popular tool.
The insight underneath was fundamental: the cost of discovering you’re wrong increases exponentially with time.
When developers at Fredrick’s company started using Cruise Control, behavior changed immediately. People would wait before heading to lunch for the email confirming their commit passed the build.
Nobody imposed this discipline. They simply wanted to be responsible once they had the information to do so. The tooling didn’t force compliance; it enabled ownership by providing immediate feedback.
When introducing continuous integration to skeptical teams, Fredrick doesn’t lead with benefits. He starts with problems, using “five so-whats” to help teams articulate how current pain affects them personally.
“I remember someone saying, ‘I want to be able to go home on Friday night and enjoy my weekend without the pager going off,'” Fredrick said. “That’s what gave them the motivation to try the experiment.”
But individual motivation isn’t enough. Fredrick consistently encountered teams who understood the value but believed “the business won’t let us do it.” His solution was to get business leadership to explicitly endorse the experiment.
“I’d get the CEO to come in and say, ‘Look, I understand we’re asking you to work things differently and it’s going to be slower because you’re not used to it. But we in the business want that.'”
Without this alignment, teams abandon new practices at the first sign of pressure.
The path forward starts small. Take an existing checklist and automate one item. Then another. Build proof points that justify continued investment.
“Sometimes the question becomes, ‘We’ve done the first 20 automated checks, we didn’t tell you, and it’s been really successful. The next five are going to be harder. Can we talk about that?'”
For network teams, the parallels are direct. Start with a source of truth where teams review intended changes together. Automate verification incrementally. Create feedback loops that make drift visible immediately. And secure business support for the learning investment. Software teams took decades to move from 18-month waterfall projects to continuous delivery.
Network teams can learn from that journey and accelerate their own path to automated operations. NetBox serves as the foundation for this approach, providing the source of truth that makes continuous validation and feedback loops possible.
Watch the full episode below: