Hacker News Reader

Comment by geekamongus | Hacker News Reader

As someone who worked in a DOC agency for 5+ years doing security work, much of my job consisted of reviewing software for compliance and security before acquiring/installing it in our systems. Every time someone showed up with something 18F was doing, it involved far more bleeding edge cloudy stuff than we were able to accept.

In short, the shiny object that was 18F had a really hard time doing its job of integrating with the resistant, crusty old pillars of Federal Agency policy and technology.

View on HN

Evaluation of 18F’s Information Technology Security Compliance | https://news.ycombinator.com/item?id=13697302

https://news.ycombinator.com/item?id=13711187

I love that comment.

This. When "left-pad" messes up some Facebook-for-dogs startup, that's bad. When "left-pad" messes up the social security system, the army, etc., that's really really bad.

You think our government websites aren’t already messed up? Look at the ACA site for example. There are plenty of websites that suffer from mundane reliability and maintenance problems.

18F was a crucial step in modernizing our infrastructure and attracting people to work for their government who would normally never touch this Byzantine nonsense with a 10 foot pole.

God bless the people still in the government fighting for good tech.

Yeah it's easy to worry about potential "left-pad" issues blocking deployments once every however-so-many-years but ignore how many government websites currently close for several hours each day as "maintenance".

Are you referring to the initial ACA website? The USDS and 18F came about as a result of resolving that particular debacle.

Yes exactly, bringing expertise in house was supposed to solve things like that, and AFAICT it helped.

This is exactly what the article talks about, but I don't think you guys read it.

The article talks about how new people aren’t being recruited in the new administration. 18F under Obama was a major recruitment effort for quality talent.

I see the point you're making, but you have to consider the other side of it as well. Most of these agencies are running ancient software, on ancient OSes, with decades of kludges layered on top to address requirements that change every six months. It's not the precise, time-tested COBOL you're imagining. Think in terms of "enterprise-ready" languages with tons of obscure, expensive, and undocumented modules. No automated testing, no documented REST APIs, no version control or package management.

Developing on top of these systems is extremely difficult and has lead to many high profile budget overruns-- Sometimes to the tune of hundreds of millions of dollars. Keep in mind that the head of Social Security was actually called in front of congress to explain how things got so bad [1], and the prospect of using modern development processes seems like a pretty good idea.

[1] https://www.cbsnews.com/news/social-security-it-project-cost...

This is common in the Fortune 500 as well. Plenty of IT and line of business development shops that build Kotlin apps and use React also have z-series cabinets in their data centers running code that has been nurtured for decades. If you think the business case for doing that hasn't been considered carefully, you're wrong.

This isn't a fedgov pathology. It's a business process reality. Unit tests, version control and package management are nice to have, but 3 decades of reliably executed business process are more important.

"reliably executed".

https://www.cnn.com/2016/07/05/politics/veterans-administrat...

That's a middlebrow dismissal. Obviously there are bad processes everywhere (including in industry). The VA is notoriously bad even for FedGov. That does not mean you can evaluate a line of business application based on whether it has version control and package management. To a pretty significant extent, any time an F-500 company procedurally cuts a recurring check, comparatively ancient mainframe code is implicated.

You want to see chaos and calamity? Rewrite all those applications, or even a significant fraction of them, with modern processes. See what happens.

With as easy as it is to setup your own repository server I can't imagine why anyone wouldn't be running something like nexus or proget to proxy all their packages.

It still beggars belief that anyone would add a critical external dependency to their product in order to save themselves the time of writing something like "left-pad". Depending on libraries that auto-update from "the cloud" and could completely remove or subvert vital utilities? What the hell.

Mostly in agreement, but the sin IMO is absolutely not in depending on left-pad. Code reuse is good, and it could have been any package, including something like your Postgres adaptor. The sin is not running an npm mirror under company control, that can do things like audit open source licenses and protect against npm outages.

Agreed - my issue is not with using whatever libraries make your life easier, it's with having those libraries under the control of a third party. So if you run your own npm mirror and vet updates (and can roll back versions if an update does break something) then you're good. Anyone who complained that they got to work one morning and their production code was broken because of a change to something external to their building should be sacked.

As someone who works for a company that works with the DoD, the push mentioned in the second to last paragraph is making it's way down the chain and we are seeing a greater acceptance of cloud tech. There isn't widespread adoption yet but they are open to projects moving in that direction.

This was true when I left two months ago, but the challenge, for us anyway, was how we extend our security boundary to encompass cloud technology without breaking the bank. Anything managed at levels higher up and offered as a "service" typically proved to be stringent to operate inside of.

US federal government really needs its own cloud computing agency full of stick-up-the-butt security and reliability fanatics. 99.999% availability. Formally verified code everywhere. Built on a real-time OS. Guaranteed periodic permanent backups.

Anything the gummint does pretty much needs to scale immediately to 400 million users, can never experience a data breach, and needs to stay available constantly, possibly for decades, or maybe even forever.

The loss of the 1890 census records by fire is still significant today. If every copy of the quarterly reports for GE from 1982 were lost, the impact would be much smaller. The current cloud service offered commercially today are plenty good enough for even some of the hugest public companies, but not quite good enough for an entity with vastly different goals and needs. The different flavor of requirements might mean that private sector business will never offer a suitable class of service. Currently, some agencies run their own data centers, so the necessary expertise certainly exists, but that is not currently contributing in any way to a common infrastructure.

Something like www.cloud.gov?

You must have a lot of really useful efficient software products at DOC right? Good thing you’re all compliant.

There’s a healthy balance between shiny object syndrome and jdk1.1 projects. Cloud isn’t bleeding edge. It was 10 years ago though.

Reply on news.ycombinator.com