Waldo Jaquith

@waldoj
4.4K Followers
239 Following
9.8K Posts
Thought follower. Male software developer. Alumnus of 18F, the Obama White House, Georgetown's Beeck Center, the Biden-Harris Transition Team, and the Biden administration. Speaks only for self. he/him
PlaceCharlottesville, VA, USA (Monacan land)
Websitehttps://waldo.jaquith.org/
Blueskyhttps://bsky.app/profile/waldo.net
PronouncedJAKE-with

RE: https://me.dm/@anildash/116342640913190195

If I lived in the EU, I'd have pivoted my career by now to supporting the creation of publicly owned software and technical infrastructure, to wean the member states off U.S. tech. It's the only sensible thing for them to do.

We’re 30 years into a contracting death spiral, where software projects have more and more requirements—thousands of them, in the case of major systems—and yet those projects more likely to fail than ever. This model hasn’t worked.

The solution is a radical reversal: the elimination of nearly all of those requirements. This is how we put government in charge again. This is how we succeed.

~fin~

...Unless you also tell the vendor that they must complete particular objectives. Then you’ve just destroyed that model. Now the vendor has to ignore the PO and substitute their own judgment about what work needs to be done when, and how, because they must answer to the higher power of the contract.

Every requirement is just tying your own hands.

But, wait, it gets worse!

It is essential that every project be led by an empowered government product owner, whose has the crucial job of preparing and prioritizing user stories for the vendor team to pull from at the beginning of each sprint. This restores control to government.

In the case of those 16 workflows, it would be a real victory if user research found that, actually, only 9 workflows were needed. That's faster to build and cheaper to maintain. But only if the contract allows building just nine! Did it specify 16? Well, then you're getting 16 now.
The core proposition of an Agile contract is this: Instead of defining lots of requirements, those are introduced as user stories throughout the life of the project, based on constant user research, prioritized by a government product owner. When you define requirements up front, they'll be wrong.
When procuring custom software, agencies commonly make the mistake of contracting for detailed deliverables. They think “our existing system has 16 workflows, so let’s require those the contract for the new system, so that we’ll know we’ll get all that functionality.” This ends badly.
Blog entry: It's a mistake to include a detailed list of deliverables when procuring custom software. https://waldo.jaquith.org/blog/2026/04/detailed-deliverables/
Detailed deliverables are a mistake.

Extensive lists of requirements provide agencies with an illusion of certainty. But they're just tying their own hands.

Waldo Jaquith

RE: https://mastodon.social/@thiseconomy/116332450416895439

My bot's been on a real heater recently. On Monday it was "between a rock AND a hard place?” and last week both "for all debts public AND private?" and "hammer AND sickle”?