4 ms·

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

by xamuel 9y ago

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.

mattnewton 9y ago
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.
- clintonb 9y ago
  Are you referring to the initial ACA website? The USDS and 18F came about as a result of resolving that particular debacle.
  - mattnewton 9y ago
    Yes exactly, bringing expertise in house was supposed to solve things like that, and AFAICT it helped.
    - geekamongus 9y ago
      This is exactly what the article talks about, but I don't think you guys read it.
      - mattnewton 9y ago
        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.
- chrisfosterelli 9y ago
  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".
taneq 9y ago
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.
- mattnewton 9y ago
  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.
  - taneq 9y ago
    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.
rblatz 9y ago
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.
alexose 9y ago
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-300m-and-it-doesnt-work/ https://www.cbsnews.com/news/social-security-it-project-cost...
- tptacek 9y ago
  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.
  - gowld 9y ago
    "reliably executed". https://www.cnn.com/2016/07/05/politics/veterans-administration-va/index.html https://www.cnn.com/2016/07/05/politics/veterans-administrat...
    - tptacek 9y ago
      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.

by xamuel 9y ago

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.

mattnewton 9y ago

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.

clintonb 9y ago
Are you referring to the initial ACA website? The USDS and 18F came about as a result of resolving that particular debacle.
- mattnewton 9y ago
  Yes exactly, bringing expertise in house was supposed to solve things like that, and AFAICT it helped.
  - geekamongus 9y ago
    This is exactly what the article talks about, but I don't think you guys read it.
    - mattnewton 9y ago
      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.
chrisfosterelli 9y ago
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".

taneq 9y ago

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.

mattnewton 9y ago
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.
- taneq 9y ago
  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.

rblatz 9y ago

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.

alexose 9y ago

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-300m-and-it-doesnt-work/ https://www.cbsnews.com/news/social-security-it-project-cost...

tptacek 9y ago
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.
- gowld 9y ago
  "reliably executed". https://www.cnn.com/2016/07/05/politics/veterans-administration-va/index.html https://www.cnn.com/2016/07/05/politics/veterans-administrat...
  - tptacek 9y ago
    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.