7 ms·

I've done some federal contracting and the issues seem to be cultural. The government hands out what they call "prime" contracts which are then subcontracted ou

I've done some federal contracting and the issues seem to be cultural. The government hands out what they call "prime" contracts which are then subcontracted out to multiple other firms. The primes tend to be stodgy old companies filled with lawyers and MBAs that can win the contracts, who then view the engineers as replaceable cogs. You then interact with multiple other contractors that own particular parts of the stack, for example an independent testing contractor and another for infrastructure. It wasn't uncommon to have 5 project managers for each engineer on the project. Coming from tech startups this was completely shocking, I was so used to an engineer driven culture. That developers couldn't write their own tests, or manage their own infra, or deploy multiple times a day was super frustrating. There sounds like there are some great initiatives to change this old approach, but until then I can't imagine many talented devs would put up with the bureaucratic bullshit.

jchrisa 11y ago
And yet there's good code written in the midst of it sometimes.
ViViDboarder 11y ago
I worked in the past on an IBM project with the TSA, and they were indeed the prime on a large software contract. About half the team was IBM, the other half medium to small sized subs. Honestly, most of the wasted time wasn't the engineering teams being slow, but anytime something had to be run by the government, it halted. It was utterly depressing.
- notmyemployer 11y ago
  This was my experience as well, it was mainly the arbitrary road blocks. When I'd be on a call and realize there was finally another dev on the line I'd immediately get in touch via email or chat and back channel while the swarm of project managers talked about who knows what.
cmurf 11y ago
These companies need to just be fired. Seriously. Send them back to the real world for a while. Makes me think of the Vogons from Hitchkiker's Guide to the Galaxy.
thaumasiotes 11y ago
> That developers couldn't write their own tests, [...] was super frustrating. I can see advantages to having someone else write tests for the developers. And I don't see how they stop you from writing tests for personal use, if you want to.
- notmyemployer 11y ago
  Sure, if those testers actually know what they're doing, which wasn't clear if they actually did. A bunch didn't even know how to use git and didn't have commit access to the repos to begin with. I have no problem with other people testing my code, but that there wasn't a culture of engineers writing their own tests at all was surprising and troubling.
- rplst8 11y ago
  In the aerospace industry (commercial and defense are similar here because the software for commercial has to be written according to government rules, see FAA DO-178B) it's actually verboten. Testing independence is part of the flight certification of the software if I'm not mistaken.
  - thaumasiotes 11y ago
    This has all the enforceability of prohibiting your workers from thinking about what they're working on, or practicing in their spare time. Tests you write for your own benefit are not a deliverable. They're part of your work process. As I said before, it's not ridiculous at all to require that deliverable tests be written by some other party than the developer whose code needs to pass them.
    - EdHominem 11y ago
      Actually I think this is one of those things that sounds so obvious, and yet isn't right in practice. I'l roughly segment projects into those that can fail a bit and those that can't. Now obviously, for things that can't fail even a little you can't just take someone's word. But why can you take the word of two people, or ten? The failures (in programming and code review) are absolutely correlated. If one person fails at something another likely will fail in the same place or when reviewing it. When people die if there's a bug, or you're even losing a lot of money, you should not be trusting best-effort human anything. This is where imperative programming against a test suite breaks down and just can't cope. You need to switch out your internals for something provable in its domain. (eg, the math to land a space shuttle in a fixed-time infrastructure (ie before it lands itself)). And for everything else, it's a $/$ calculation. How much do you want to spend to have some unknowably smaller amount of risk? And usually the best value for the dollar is having the original engineering team work on the tests, with outside oversight and good metrics. If an integrated team is having problems getting full branch coverage (the only worthwhile coverage metric...) in a given method, they rewrite the method. External teams have to test what's given (or waste a ton of time in communication delays) and that usually ends up with suboptimal tests and suboptimal coverage. What you can't do though is simply ask a developer if their work is properly tested and trust their answer. You need real metrics and to know what they mean for you. (Like benchmarks.)
