DevOps: The path, not the destination

Remember Home Ec? At one time in schools, boys took shop and girls Home Ec. We made wooden table lamps with a handle that operated like a miniature water pump. Girls made A-line skirts and learned to bake. Those days are over.

Home Ec evolved into family and consumer science, shop into industrial arts. Whatever the moniker, nowadays boys and girls at least have the freedom to do either or both.  In reality, fewer and fewer kids know how to thread a sewing machine or tune up a car. It may not matter; what people need for competencies always evolves.

In IT departments both commercial and federal, the word DevOps has sailed in. It’s a faintly hip-sounding contraction of development operations. Since the days of Fortran and punch cards, organizations have had (in the strict definition of the words) “development operations.” They didn’t always function very well.

Now, DevOps has come to apply to a style of software development emphasizing fast deliveries of small modules of functionality, and repeated collaboration with users to get software to do what users want and with few bugs. DevOps is associated with agile development.

The implication of DevOps is that those doing it are modern and cool, while those still doing waterfall development — the software development equivalent of shop and Home Ec — are antiquated and out of touch. Given the mixed record of software deployment performance by federal agencies, you can understand the strong encouragement from the Office of Management and Budget for agencies to get with the DevOps gestalt.

But the notion of “DevOps = good, regular software development = bad,” oversimplifies the difficulties of development. It’s like comparing classical and jazz or pop music and saying one is better. You can be excellent or lousy at either one. The late Leonard Bernstein tried to express this in a musical lecture when he dismissed the many adjectives — long hair, high-brow, serious — people use for classical, and substituted a more precise definition for it.

The right methodology depends on the mission, the organizational environment and the pace of change of the environment into which the software is to be inserted. Developing applications for a nuclear power plant might still work best using the older workflow models. In deploying digital services to a fickle public, many agencies are stepping into the agile, DevOps mode. The former situation tends toward stable requirements and long-term reliability, the latter on speed, flexibility and trying things.

A great PriceWaterhouseCoopers piece published a couple of years back describes the agility versus stability conflict. It says the software goals of all organizations should include “antifragility” — less vulnerable to catastrophe. This and many other expert pieces I’ve read on the whole question emphasize not so much how to code but rather how to orient the organization so that people collaborate and get used to repeated incremental change.

Any time an organization adopts a new methodology or — heaven forbid — tries to change its culture, its leadership must be careful to distinguish the prescription from the goal. DevOps just happens to be an effective way to the goal of better software, delivered faster and more reliably.

Copyright © 2024 Federal News Network. All rights reserved. This website is not intended for users located within the European Economic Area.