Project 2025 for DOGE and Computing

This article is part confession, and part re-thinking how we architect things in Computer Science.

The way we are taught to structure systems no longer applies.

I'm writing this for DOGE, but anyone can take its principles to heart.

Mea Culpa

Once upon a time, I built the data model for a website that let anyone manage a stock portfolio as if they were a mutual fund manager. I duly created objects like Stock, Portfolio, Trade, Corporate Action, etc. Then I used an object relational mapper to apply those objects to a relational database.

And it worked good enough to almost make me rich. But at the end of the road, it was crap. Because what I should have built was an accounting system.

If you look under the hood in Quickbooks, everything in quickbooks is chrome around a general ledger entry. Invoice? Entry against accounts receivable. Bill? Entry against accounts payable.

Reversing the Singly Linked List, and other stupidities.

Something that companies love to ask in job interviews as a whiteboard problem is to reverse a singly linked list. This is stupid for three reasons:

No one has ever had to do this. It's a toy problem. Instead of asking toy puzzle questions, bring a real problem into the interview and audition the applicant by having them work with you on the problem.

Building a singly linked list is stupid in 2025, best way to reverse it is to write code to turn it into a doubly linked list as you go. Standard answer is a stack.

There should be only two data structures: The array, and the 6-bit Trie hash. Modern computers have layers and layers of caching and memory bandwidth you don't want to screw with. A 6-bit trie hash gives you 64 entries at a time, which is perfectly melded into the cache of your CPU.

All that stuff we're taught in university? Bunk at this point. Memory, CPU, and Storage are cheap now. Brute force solutions like ElasticSearch, Hadoop, Cassandra, and S3 rule the day.

Rethinking government

So what DOGE should do is embrace the year 2025, and the capabilities we have available now. We don't need a data model per department. What we need is an accounting system that collects every transaction, and every piece of paper the government inflicts on us poor citizens. That system should then be wrapped with the appropriate UI chrome as needed.

You can see glimmers of this already, if you've ever looked at the 1040-PC form the tax software spits out, all those forms are just chrome around "Line 100, $45".

Rethinking Forms

Similarly, every application should work more like github. Reading Reentry I was struck by how SpaceX wrote their proposal once as a template, and then they would edit the bits that changed and resubmit it to the FAA. Elon was raging awhile ago that the FAA was going to take months to approve a launch after they changed the location from one launch site to another.

Here's the thing. The United Launch Alliance had hundreds of people working on their proposals. Elon had 3. So the ULA was perfectly happy going along with the status quo where the FAA would re-read every line of their 300 page proposal, and they needed all those people to re-generate the new application for every launch. (Day 1: You are assigned page 58).

But that's crazy. We wouldn't be able to generate software in the real world if we re-read the entire code base for every change. Instead, we look at just the changes, and approve deny that change.

Applications should work like pull requests, and the history and changes should be tracked just like git tracks everything that has changed in a file.