Comment by notmyemployer | Hacker News Reader

Comment by notmyemployer | Hacker News Reader

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.

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.

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.

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.

> 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.

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.

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.

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.

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.)

The tests are written independently of the original code. If someone has made a logic error or misunderstood some part of the spec, there is a good chance that the independent test implementation is not going to have the identical error. It's definitely a higher chance of finding bugs than having 1 developer write both, as long as the testing is written independently based on an API.

There's a difference between code tests though and spec verification.

Spec verification is (should be...) black-box integration testing. And yes, this is a good chance to get a second set of eyes on the spec to make sure nothing was missed in the implementation. (unit-tests can't catch missing code!)

Code tests should be more white-box and should be measured against line/code coverage instead of spec coverage. These are what I think the original devs should write, and should be 95%+ of the total test volume.

The problem with expecting testing to pick up spec errors is that it takes comes at the end of the design/build phase instead of the beginning when you can make changes easily.

> Code tests should be more white-box and should be measured against line/code coverage instead of spec coverage. These are what I think the original devs should write

Nobody's stopping them.

Well you're not going to pick up spec errors with same-developer unit tests, so either you have someone else write those spec tests or you wait until the customer picks them up on initial delivery / QA.

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.

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

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

Reply on news.ycombinator.com