Comment by alexjplant
1 day ago
> There is a fundamental truth motivating the U.S. Digital Service that sets it apart from many other government agencies: You cannot build an app the same way you build a boat.
In my time in government contracting almost nobody understood or wanted to acknowledge this (at least in the Navy). You could practically play bingo with non-technical PMs talking about "increments" and "milestones" on the way to "fielding a complete capability" as though it was a weapons system that'd be stuck in the field for 30 years instead of the CRUD app that it _actually_ was. Any attempt to expediently deploy a thoughtfully-engineered vertical slice to iterate upon was stymied by year-long compliance processes and deployment procedures rooted in the year 2004. The culture is used to building tangible physical products (airplanes) and fails to comprehend that software is just bits and bytes that can be changed at will and automated. Even worse, any attempt to introduce a more sane process resulted in something that strongly resembled the status quo being repackaged and disingenuously branded "Agile" or "SecDevOps" or some other buzzword.
I'm certainly not in the "move fast and break things" npm/Xitter/Google camp but it shouldn't take 18 months to get a web app in front of beta testers. It's a real shame that the USDS is being gutted because I was very impressed with what I saw of their work and think that it's the path forward to cost savings in government software development.
I'm not a USDS employee, but I'm a federal contractor working alongside USDS employees, some of which I count as friends, and some of which have been fired. My views are my own, and take them with a grain of salt; I'm kind of an idiot.
The USDS is wonderful. Unfortunately, there are a couple factors that might have impacted its lifespan. I think the USDS has been a bit quiet about its accomplishments. One reason for that is the common public view of the government agencies as ossified and of government employees as slothful, ineffectual, and arrogant (which has not been my general experience). I think the USDS has been very willing to give its partner agencies the lion's share of the credit in order to assure future cooperation and avoid any public controversy, to refuse to play into that narrative.
Unfortunately, without a lot of publicity, I think there has been a faintness in the public perception of what the USDS does, and how well it does that.
Ages ago I worked at a DoD contractor. I was in a special projects department.
The overall company was broken up into divisions, essentially the west coast facility was its own division, the midwest, east coast had its own division. They are reasonably independent, with their own facilities, own profit and cost centers, etc.
What was telling was that they also had a "Data" division. This was a branch that had its own division level autonomy, but was installed in each of the other divisions. The Data division managed the mainframes at the time. If one of the divisions needed computing facilities, they contracted with the Data division. Considering the expense of setting up and maintaining the mainframes of the time, it made sense.
But that's where my special project group came in.
We offered internal computing services, without the Data division, for our group. We ran on mini computers and the exploding PC and workstation machines. Our boss had sales reps from everywhere dropping off new gear to evaluate.
Typically, we've all heard it before, that our group of college level "kids" was much more nimble and responsive to the needs of our group than the Data division ever could be. We were a sunk cost that could be spent on anything rather than bound by contracts and such. Specs were delivered over coffee and recorded on post it notes. Then we'd just get to work and iterate.
It seems this concept had to be continually reinvented, and rise again, and again, and again, from the ashes. Maybe its a software thing. We all know how it always seems faster to burn the old, reinvent and rewrite the new. How the "best" way to lose technical debt is to `rm -rf /` and start again. "Do it right, this time." -- again, and again.
You'd like to think there's a middle ground, but I think it's just the institutional nature of the business and the practice. Obviously, nowadays we do have some substantial, long term, long lived systems. But they're more rare than not, they're imperfect and still suffer from issues, new and old, as they evolve.