The U.S. Air Force learned to code and saved the Pentagon millions

The cap should be based on the private sector equivalent of a job. Having an absolute cap is counter productive.

The article talks about enlisted doing the coding, not officers.

They cannot leave until their contract is up. They literally cannot leave as soon as they've learned if they still have years in their contract. Additionally, the military dangles a lot of incentives to re-enlist, and people who have spent a lot of time in the military sometimes have trouble adjusting to life outside it. But yes, people will leave. There's always more. You would be surprised how many bright people choose to join the military even though it doesn't make economic sense for them.

I'm on mobile and copy paste isn't working, but enlisted pay grades are publicly available. They are much lower than SV salaries and they are set in stone.

Many folks who join the military did so out of a sense of purpose. Not all, to be sure, but many.

One thing I was disturbed by going from the US Navy to working privately in software development in Seattle is how much of a secret pay is in the private sector.

You can pretty much look up how much money anyone in the military makes. Base pay is trivial to look up, and all the other allowances (housing, hazard, etc.) can be looked up.

https://www.dfas.mil/militarymembers/payentitlements/militar...

The same is true in the government, AFAIK.

https://www.opm.gov/policy-data-oversight/pay-leave/salaries...

To be 100% honest, if they offered $80k and military level benefits I bet you a ton of people would take that offer as long as it was guaranteed in writing they would be in the US writing code. Most developers are mediocre and paid in the $80-120k range depending on cost of living.

The allure would be job/salary security for 10-20 years (albeit at a lower salary than SV), and retirement in 20 years with full pension and medical benefits for life.

The housing allowance for an O-1 in San Francisco with no dependents is over $4000. That’s a good deal better than the rent spending most Bay Area bigco engineers feel comfortable with. I’d argue the military is quite competitive with the tech industry when location is taken into account.

Guaranteed pension and benefits for life after 20 years with substantial subsidies are worth a lot.

Given the choice between a typical developer's life (outside a tech hub or hot spot most programmers aren't compensated much different from any other low social status white collar worker), moral issues aside, I'd take the military job any day.

A person can join the military at 18, retire at 38 and be in a prime position to capitalize on his network as a consultant or "small business owner" contractor, or else just sit back and enjoy his generous pension and health and other benefits. That's a big deal.

The best rank structure for this would be the warrant officer.

I work in the public sector for a lot less than the offers I get from the private sector. I haven’t once considered leaving.

Well I have, but that’s when the right decision drowns in politics and red tape, not because of money.

A lot of people would consider me an idiot, but I get a sense of duty and purpose from public service that is worth more to me than money.

Of course it helps that my pay check isn’t exactly bad. So it’s also a choice between good money and better money, I’m not sure how I’d feel if it was a choice between shitty money and great money.

This is a bizarre thing that keeps popping up here. This assumption that as soon as somebody learns how to code, they pack up and move to the Bay Area. Since when was Silicon Valley the only place with competent software developers? We exist all over the planet, often getting paid very different amounts, and usually, yes, very much less than Bay Area developers.

In reality, the USAF here is competing against the cost of defence contractors. Which it turns out, is pretty easy because they've been charging megabucks for everything for two decades because their only competition has been other defence contractors. Thanks to politics, right or wrong, they've had no capacity to ramp-up on in-house development and submit their own bids to really compete on price.

I really hope we're entering into an age of reality where public organisations (military, government, healthcare in the civilised world, etc) —and more, the people funding them— realise that in-housing development work is so much cheaper than farming it out.

Working for the military can pay very very well -- if you're a consultant or work for a third party.

When theory meets reality, requirements change. We thought this approach would work, and our research suggested it would. Then the real world came along.

For what it's worth, Pivotal Labs bills on a time & materials basis. But we're not billing to create software, we're billing to help you learn how to build it yourself -- and to teach your own to do the same.

Disclosure: I work for Pivotal in R&D.

Risk IS ALL it comes down to. Risk and who the the big-wigs have lunch with. Is the company big enough to sue when something screws up? Tick!

i worked on software like this as a contractor for ausDoD. The same shitty companies who were big enough to sue would get awarded contracts over and over again even though nothing they ever delivered was on time, budget or worked. Accenture didnt even have programmers, they were hire buisness grads and give them crash courses on writing software. so whatever was delivered, would need another billion dollar project to replace it. why? its a massive bureaucracy, where everyone is covering everyone elses ass, everyone is fighting for budgets that they will do anything to protect. 90% famine until the last month, when its a feast and all the desicions get made, because if they dont spend it, they loose it.

The reason why this is changing is not because its a light-bulb moment, its because its taken this long for the people up the chain to backed into a corner. Eric Smitch isnt the first person to think of this, his the first person with high enough clout to get it done (on a micro-level).

suffice to say, working in such a environment is toxic for your career in software development. unless u want to work on these secret networks all your life, on the same software, maintaining it, its just a dead end. Want to use that new web tech? Nup. The SoE takes years to update, you still need to support IE8 for the next decade.

You should qualify which engineers you are refering to. From the article it's clear that the majority of the coding is "by a fast-moving cadre of Air Force engineers". They are Forces personnel, not civilians. Yes, Pivotal are involved, equally it seems if they are practicing XP, perhaps now only as Agile Coaches.

I also believe the applications this team are creating are substantively different in intent to those the Google employees were complaining about.

> I know I'll get down-voted to hell on this, but please if you're going to try and take the moral high ground at least do so consistently.

I feel that saving money on tanker planning is on a different ethical level from creating drones that can kill people upon facial recognition.

