How I Explained DevOps to My Dad

I was hanging out with my dad recently when an old question came up yet again: “Tell me again, son, that software you sell, what does it do?”

Oh no, I thought. Here we go again. So I launched into my spiel, explaining software development lifecycles and constraints, and how release automation tools and Service Virtualization software work to smooth all that out.

I explained how we help the many different teams that contribute small pieces to large software performs do their jobs simultaneously instead of in a long, tedious, slow sequence. They can work in parallel because we provide machine behavior modeling.

On and on I droned, app-dev this and app-dev that. His body language told me I was either losing him or that his scotch needed a refill, or both.

“I don’t know much about that. I just want to build something,” he said.

An A-Ha Moment: Developers and General Contractors Both Battle Constraints

This was my a-ha moment. You see, my dad is a construction guy. His entire life has consisted of building things. He was a general contractor in charge of constructing banks, schools, warehouses and many other types of commercial buildings.

My dad understands project planning. Then, seeing the connection between my work and his, I started in with a new sense of purpose.

“Well, our software helps folks build things, too, except the things are software applications that companies provide for employees partners and customers,” I explained.

And then, before we went down another rabbit hole that might require more scotch, I shifted the context to his experience: “Dad, do you know how you would make more money when you finished a project early?”


“Yes,” my dad said. “My teams knew about time-saving techniques that saved money for the customer and turned out a higher-quality product.”


“That’s what we do except for software,” I said. “You just can’t pick it up or see it.”

Getting Around Project Constraints

I asked my dad to visualize one of his project plans in a Gantt chart. Like every piece of software, each construction project has predecessors and dependencies.

“You survey, break ground, pour a foundation, build infrastructure and then finish out in a construction project, right?” I said. “What if one of those steps gets delayed by weather or lack of materials? What if a subcontractor doesn’t show up?”

Dad was with me now.

“Then the project step is behind schedule and we find ways to squeeze more work into the remaining days,” he replied. “School starts on a certain day and we have to be out and hand over the project before the staff and kids get in the building.”

That’s it. If you have the right tools, the right visibility of the project from end to end, and the right experience, you figure out a way to get the job done without sacrificing quality.

A Simple Explanation: Better, Faster, Cheaper

That’s really the long and the short of what we do, and my dad didn’t need to hear about how transport protocols and data work back and forth in enterprise applications. What we do is to help companies build better software, faster and cheaper.

That was the explanation my dad, the general contractor, needed to hear: Better, faster, cheaper.

From an SDLC perspective, achieving that simple goal requires resourcefulness and a willingness to consider new ways of doing business.

No company has unlimited budgets or people to meet project schedules. But you’d be surprised by the new ideas that can help. Try popping up your gopher h*** every now and then to listen to an innovator or expert who has tried them.

This post originally appeared on