[nonameiguess]

I experienced something like this for many years across several of the big five defense contractors and smaller SBIR contractors working for the US DoD and IC. As someone who 20 years ago had a slightly better understanding of how computers and networks actually work than an average developer and was comfortable at the command line in an era when juniors increasingly couldn't leave their IDE without becoming hopelessly lost, as DevOps, SRE, and platform engineering started to become things, my career drifted in that direction.

The problem being on teams like that was always the same. You're responsible for developing software products of some sort, but they're software that runs, tests, or delivers other software or even orchestrates the operations of an entire environment shared by many different applications. This inevitably means a whole lot of your work is the classic incident response/post-mortem of operations, plus some level of customer support given to other development teams because internal platform teams never get a separate support organization. To this day, the government has no idea how to handle this in light of how DFARS (administrative law governing acquisition) works.

Every labor hour a contractor charges has to be tied to a specific line of accounting which is itself tied to some unit of planned work tracked in an issue tracker or project management system of some sort. Most of the time, this is an Epic in Jira. This is logical insofar as you consider the intention of acquisition as a category of appropriations bill. A budget proposal with line items tied to measurable product features is presented to and approved by Congress. You have to demonstrate you're spending the money they gave you on what they approved you to spend it on, because per the Constitution, that's how power of the purse works. The executive branch can't just do whatever it wants.

But it falls apart as contractor labor increasingly replaces federal civil servants. When your job is anywhere from half to all running and maintaining an operational system, that isn't really acquisitions any more. It's operations and maintenance, which is an entirely separate appropriation. Soldiers manning a defensive perimeter have no idea when they're going to be attacked or how much work they'll be putting in. Software operations is effectively just the less lethal civilian equivalent of that. The government arguably even recognizes this in many ways. Typically, running and maintaining the production system is a separate contract from the development contract and it uses separate work tracking systems, and if someone spends 8 hours watching a screen while producing no quantifiable work outputs, so be it. They charge 8 hours because that's what the contract says they're supposed to do.

But as we're increasingly expected to be modern software organizations with things like CI/CD, test and staging environments, and you inevitably need to run at least some of your own development infrastructure, well now what? You have a lot of people whose job is the same. Be on constant lookout and respond as needed, but now it's part of a development contract and they need to have quantifiable work outputs that be tied to a budgetary line item with an associated product feature.

So we convolute nonsense out of thin air like cloning the same monthly "Support" Epic in Jira, month after month. "As a developer, I want my tooling to work so I can do my job and deliver value to the government." Plug in some SWAG number vaguely guessed at based on how much of this kind of work you ended up doing last year. Every 90 days, play planning poker with it. LARP a product team even though that isn't what you are.

[OldGuyInTheClub]

Excellent and, to me, underappreciated points on HN. Now, expanding into the hardware world of A&D brings different levels of agony. If there's development risk, there's no good way to write a schedule that both accounts for it AND consistent with absolutely mandatory "Earned Value Management" where complex tasks have to be shredded into tiny 1-3 week chunks with metrics that the accounting team can track and report. If you need to fix a broken piece of equipment, if you need to buy a part, you're at the mercy of a procurement system that exists to survive audits and wants to know why the break or purchase wasn't in the plan. If the problem requires evaluating Plans A, B, and C, you have to pick one as the best, baseline, and execute it. Then if you need to consider the other two options that everyone knew up-front were possible, you get to explain why The One Chosen Plan didn't work. "You signed up for it."

The only way I've seen around it is a Risk/Opportunity Management system where risks/opportunities to whatever the baseline plan might be are enumerated, assessed, planned for, and maintained for when things go sideways or when there's a chance to save schedule and/or cost. But, that takes a VERY gifted _leader_ to run at the top level and those are rarer than hen's teeth. Ideally when a risk becomes a problem or an opportunity presents itself, the contingency plan is implemented. When it works, it is great and I've seen tough, ambiguous projects come in ahead of schedule and under budget. The common theme was one guy running all those projects and he's now retired. Usually the result is that the person reporting the problem gets stomped upon by a _manager_ who runs a cargo-cult process that s/he doesn't really understand.

Earned Value Management may be fine and dandy when development risk is done, the transition to manufacturing is complete, and the manufacturing process is relatively stable and the perturbations are small. Of course, that's when the contract SHOULD be Firm Fixed Price and not tracked by an army of accountants on both sides of the contract.