Live data from Hacker News

USDS Digital Services Playbook

playbook.cio.gov

31–40 of 103 posts

Re: USDS Digital Services Playbook

#31

I have a lot of heartburn reading something like this. I spent a decade in government consulting trying to implement anything resembling "data science" or "DevOps" and got repeatedly shut down by higher ups or by random bureaucrats that saw any modern practices, including any technology, as a threat. Excel macros working one day, then prohibited the next by new IT policies. Directors demanding that service line bosse…

Sounds like you want to do more then make a nice living in IT. Govt. IT for the most part isn't that, rather it's going with the easy/chill flow.

My kinda of place... no stress, drama (for chill .. go with the flow types), nice co-workers and you can pay the bills & then some!

Re: USDS Digital Services Playbook

#33

Earlier quoted context omitted.

Which is exactly what they do in 9.9/10 cases. As an example, Healthcare.gov was built via a contract with CGI.

Yes but this whole set of "playbooks" seems to be written for government agencies who are doing the work in-house. The playbooks aren't wrong, but it's silly to think they'll actually fix the issue of technology not being a government's core competency.

Yeah, that’s a fair point. It’s going to take more than a playbook to fix the problems, but there are some movements in the right direction. Government is just very very slow to change. Sometimes that’s a good thing, but not so much when it comes to technology.

Re: USDS Digital Services Playbook

#34
post #2

While this is all well and good it feels like a slick "thought leadership" campaign that provides little in the way of actual solutions to the issues USG orgs face when building/providing digital services. The challenge is not the "approach", but rather a system that constrains the ability to even begin that approach. I find #7 especially hollow: > We need talented people working in government who have experience cre…

https://smeqa.usds.gov/

We do work on hiring as well

Re: USDS Digital Services Playbook

#36

I have a lot of heartburn reading something like this. I spent a decade in government consulting trying to implement anything resembling "data science" or "DevOps" and got repeatedly shut down by higher ups or by random bureaucrats that saw any modern practices, including any technology, as a threat. Excel macros working one day, then prohibited the next by new IT policies. Directors demanding that service line bosse…

These plays can work. Why? Because USDS employees are government employees with escalation paths all the way up to the very top which gives them a lot of power to break down bureaucratic barriers to modern software development that government contractors & consultants would have no chance of doing. They then can bring in contractors to work in the relatively modern shell that they've created.