elliottcarlson 11y ago
I was at an agency and worked on the website for the Bureau of Engraving and Printing when they were releasing the new $20 design. The contract was for $88M - and our parent company was the prime contract and simply sub-contracted all the work to various sister companies. The agency I was at was in charge of the website part of the contract and we were literally just another cog in the wheel - we were certainly being billed as high end talent, and we had to undergo a minimal security clearance to work with high-res images of the $20 bill, but we were severely underpaid and overworked - and we were offered no recognition for our efforts. No regrets leaving the agency world.
seivan 11y ago
I've also been there. It's a really poor environment for quality. Forget engineering driven.

jchrisa 11y ago

And yet there's good code written in the midst of it sometimes.

ViViDboarder 11y ago

I worked in the past on an IBM project with the TSA, and they were indeed the prime on a large software contract. About half the team was IBM, the other half medium to small sized subs. Honestly, most of the wasted time wasn't the engineering teams being slow, but anytime something had to be run by the government, it halted. It was utterly depressing.

notmyemployer 11y ago
This was my experience as well, it was mainly the arbitrary road blocks. When I'd be on a call and realize there was finally another dev on the line I'd immediately get in touch via email or chat and back channel while the swarm of project managers talked about who knows what.

cmurf 11y ago

These companies need to just be fired. Seriously. Send them back to the real world for a while. Makes me think of the Vogons from Hitchkiker's Guide to the Galaxy.

thaumasiotes 11y ago

> That developers couldn't write their own tests, [...] was super frustrating. I can see advantages to having someone else write tests for the developers. And I don't see how they stop you from writing tests for personal use, if you want to.

notmyemployer 11y ago
Sure, if those testers actually know what they're doing, which wasn't clear if they actually did. A bunch didn't even know how to use git and didn't have commit access to the repos to begin with. I have no problem with other people testing my code, but that there wasn't a culture of engineers writing their own tests at all was surprising and troubling.
rplst8 11y ago
In the aerospace industry (commercial and defense are similar here because the software for commercial has to be written according to government rules, see FAA DO-178B) it's actually verboten. Testing independence is part of the flight certification of the software if I'm not mistaken.
- thaumasiotes 11y ago
  This has all the enforceability of prohibiting your workers from thinking about what they're working on, or practicing in their spare time. Tests you write for your own benefit are not a deliverable. They're part of your work process. As I said before, it's not ridiculous at all to require that deliverable tests be written by some other party than the developer whose code needs to pass them.
  - EdHominem 11y ago
    Actually I think this is one of those things that sounds so obvious, and yet isn't right in practice. I'l roughly segment projects into those that can fail a bit and those that can't. Now obviously, for things that can't fail even a little you can't just take someone's word. But why can you take the word of two people, or ten? The failures (in programming and code review) are absolutely correlated. If one person fails at something another likely will fail in the same place or when reviewing it. When people die if there's a bug, or you're even losing a lot of money, you should not be trusting best-effort human anything. This is where imperative programming against a test suite breaks down and just can't cope. You need to switch out your internals for something provable in its domain. (eg, the math to land a space shuttle in a fixed-time infrastructure (ie before it lands itself)). And for everything else, it's a $/$ calculation. How much do you want to spend to have some unknowably smaller amount of risk? And usually the best value for the dollar is having the original engineering team work on the tests, with outside oversight and good metrics. If an integrated team is having problems getting full branch coverage (the only worthwhile coverage metric...) in a given method, they rewrite the method. External teams have to test what's given (or waste a ton of time in communication delays) and that usually ends up with suboptimal tests and suboptimal coverage. What you can't do though is simply ask a developer if their work is properly tested and trust their answer. You need real metrics and to know what they mean for you. (Like benchmarks.)

elliottcarlson 11y ago

I was at an agency and worked on the website for the Bureau of Engraving and Printing when they were releasing the new $20 design. The contract was for $88M - and our parent company was the prime contract and simply sub-contracted all the work to various sister companies. The agency I was at was in charge of the website part of the contract and we were literally just another cog in the wheel - we were certainly being billed as high end talent, and we had to undergo a minimal security clearance to work with high-res images of the $20 bill, but we were severely underpaid and overworked - and we were offered no recognition for our efforts. No regrets leaving the agency world.

seivan 11y ago

I've also been there. It's a really poor environment for quality. Forget engineering driven.