s19e10: Hallway Track; DOGE; Efficiency; COBOL; Give None of These Things; Context, Not News
0.0 Context Setting
Wednesday, 28 May 2025 on DL786, an Airbus A321NEO cruising at 35,000 feet and an airspeed of 527mph.
I’m heading out to the Code for America Summit in Washington D.C., where I’ll be part of a panel on procurement this Friday. I can’t link to the panel because the website is stupid.
On Monday 2nd June I’ll be having an impromptu meetup in D.C. in the evening once I figure out a venue - drop me a line if you’d like to come along.
I have at least three draft episodes lying around, and more fragments of episodes. It has been hard to get something finished and sent. But, here we are!
0.1 Events: Hallway Track is Back
Registration for Hallway Track 012: The Thing About COBOL opens on Thursday 29 May at 10am Pacific / 1pm Eastern.
We’ll have Marianne Belloti, Mar Hicks, and Clive Thompson talking about COBOL! Here’s the show blurb:
That computer system you hate that’s also really old? There’s a fair chance it’s powered in some way by COBOL, the programming language that people love to hate, and if it were a person, would be hitting retirement age.
COBOL sucks, right?
But the things you hate don’t suck because of COBOL, do they? And anyway, wouldn’t a 60+ year old computer language be terrible because new things are always better? All those things that suck, don’t they run on outdated mainframe technology sold by that company your dad’s dad said nobody would get fired for buying?
Come to this Hallway Track to talk with three wonderful human beings and experts about topics like:
- no, things don’t suck just because of COBOL;
- no, 60+ year old computer languages aren’t irredeemable;
- who would have thought that the people and processes are as important if not more important than the technology used?!;
- the trade-offs between reliability, maintainability, and upgradability;
- mainframes are pretty neat, actually; and
- how everything is always slightly more complicated than you might think.
25 spaces only. Register for Hallway Track 012: The Thing About COBOL.
1.0 Some Things That Caught My Attention
I wrote this so long ago I can’t remember when I wrote it.
1.1 Fine, Let’s Talk About DOGE
Or not. Unsurprisingly, I’ve been having a bunch of conversations with people about DOGE and what the DOGERs say they’re doing / are doing / say they plan to do.
There’s been a few thoughts bouncing around in my head that I want to get down.
One of the hardest things to do in an organization is to choose something to focus on, which necessarily means saying no to other things. There will be many things you will have to decide not to do. What DOGE has is, for lack of a better description, a ruthless focus on efficiency. (Points for noticing that the primary focus of government isn’t to be efficient). But when you are ruthlessly focussed on efficiency, or ruthlessly focussed on something, the degree of your ruthlessness, what might be your sociopathy, the degree of what in some senses might be your lack of enterprise fucks, becomes something that can be quite scary from the outside.
A ruthless focus on efficiency means that you will say no to other things. You will do it, for example, a bit like this.
You will have a mandate for making something like “Social Security”, which is a big thing made up of lots of small things, “more efficient”. What DOGE has done -- and I think this comes about by paying attention to the name -- is that it’s completely integrated in terms of technology being the means to achieve efficiency (again, whatever that is).
You will make ruthless decisions, like this:
- You will want to “modernize” the entire system, which is a big tangled system
- You will want to do do it quickly
- You will cut, cut, cut and make decisions to hit that date
- You will change your requirements, which means changing policy.
In other words, you are completely happy with changing what the system does.
Most people are not happy with that because most people find saying no awkward. This is where the sociopathy and not-giving-a-shit comes in.
Normally when you have a giant system that tens of thousands of staff use and then tens or hundreds of millions of people use and you want to “modernize” it, dealing with scope is super difficult if you want to keep people happy! The safest way for you to “modernize” would be for example to write a whole bunch of tests to the degree you’re happy with the risk of what might not be caught, and then developer and run the new thing alongside the other one and make sure the results are the same.
That would take a long time, but it would definitely be safe.
But at the end of that, all you’ve got is a system that is more “modern”, and does exactly what the other ones does. Many people will be upset about this, because if you’re going to spend a bunch of time and money, then why aren’t they getting something better that does more?
(Well, they are getting something better: it’s just that the things that are supposed to be better are hidden and more infrastructural, probably, and hopefully those changes make it easier for people to get those wonderful features they have ideas for)
The feature requests don’t stop. The requirements don’t stop. Scope will keep increasing because of course it will keep increasing: we will think of better (hopefully), different ways of doing things. There will always be more downstream requirements from legislation and so on.
And even if not legislation. This applies to the private sector as well as the public sector. If you’re making something for people, then those people are definitely going to have an opinion. If you are aiming to meet needs, needs are not necessarily static. The needs might not change quickly or frequently, but they will change because, well, time. Things that happen cause other things to happen.
Elon and co will just cut. They have a ruthless mindset and they’re enabled and reinforced by a ruthless mindset and, crucially, a mindset that is also cruel and doesn’t care. Also an ideological mindset that just plain doesn’t believe most government services should even exist in the first place.
One of the reasons why modernizing systems is difficult and hard and takes time is figuring out what they should do and when because people also in general do not like change. Doing things the same way is comfortable for most people.
Ruthlessness here is having the Big Balls, as it were, to get rid of a headphone jack and in this case having the capability to do so.
I think DOGE has what a lot of people doing digital service work in government actually want, which is political alignment with technological means of delivery and what it takes to meet user needs.
The regular deal with meeting user needs is that it encompasses policy and delivery: I want to drive a car is the need, the delivery is the simplest, clearest, fastest way to navigate the legal requirements of being allowed to drive a car. Designing the process -- of which the digital service is a part -- of getting that driving license involves negotiating with the people who make the rules about what you need for getting that license and the requirements for the process. Some of those requirements and rules are hard rules. Some of them are open to interpretation.
DOGE, with its inextricably linked policy/delivery view is just making decisions and doing them within a framework of what’s important. This is certainly an approach! It’s an approach that means if you think it would be better for you not to need to provide information to government when government already has that information, then you just do that.
The ruthless prioritization here is that what matters more when you just do that is that efficiency is just more important than protecting data or any rules, whether hard or soft. The alternative to just doing that and one of the reasons why that isn’t done is that there ends up being a negotiation and compromise amongst competing and opposed interests: yes, we want to reduce duplication of data entry and we want to ensure your privacy based on, say, a principle that data is only used for the purpose it is collected.
But if you are ruthlessly focussed on efficiency, then you don’t compromise. It just doesn’t enter the equation.
The group that directs technical implementation and program policy -- the purpose of the system, and how the system works -- is, like I said above, closer linked than ever before. I don’t necessarily like being digital-nativish about this, but one of the deals with software people and these types of technology people is how delivery is so close to purpose.
And in this case, the fact that they don’t care about political capital. They will burn it all, to the extent that they’re in an environment that appears to even need political capital. What DOGE are doing, and the manner in which they’re doing it, has an overlap with what I hear when I work with people and ask them “well, if you could wave a magic wand, what would be different, or what do you need?”
1.2 Efficiency Says What?
Fine, efficient at what, then? To what end? I mean, you’d normally think something like cheaper/faster. More output for less resource, right? More work done per energy input.
Like I said above, that’s not the overriding point of government. The overriding point of government, at least one of them in terms of the services that we apparently believed and agreed that government should provide, is services to everyone. At least in one respect that’s the military budget, right? The military is supposed to protect the entire populace from external threats, right?
The Trump administration just fundamentally doesn’t believe many of these services should exist in the first place. And where they do exist, they are being ripped off. Fraud, waste, and abuse are very handy in terms of figuring out ways to reduce payouts. Suspecting most applicants of being fraudulent -- even when that is overwhelmingly not the case -- is a great way to save money, and reduce that input side of the input/output equation.
Here’s what I think I haven’t been hearing. You want to make something like social security efficient, then you might want to drive down the transaction cost of dollar-to-entitled-recipient. That would be one way you could gauge efficiency. But I do not think they are planning to do that. Especially the “entitled recipient” part.
Another way you might make social security more efficient for people (Right! Efficient for whom?) would be reducing the time it takes for them to perform certain transactions like verifying addresses or correcting mistakes. But again, I do not hear that. I do not hear, for example, DOGE saying “within 3 months, we will have verified everyone’s address” or “we will reduce the number of people needing to speak to someone to verify something by 10x”. But again, I do not hear that.
I know there is a figure out there about the ratio of the administration cost of Social Security as a proportion of the entire budget. My understanding is that it is quite small! Could it be smaller? Probably? But again, to what end?
Efficiency should really be about increasing the amount of useful work done per input.
1.3 Fine, A Thing About COBOL
I think the discourse around COBOL Is Bad and Mainframes Suck is starting to become slightly more sophisticated. I definitely know this in some part because my understanding has become more sophisticated over the last 10 or so years, anyway. So here are some Things About COBOL:
- It works.
This is one of the first things you should remember: it works. At the end of the day, those social security payments get paid out in a reliable, predictable way. At the end of the day, banks move money around in a reliable, predictable way.
- Old is valuable
The longer something has been around, the more chances it has had to completely fuck things up. New things, which by definition of being new, are things we do not have much experience in terms of their operation. We might have a good idea of predicting how they’ll work, but there’s no real substitute for actually using it.
These systems are valuable because they have had such a long time for bugs to get ironed out of them.
(I realise that I’ve pretty much said the same thing in (1) as in (2) but this is my newsletter not yours. Get your own)
- Oh No COBOL Is Too Old
So? Go learn it. Latin is old too. People still learn that.
Oh no, nobody wants to learn COBOL. Yeah, but there are people who also want stable government jobs more than they want a giant salary or are motivated by public service. It would not be that expensive to teach them COBOL.
- It’s Not Actually The COBOL
It’s mainly because you have a very complex system that has accreted decades worth of behavior that is not documented well and is big and hard for someone to understand. You actually have a knowledge problem and you might think it’s easier to throw the whole thing away and start again.
1.4 We Too Should Give None Of Those Things
I will try to make this one short. I was in a conversation with someone adjacent to the philanthropic industrial funding complex and we were talking about the usual Systemic Problems and Solutions and how the Solutions needed a lot more detail and how they were tactics and not necessarily embedded in a Strategy which is different from a Theory of Change.
Anyway, this particular one was about procurement and making procurement better, and one of the underlying problems or reasons why people think about procurement in government is because the government is bad at procuring the software it needs to uphold its side of the “being a government” bargain.
There’s urgency right now I think in the philanthropic industrial complex in that I suppose they’re trying to figure out what to do with the wholesale cruel dismantling of social programs?
And I think it should be an opportunity to be as ruthless, as focussed as the other side. You want to make it easier for governments to choose better vendors? How much would it cost to switch? “But switching costs are too high”. OK well... how many millions of dollars are we talking? Tens? Do you need to buy off Deloitte? I mean, you could do that. The least you could do is ask. Don’t try to do more of the same.
1.5 Context Not News
There are things on Bluesky called Labelers and one of the things they do is put little labels next to screen names in your feed. They are like the checkmark thing, but, you know, arbitrary and also programmatic.
One of the labelers I really like in terms of “wow, that’s useful!” is the Private School Labeler, which places labels next to people who went to private school with the name of the private school and the fees. It is a helpful reminder of peoples’ backgrounds!
Another labeler I like is the kiki/bouba labeler based on the quite frankly ingenious cognitive pscyhology experiment based on what you think a spiky thing is or a blobby thing. This labeler uses machine learning to decide whether your profile pic is kiki or bouba. In a different world this would be the cause of World War III.
Anyway, someone thought there should be a labeler for headlines that mentioned judges so you could see who appointed the judge. Which could be interesting!
And got me thinking of contextually-important-news-related labels. Like: on a politician’s account, a label for how many years they’ve been a member of congress. Or what college they went to. Or what they studied at college. Or how much their stock holdings were the last time they filed a whatever they have to file.
Right now in an attention economy, “news” is “thing that has happened just now”. Publishers have decided that there isn’t space to include context, or at least that context doesn’t perform in whatever environment we’re in. Less of “what should I do with this”. Context here means things like reporting the president’s latest off-the-cuff utterance with the persistent reminder that he just makes shit up and habitually lies. I don’t think it’s okay to just say that people already know that, and certainly in the realm of service design sparkles, you’d go and check if people actually know what’s treated as priced in. “Everyone knows Trump lies”. I mean, clearly, many people don’t and/or don’t care. But I still think it’s worth trying.
Yeah, it’s been a difficult time. It continues to be a difficult time. Like, really difficult.
How are oyu doing?
Best,
Dan
How you can support Things That Caught My Attention
Things That Caught My Attention is a free newsletter, and if you like it and find it useful, please consider becoming a paid supporter.
Let my boss pay!
Do you have an expense account or a training/research materials budget? Let your boss pay, at $25/month, or $270/year, $35/month, or $380/year, or $50/month, or $500/year.
Paid supporters get a free copy of Things That Caught My Attention, Volume 1, collecting the best essays from the first 50 episodes, and free subscribers get a 20% discount.