DevOps Isn't Dead, but It's Not in Great Health Either

Kent Beck (of "Extreme Programming" aka "XP" fame) is a joy to read. He thinks really deeply about software, and takes things to interesting extremes. But he's very pragmatic about it.

Then XP becomes the Agile Manifesto. At this point, we're getting a bit silly but it's still an interesting idea.

Then we start talking about paid "agile" consultants teaching big companies. Maybe it's still better than the alternative. And some of the best ideas, like unit testing, seep into the culture. (80s and 90s project planning and testing could be terrible in ways any undergrad could fix today.)

And then, eventually, we have so-called "Scrum" being run by someone who learned about it third hand through a game of telephone. Every truly successful revolution lives long enough to become a gross and broken status quo. And so the cycle repeats.

That said, Kent Beck is still writing, and he's still delightful to read. I knew his favorite themes 20 years ago, but sometimes I pick up his stuff and find a clever new insight.

As a sysadmin, I feel attacked. DevOps is not a modern used version of the sysadmin. It's a different shade with different expertise to apply to a slightly different field that what a sysadmin does. I've seen devoperators who don't know how to manage a server and I've seen sysadmins who don't know how to write scripts. One is not more modern or superior than the other.

This is infuriating at times. We ingest a lot of data from 3rd party systems of our clients for things like KPI analysis, the devs¹ provided various APIs for submitting data and we can read from various others, but good old reliable dumping-CSV-files-to-us-via-SFTP is still what most clients want to do.

I have no problem with this², BUT the amount of times I end up talking to clients (sometimes large banking organisations) that don't have anyone available who actually understands SFTP/SSH amazes me. We often resort to password based auth because they simply don't get private/public keys (or claim their other infrastructure just doesn't work with them).

----

[1] used to be a full-stacker myself, but I've let large parts of my skillset rot so except for when working on legacy issues I'm a more specialised database/data-processing/infrastructure fellow these days

[2] other than, of course, dealing with bad CSV output implementations⁴ or just all the combinations of how to encode problems like quotes, eols in long stings, and so forth. JSON³ is starting to get some traction as an alternative which is handy because being more modern it is more rigidly designed compared to the mess that CSV is due to decades of implementations being slapped together in an it'll-do-until-it-doesn't manner.

[3] Don't expect structured data though: the clients & 3rd parties I deal with are sending the same simple table format data, with multiple files for us to join together later when there is more complex structure, that they would send as CSV, just using the more bloated format⁵ for the gain in reduced encoding confusions.

[4] not quoting values containing the separator character or otherwise escaping it, not dealing with existing quotes when values do get quoted, etc. - if you'd be surprised to find CSV is far from a solved problem today, then prepare to be very surprised!

[5] Don't get me wrong when I mention the format bloat: this _is_ a good trade for easing the other issues. Bandwidth & storage (or compute resource for compression) are more than cheap & fast enough to make it so.