Comment by exelius | Hacker News Reader

Comment by exelius | Hacker News Reader

Parent Full thread

I don't envy this guy; what he's dealing with is a very hard problem.

Government tech has the unfortunate problem of requiring instant scale. As in whenever you develop a new app or tool, it needs to roll out to a hundred thousand (or hundred million in the case of healthcare.gov) people and needs to integrate with dozens or even hundreds of different systems. Which of course, is the entire problem to begin with.

It's pretty obvious that the old way of doing things is not sustainable. Most people would say the answer is Agile processes; but that has drawbacks in a government context. Agile can mean many things. Depending on how you implement it, but there is an inescapable trade-off of efficiency for oversight. Government contracts need oversight; otherwise you have contractors who aren't meeting their obligations and collecting millions of dollars while throwing obviously unqualified people at a problem. Often nobody on the government side is even paying attention that the work isn't getting done until it's too late.

I really don't know what the answer is here. There are lots of problems with the government procurement process, but there is a lot of money on the line and the people receiving it have a vested interest in maintaining the status quo. Ultimately the procurement process is the biggest issue. Contracts go to the company that can navigate the procurement process most effectively; not the company best suited to do the job. Given the bureaucratic nightmare that is government procurement, any procurement process designed to find the best company for the job will still ultimately reward the companies most adept at gaming the system through back channels (e.g. calling in a favor with a Congressman to ensure the criteria for contractor selection benefit a specific company).

Agree, and having worked for the government (as a contractor) for over 20 years before leaving, I'll point out another issue. They want budget and schedule. Somebody has to pay for a system, and they can't go to the hill and ask for "some" money. Agile acknowledges that you don't know everything up front, but with that is the concomitant fact that you cannot give a budget and schedule. So, should the government hire me or you to do a job? Is it even worth paying for? And yes, am I executing on what I promised?

The results in messed up. We always strove, after winning, to write a rational requirements document that acknowledge the uncertainty. Most times they 'got it' and accepted that sort of management style, but there were also times when you'd be tasked to do something utterly useless because of some "shall" in a requirements document that is now hopelessly out of date. But it depends. A half million $ contract you can have that conversation. $60million+, several subcontractors? Not so much.

I would say that Agile processes is definitely a part of solution (and I have been part of Agile teams and implemented Agile processes within the government), especially because of the oversight it can allow.

It can allow more oversight; but that oversight comes at the expense of efficiency. It can be manageable if the organization is relatively flat, but that's almost never the case in government.

What eventually happens is that to give oversight to the decision makers on a sufficiently large project, your dev leads spend all day in status update meetings with scrum masters, who spend all day in status update meetings with project managers, who spend all day in status update meetings with directors and functional leads. Decisions are made a level above that, so you've got 5 levels of management in a big game of telephone.

It's still probably better than the alternative, but Agile doesn't give you the certainty around schedule and budget that waterfall does. There's a mindset in the government that often manages around schedule and budget ONLY; so it will take rooting out several generations of government project managers to really start to crack the problem.

Like I said, I don't envy the guy. But his bar for success is so low that it would be hard not to improve things.

"Agile" is very popular for upcoming next gen tech projects in the intelligence community partly because budgets are so erratic and progress is much more scrutinized than before (sequester may be over technically but you wouldn't think so if you look for job listings in the DC area). The problem is that even that process is not unaffected by the waterfall and spiral externalities of who these projects must ultimately answer to and (much more importantly) receive headcount and budget from to accomplish a goal. I'm familiar with one project where iterations / sprints took about 2 months each. Comparing this to the precedent of top 50 enterprise size orgs taking half a year to deploy one... or one thousand physical servers due to sheer bureaucracy in the name of checks and balances... well we should not be trying to compare ourselves to the worst to just make ourselves feel better. It's not like low morale is the primary reason for low performance in enterprise work for so long.

I think exclusive contracts should be abandoned anywhere they can be. Why should there only be one monolithic Healthcare.gov? Every single company that wants to should be able to build their own solution to this. They can be rewarded based on how many users they get, or the best one can win a bounty.

I agree that exclusive contracts should be abandoned where they can be, but for a much different reason: I have little or no confidence at all in the private sector to meet the requirements properly. A lot of the work done by private contractors ought to be done and maintained directly the government. The current system is not one of efficiency; it's one of corporate welfare.

>'I think exclusive contracts should be abandoned anywhere they can be. Why should there only be one monolithic Healthcare.gov?'

I completely agree with the first sentence conceptually, but think the second is a terrible fit for that concept.

A monolithic healthcare.gov actually makes a lot of sense as every implementation will necessarily have loads of shared functionality.

There's a reason state exchanges have spent multiples of what healthcare.gov has per sign-up. [1]

>'Every single company that wants to should be able to build their own solution to this. They can be rewarded based on how many users they get, or the best one can win a bounty.'

This isn't a throwaway chat app. The tacit Government approval of free-for-all collection of the SSNs, income and health coverage information that go into a marketplace application would not be wise.

1: http://www.npr.org/blogs/health/2014/05/08/310721495/healthc...

There were suppose to be 50 healthcare.govs. Unfortunately, the intransigence of some Republican governors have left us with more states than intended falling back on a Federal solution.

One of the governing principles of the ACA was that the states would be afforded the ability to experiment with their own approaches to meet the law's guidelines, the other states could replicate what worked. Would have been a wonderful opportunity to try 50 differnent ways to bid, design and build the same system...

I do not think what you are suggesting is a bad idea. But a counterargument would be that having many organizations doing the same thing might make it more expensive overall, by increasing the cost of overheads (e.g., every company needs to have its own HR department). Those costs may not manifest themselves outright, but they will go into the cost equation.

I really really wish that governments would define some specs for what a patient record MUST and MUST NOT do; and what the software must and must not do, and so on, and then just let software providers sell software to medical providers.

Reply on news.ycombinator.com