Disclosure: I work for Pivotal in R&D.

>Where are the calls from HN commenters suggesting that the engineers refuse to work on this?

shrug I find that the state monopoly on violence to be much more justified than some of the perfectly-legal ways people in the private sector choose to exploit their fellow humans for profit. -- At the very least, we treat the state's exercise of violence as a necessary evil to be minimized.

I found it darkly-humorus that nothing short of actual military contracting could wake up oh-so-progressive googlers to some "are we being evil" introspection.

I want software developers to collectively adopt an ethical standard and stick to it. I really, really do. But the only way I'm able to cope with what I've been witnessing for the last 15 years is to aim scorn at us all for being rationalizing frauds.

You're talking about a company that's motto use to be "Don't be evil" and who has been referred to as the Chocolate Factory (a la Willy Wonka). Google isn't historically a military contractor or a systems contractor in general. All of their advertising, keynotes and press conferences center around connecting and helping people, not helping to develop weapons. Culturally they're a friendly company trying to make the world a better place. Presumably their employees didn't seek employment with Google under the impression they'd ever be developing technologies to aid the military in carrying out it's mission. So why is it so difficult for you to comprehend the backlash or cultural resistance to this?

This would be like Coca Cola announcing it's new chemical weapons division.

They are military personnel, writing code for military applications. They are under the obligation to refuse to execute orders that go against international conventions and have an obligation to respond to Congress/Senate inquiries. Their superiors, who might want to pressure them into doing things that are illegal or don't align with the US stance can be court-marshaled.

Good luck getting anywhere near that level of responsibility from Google execs or managers.

There is an, unfortunate, lack of continuity in many offices like that in the military. This is due (as you're aware, this statement is more for others) to the way that personnel get moved within the military. Officers, in particular, as the ones who are typically the "decision makers" for selecting what projects to work on will be in their job for 2-3 years at a time. If they don't have a chief or a civilian staffer who acts as a continuity officer, projects like what you did get forgotten.

"Why are we still using this VB6 thing after 15 years? We should put out a contract and have it done properly." says some colonel or major who doesn't know better. And so it happens, a contract is awarded and it's a mess. I saw it more from the civilian side. Without strong continuity officers, when the military leadership changed over the direction and intent of things is forgotten.

Additionally, as this article points out, the military is set on Waterfall-styled contracts and projects, given to the lowest bidders. Which is why it becomes a mess once a contract is awarded. Waterfall only works under a few circumstances, and I guarantee your lowest bidder won't satisfy them all (expertise with the implementation technology, expertise in the problem domain, expertise with how the system is actually used, ideally a project that's been done 100x before by the same team).

Competent internal teams can produce relatively simple solutions within a reasonable budget. However, it's hard to formalize and replicate such teams and/or team habits. That's why the more formal specification & contract approach is often used instead: It's a BIT more predictable.

The first approach may get a grade from A to F, while the second ranges mostly from B- to D-. Predictable semi-crap is often easier to accept than something that might easily be an A, F, and all between. The first's probability curve is mostly flat from A to F, while the second peaks around C-, and thus it's somewhat more predictable, and that's why managers and bureaucrats often prefer it.

I think it's a really tough problem, and maintaining all the capability in house may not be the right move, but there must be some in house capability to use for prototyping and technical decision making, otherwise your procurement gets disastrous because you have no ability to evaluate what you're buying.

I once interned at a military base that used punched card readers. Some jobs (processes) would refuse to run if any card in the deck was detected as being bad (using counts and check-sums), such as misaligned holes. Being analog, different cards often were "bad" on repeat reads. It drove everybody crazy. Experienced card people knew all kinds of tricks to reduce such a problems. I learned to respect experience.

It came from Hogans Heroes and was generally adopted by the military as a "black box" that nobody understands. In my experience, it's predominantly used in the Air Force.

> "move fast and break things"

Doesn't mean that you deliver broken code, it means that you should not be lazy to rewrite old code.

I would have thought "move fast and break things" could almost be an Air Force motto!

> in the direction of an industry whose unofficial motto is "move fast and break things"?

At Pivotal we have a different version: "go fast, forever". I believe Facebook updated theirs from "move fast and break things" to "move fast".

> But broken things have much graver consequences when they involve guns and bombs and airplanes.

We aren't to my knowledge participating in weapons systems or flight avionics (and I hope we never get involved in weapons systems).

Our work demonstrates a principle discovered in other industries a while ago: relentless focus on improvement breaks the iron triangle. Fast, affordable, good: pick any three.

But you can't do this by mouthing some slogans, skimming a book and then burping up code as fast as you can type. It takes a genuine and sustained discipline to keep to the core practices: pairing, TDD, CI/CD, IPMs, retrospectives, user-centred design, lean product management, balanced teams etc. But keep to it and the payoff in sustainable pace is remarkable.

Disclosure: I work for Pivotal in R&D.

The traditional outsourced approach seems to have been "Move slowly, waste money, and break everything."

My concern is that security is a potential issue, and short term savings could easily be offset by a massive security disaster later.

Enthusiasm isn't enough. I hope there's a standard, professionally tested, security framework being developed by experienced and capable security experts which other projects can rely on, as required.

It could otherwise be read as "agile as f*"

I call BS on this [0]

[0] https://blog.codinghorror.com/boyds-law-of-iteration/

This is the current war: https://en.wikipedia.org/wiki/Operation_Inherent_Resolve

Possibly because the applications are qualitatively different; possibly because the software is being produced by military personnel (aided by civilian advisors).