For example, here's a project started by the USDS in 2015. It's responsible for managing the complex bureaucratic process of VA legal appeals. (https://github.com/department-of-veterans-affairs/caseflow) It's open source, continuously integrated and deployed with close to 100% test coverage, deployed on an AWS GovCloud VPC, and was built on a fraction of the budget of similar systems.

Active development on this system is now done primarily by contractors now that the relevant bureaucratic barriers were removed.

How do we scale this story? More talented people with the desire to serve their country. It's not easy, but it can work.

Re: USDS Digital Services Playbook

#37
post #19

I think the biggest problem any US government agency has (federal or state) in producing services that leverage modern technology is that they cannot afford to pay people market rates. We have a mentality in the US that government cannot do anything right, but it seems of late (last 40 years or so) that we are kneecapping government's ability to execute and then complaining about it when it can't and making pronounce…

Another conclusion based on the same facts is that the government has no business doing its own technology and should do what they do for weapons and roads: contract it out.

There are a bunch of problems that result from contracting work out though.

The contracting process itself is an incredibly onerous burden with a huge number of factors other than mere technical ability (are you a disabled veteran minority-owned business?). And the companies with the fortitude and resources to actually make it through the contracting process tend to be the exact companies you don't want doing the work - it's not your scrappy 30 person startup that gets the bid.

Furthermore, those companies are the only ones that can, frankly, put up with the government's shit. The problem isn't just that the government doesn't have the technical ability or the culture to get the job done, they don't even have the ability to oversee a technical contract, and it inevitably results in weird and obtuse requirements, stumbling blocks injected from the contract coordinators, etc.

You can sometimes have a setup where one contractor executes and one contractor oversees, but anyone who's worked on a project overseen by one of those contracting management companies (DeLoitte, Accenture, etc) knows that doesn't fix anything either, and the contract coordinator isn't going to stop their bullshit either, now you just have twice as many layers of management shitting things up.

There's no magic bullet here, but management and IT services within the USG drastically need a shakeup, and increasing pay scales to match the private sector has to be there too. On top of that you basically need a top to bottom review of the regulations and SOPs. It's simply too hard to actually get work done, at every level. There is too much security theater, too little real security, too many fiefs, too many bosses, too many approval processes, too many dumb requirements that were coded into law 20 years ago when they maybe made a little sense but have long-since ceased to be best practices.

Also, contracts are for a specific and limited period of time. Often development and maintenance are under different contracts - which will be bid out separately. So the first contractor doesn't really care about anything except getting it out the door, then the USG will be super surprised that they're pulling the plug once they've met the bare minimum of the requirements, and then there's no money to actually maintain it on an ongoing basis. If there is, that money will be bid out again and probably goes to a different contractor.

Keeping it internal at least means that somebody has ownership of the project. Contracting turns everything into a game of hot potato with everyone racing to throw the potato as soon as they've done the bare minimum to accomplish their contractual obligations and get paid.

Re: USDS Digital Services Playbook

#38

I have a lot of heartburn reading something like this. I spent a decade in government consulting trying to implement anything resembling "data science" or "DevOps" and got repeatedly shut down by higher ups or by random bureaucrats that saw any modern practices, including any technology, as a threat. Excel macros working one day, then prohibited the next by new IT policies. Directors demanding that service line bosse…

Have certainly seen and experienced what you did, so I hear you. However, there are improvements slowly being made to be optimistic about. DevOps (or DevSecOps as they like to refer to it now...) is definitely becoming a more ingrained practice. If you’re interested, take a look at initiatives such as Cloud One, or some of the work being done by GSA (especially 18F) and USCIS (of all places). Interestingly, the 21st…

I'm curious how you've heard about USCIS' work / style?

I'm new to the system, so this is the only one I know (wrote about joining here: https://twitter.com/abachman/status/1217795232449859585), but I'm currently on a team of 6, all feds: 1 designer, 1 product mgr, 3 engineers and I'd say we're fairly to extremely self-directed. User-research based product development, pair programming, short iterations, deploying daily, all that jazz. Just a variation on the same sort of thing I've seen in the tech-first / software-product-company gigs I had in the past, but I've mostly worked for smaller indie or niche companies.

That is, I get to work in a way and with people and tools (Rails + React at the moment) that makes sense to me. How far outside the norm are we and where could I go to learn more about the whole system?

Re: USDS Digital Services Playbook

#39

I have a lot of heartburn reading something like this. I spent a decade in government consulting trying to implement anything resembling "data science" or "DevOps" and got repeatedly shut down by higher ups or by random bureaucrats that saw any modern practices, including any technology, as a threat. Excel macros working one day, then prohibited the next by new IT policies. Directors demanding that service line bosse…

I agree with the sentiment that there are cultural issues with the federal space, and it requires continuous diligence of dedicated people to change the landscape and move the needle. Devops take a long time to grow organically - and it's longer in the federal government due to silos, compliance, finance, regulations.

The list is a nice dream, and it is with the will of those in the federal work force who can break down those silos and bring about a common understanding with urgency that'll make it happen for their project.

Re: USDS Digital Services Playbook

#40

I have a lot of heartburn reading something like this. I spent a decade in government consulting trying to implement anything resembling "data science" or "DevOps" and got repeatedly shut down by higher ups or by random bureaucrats that saw any modern practices, including any technology, as a threat. Excel macros working one day, then prohibited the next by new IT policies. Directors demanding that service line bosse…

Have certainly seen and experienced what you did, so I hear you. However, there are improvements slowly being made to be optimistic about. DevOps (or DevSecOps as they like to refer to it now...) is definitely becoming a more ingrained practice. If you’re interested, take a look at initiatives such as Cloud One, or some of the work being done by GSA (especially 18F) and USCIS (of all places). Interestingly, the 21st…

[deleted]
Post reply on HN