[noir_lord]

I think that startup mentality might bite them in the arse.

I saw "React on Ruby" and winced.

There is nothing wrong with that platform as a "We are in a market where things will change radically in two years" but for the VA? Where things might change once a decade, that's a recipe for pain.

Look at where the Web was 5 years ago (hell React didn't exist) never mind 10.

Angular is 7 years old, KnockoutJS is 7, jQuery is the grandaddy at 11, React is 4.

Not a criticism (they are clearly doing important impactful work) more a concern.

If someone said to me "You will have to support this for at least 10 years" the choices I made would be extremely conservative.

[commandar]

To me, this looks like the bigger potential problem:

>U.S. Digital Service members join us for what we call a tour of duty. We are seeking candidates interested in joining the U.S. Digital Service fulltime, ideally for at least 12 months. In some cases, we can accommodate candidates who can only commit to a shorter amount of time. Three months is the minimum time commitment we can accommodate. All members of the U.S. Digital Service hold "term-limited" positions, which means that at the end of a prescribed term, the candidate's employment with that agency must end.

You have to move to DC -- without relocation assistance -- knowing that you're only going to work for USDS with an expiration date? Seems like that'd really shrink the net of candidates to me. I know it kind of kills my interest, personally.

[nacin]

Yeah, this is hard. I worked from home for five years before joining USDS, and I wish we could support remote work, but we're grafted onto agency projects that are so often based in D.C. that it's just not possible.

The "term-limited" positions are actually quite nice. Generally, you can serve for up to four years. USDS is almost 3 years old, and anecdotally it feels like people tend to leave by the end of their first two-year term because, well, it's hard and it can be exhausting. You lose effectiveness over time, and returning to the private sector is important to re-strengthen your skills and knowledge.

As it happens, the excellent career civil servants we work with also appreciate knowing we're there to help them, not take their jobs. :-)

[kelnos]

What also concerns me about that is maintenance. You're constantly bringing in new people to build new things who have no knowledge of what people in previous "tours" built. The overheard of all the handoffs and knowledge transfers that needs to happen seems unfortunately high.

[dkhenry]

While the USDS does build things, the model is to have them partner with career civil servants and contractors and get them to implement industry best practices. So there is still overhead when handing off between tours, but the bigger problem is finding capable contractors and vested partners at the agency's who can champion the new way of doing things.

[askldjd]

Our team is very careful at choosing technology that is stable and well proven. In fact, it took a lot of debate for us to move from Rails static pages to React SPA.

As for government being slow and only change once a decade, you might be underestimating engineers in the government.

Here's the disability claim processing project I worked on when I was on SSA Digital Service. https://federalnewsradio.com/ask-the-cio/2017/01/ssa-turns-c...

The team I worked with managed to pull off React/Node.js/Redis/Zookeeper microservice framework over AWS using Jenkins as CI/CD pipeline. And most of the team came from an older enterprise stack using Java and IBM WebSphere. They were able to adapt to the new framework.

Be conservative, yes. But being overly conservative is part of the reasons why government is so far behind today.

[noir_lord]

Interesting, when I said once a decade I didn't particulary mean changing anything I meant that the system as a whole has to last a decade.

I've stuff in production I wrote in 2007, it's the same system but lots of the parts have been replaced (bit of a Theseus/Triggers Broom philosophical point) over time.

I agree on the overly conservative point, what I find helps there is to consider the migration away from anything new you are considering, I usually ask myself the following question - "If the entire dev team for foobar disappeared tomorrow, how much would it hurt" if the answer is "not much because I can maintain it myself while migrating away" then thats very different to "a lot because I don't understand it that well and/or it's massively complex".

Enterprise is a different world (even for a medium sized one like I work for) because (frankly) a lot of the programmers are doing it purely for the money and/or simply aren't that competent.

Not all of them by any means but I run into a lot of code that is just plain horrible, not "not the way I'd have done it" so much as "how does this thing even work?" and "Who possibly thought this was the right approach?".

I'm weird, I like LoB software development - I find that done well the feedback loop is very gratifying, you get to have an immediate affect on the companies bottom line and you have happier employees also the problems have a lot of hidden complexity which is intellectually stimulating.

[nostrademons]

I think that much of the reason for the existence of USDS is that government agencies like the VA should not be stuck with 10-year-old [1] technology. The idea is that U.S. citizens should be able to expect the same level of technology from their government that they get from Facebook, Twitter, Apple, or Google. They're explicitly trying to change the culture where you do things once for hundreds of millions of dollars and then it's never revisited because the first time was such a clusterfuck.

[1] Actually more like 50 year old technology, if my friends at the USDS are to be believed. In some cases, they're replacing systems where SOP is to manually type in data, print it out, fax it over to another department, and then type it in again to a different system.

[alexose]

Those kinds of inefficiencies are /everywhere/ in government. They tend to mirror the limited ways departments communicate (see: Conway's Law). Having structured data available isn't a given, nor is the ability to send it across networks that often predate the internet.

I remember an incident where a critical feature went down for days because a backhoe severed the only available link between two agencies. It's hard to overstate how unusual it is by government standards to operate the way modern startups do-- e.g., put everything in the cloud and let Amazon handle your availability problems.

[mquander]

There's nothing that would prohibit maintaining a Backbone or Knockout app (or just one written with a bunch of non-spaghetti-code jQuery) today, and it's hard to say that any other choice for writing a piece of software with a GUI would have fared better. Why do you think that using React will have a worse result than that?

I think that of the kinds of tools people are using to make web applications in 2017, React and Rails are probably in the more conservative, most likely to be maintainable in 10 years category. (I wouldn't believe this about Rails except it's been so popular for the past 10 years.)

[noir_lord]

> There's nothing that would prohibit maintaining a Backbone or Knockout app (or just one written with a bunch of non-spaghetti-code jQuery) today

Well that kind of depends, I still have stuff in production with knockout and for some stuff I still use it but it's not just a matter of the framework/library it's the ancillary tooling.

We went through grunt, gulp, browserify and webpack fairly quickly, we could have stayed with any of them but no-one else did, if you stand still you end up been left miles behind when you eventually do want to move on.

The dozens of different bits approach has a lot of advantages but it has some severe downsides as well.

Modern JS is a bit of a red queen problem, you have to constantly adapt your codebases just to stay even on a 5-10 basis.

It's a problem in my world (enterprise LoB stuff in the browser), you want to be somewhat conservative while still be able to have some assurance of long term viability and some of the nice toys.

My approach has been to trade off dependencies as much as possible, I moved to TypeScript for a lot of stuff since it emits good JS so if it ever did go away I could just output the most recent JS and base from that (and I doubt TypeScript is going away in the next few years, MS has invested heavily in it as a platform for internal stuff).

Meanwhile over on the other side of things I recently ran something that was written in 'pure' Java 1.2 on the modern VM with not as many issues as you'd think (that platform is 20 years old).

I recently inherited a large enterprise system that is classic jQuery/no framework, it 'works' on a modern browser but it's an unholy unstructured mess and getting any kind of iteration velocity on it is a complete pain and that was written in over a few years finishing two years ago.

The developers just hadn't adapted to the modern landscape well at all and their momentum was terrible and getting worse.