Doesn't it seem wasteful that 18f spent all that time on the standards, instead of maybe a guide/theme on how Gov't sites should adapt, already open-sourced (bootstrap), frameworks?
Take a look at https://github.com/18F/web-design-standards/blob/staging/LIC... and count the number of existing open-source projects which they're re-using. This looks to me like an experienced team who did their homework to assess how much flexibility and control they needed and reused as much open-source as possible while still meeting their other requirements.
Frameworks and standards like that are more often needed because there's a huge ecosystem of custom, proprietary libraries and frameworks that also exists within government. Previous attempts to try to release standards that only address specific frameworks that are popular within the open source world may only ever apply for 20% or so of federal agencies. There's even "agency-specific" forks of open source software that looks nothing like what they were based upon now. But really, you have tons and tons of different frameworks out there that have wasted taxpayer money delivering nothing material in value except "the government owns its IP" meaning "it avoids political / legal problems." See https://github.com/ozoneplatform/owf-framework for an example
Second of all, nothing precludes them from releasing standards-compliant variants of frameworks after the higher level standards are complete.
Please help make changes in the most efficient way possible. I've seen it before when these digital agencies filled with "innovators" come only to reinvent the wheel; spending ridiculous amounts of tax payer dollars and man hours to create things that could otherwise be brought in from the private sector.
Good luck, do what's right with the tax payer dollars.
Failure should result out of poor leadership in the end. On my team I don't care for your gender, your race, your culture or your social image. I only care that you can get the job done. If I know you can, then I'll give it to you. If I think it allows for time to learn, then I'll give it to the ones who need to grow. If you think you aren't given a chance, then speak up and I'll give you a shot at something. Poor leaders will deny those opportunities.
But I believe that there is more good leadership as opposed to poor leadership in our industry, and that articles like this create misguided issues.
Also, it is too easy for anyone to go and find another job; especially if they have talent. A full on exit means something else, something these articles haven't shown yet. For example, my last experience with this type of issue was with a coworker, a gay black male, who decided to quit in the middle of a project he was leading. He was falling way behind and presenting demos with bugs & poor functionality. All would've been fine and understandable if it weren't for the developer misleading the boss and stating that the project was on track and doing well. After continuous failure our boss eventually gave him extensions but was obviously was not happy about it. The boss began to put pressure on and keep a watchful eye over new commits. The senior ultimately chose not to continue and quit. On his way out he complained of bullying and not being appreciated. He declared that he was a senoir and should've been included in more decision making and that other senior developers were treated with higher favoritism because they got "cooler projects" and he did not. He was partly right, but only because he had not shown that he could get the work done, and rather shown quite the opposite. He had never proven his skills when given the chance. He faltered at all chances and yet still had some type of delusional self-entitlement. He left and his project was delivered 2 months late even after his poor code-base was heavily refactored by the next lead. I recently chatted him to ask how he was doing and he stated that his experience on our team and with our boss was so negative that he hasn't looked for a new job yet, and is even considering a career change. I agreed that he should do what is good for him, but only because I consciously knew he is in no place to be a senior developer in this industry (but he will never tell you that, and neither will any journalist trying to make a story out of it).
As someone who develops for a Gov't agency, this is the wrong move. So much money has been spent on mimicking the private sector innovators. Millions and millions of tax dollars spent on these type of projects.
The focus really needs to be on building a process to better integrate private cloud services and gov't applications. I mean they already are for the most part: https://aws.amazon.com/compliance/fedramp/
You listed two IaaS provider and one SaaS provider. cloud.gov is a PaaS provider. There is no FedRAMP PaaS available to agencies, and PaaS is the level of abstraction needed to accelerate delivery of services the government itself provides.
We also leverage the fact that AWS GovCloud already has FedRAMP status as an IaaS to accelerate our delivery of cloud.gov (which sits on top of it), so we're piggy-backing on the money and effort already spent and eliminating the millions we would otherwise spend by having the government run the IaaS layer.
In other words...
> The focus really needs to be on building a process to better integrate private cloud services and gov't applications.
Actually, there are several FedRAMP PaaS' available to agencies. A quick look at https://www.fedramp.gov/marketplace/compliant-systems/ lists several compliant PaaS offerings, including one (Autonomic Resources LLC – ARCWRX) based on OpenShift. It's great to see activity in this space.
Acquia is FedRAMP accredited as well. Acquia is optimized for Drupal. Drupal now powers 40% of .gov sites in the US (and growing). It's a fully managed and supported platform, which offers not only the CLI integrations that developers appreciate but accessible, responsive GUI DevOps tools and 24/7/365 application support.
I don't use apex. I use serverless. but it's probably the same idea. All the work of transpiling, minifing, creating lambdas, api gateway, aws resources, stages etc... are done automatically from the command line. You don't need to compile/transpile your code, create a zip, upload to s3, create a lambda import the zip from s3, create the endpoint, connect to the lambda, create the api gateway template, etc... And do this every time you change something in your code. It gets frustrating really fast when doing it manually.
Once you get beyond "just started" you'll see the value of these tools :-) The charm of Lambda is that it's easy to get rolling, but then the AWS complexity seeps in. This helps deal with a _lot_ of that in a pretty sane way.
The AWS UI and console are great for <10 functions. 100 functions... not so much. It becomes necessary to automate things and Apex provides that. If you are just getting started, I'm not sure it is "better". But if your entire stack is lambda funcs its almost necessary to keep your sanity.
