Comment by rayiner | Hacker News Reader

Comment by rayiner | Hacker News Reader

Parent Full thread

Interesting quote from the article:

> 'You have companies like Lockheed Martin -- they're not web development companies, they don't do work in the private sector, they're not building start-ups,' Gershman said. 'There's very little in the market that forces them to adopt new technologies.'

All of these are true, but I think this glosses over some fundamental structural problems with government contracting. The SSA has almost 60 million beneficiaries, and deals with distributing an entitlement that is extremely sensitive and protected by layers of legal process. 8,000 Social Security checks get lost,[1] and its not a blog post, its national news.

Moreover, a lot of lean and agile processes just aren't consistent with political reality. There's no minimal viable product, there's no invite-only beta testing, there's no iteration, there's no A/B testing, etc. Technical decisions ("let's just roll out to northern Alabama first") become divisive political ones. Purchasing decisions ("we've had good luck with this vendor before") become the basis for accusations of favoritism and corruption.

Perhaps most importantly, there's no failing fast. The private sector accepts the fact that many engineering projects will fail.[2] Good companies take care not to punish failure unreasonably. But in the public sector, failure is just license for those opposed to project to crow: "we shouldn't have been doing this anyway!" If you fail fast, it's easy to pin the blame on you. This creates a perverse incentive to drag a project along so failure happens over years if not decades.

[1] https://medium.com/@jan.curn/how-bug-in-dropbox-permanently-...

[2] Most big IT projects fail: http://www.computerworld.com/s/article/9243396/Healthcare.go.... Most startups fail. Most internal prototypes never amount to anything. This is just how engineering works.

Later on the article describes the project as being "adrift" with ill-defined requirements and scope. That will kill absolutely any project and is a completely separate problem from technology. Lockheed failed at the engagement level to define scope. Their development team didn't have a prayer.

Pretty much all government IT projects have ill-defined requirements because GS-15s and Field Grade Military Officers are like little kids. They change their minds frequently and they are so used to having their way that they simply won't take "no" for an answer. You can't explain to them that it will ruin a project because the overwhelming majority of them go through life thinking that they know everyone else's job better than they do. Because of this a typical government IT project will keep having requirements added until the last day of the contract.

You are right, the development team never had a real chance at achieving success.

It's worse than that. It's not just GS-15s. It starts with Congress.

Congress writes the bills that somebody (higher than GS15s?) turn into implementing regulations that GS-15s turn into program requirements. If Congress writes bills that are simple, clear, and short, then you have a chance at simple implementing regulations and therefore simple program requirements (not certainty, but a chance). But if Congress writes convoluted, lengthy crap, it's almost impossible to write a program that will correctly implement it.

>higher than GS15s?

Yeah, I forgot to mention Congress and the SES(the higher than GS-15) guys. Yet, even when there is a simple set of program requirements, the guys I already mentioned are going to keep adding shit on until the very end. If you give a high-ranking government employee authority over an IT project, they start imagining that they are Steve Wozniak, Bill Gates, Johnny Ive, Steve Jobs, and Leonardo DaVinci all rolled into one. Then bad things happen.

And... Congress can change the law halfway through the project and then what? That's the ultimate requirements change, and no way to push back.

>>Perhaps most importantly, there's no failing fast. The private sector accepts the fact that many engineering projects will fail.[2] Good companies take care not to punish failure unreasonably. But in the public sector, failure is just license for those opposed to project to crow: "we shouldn't have been doing this anyway!" If you fail fast, it's easy to pin the blame on you.

This is not unreasonable. After all, projects in the private sector are funded by private funds. If you fail, you only waste your own money. Whereas public projects are funded by the taxpayer. When they fail, what's really happening is that taxpayer money is going into the pockets of some private company, but there's only a failed project to show for it. So yeah, of course the backlash is going to be much stronger.

In the private sector, investors provide capital that companies (and employees thereof) use to pursue projects. When the company fails, the employees are generally still paid (while some companies have employees who participate in profits / share risk with investors, it's rare for it to be a dominant form of compensation). Thus, the situation is more similar than you describe: if the projects fail, the investor/owner has paid out a lot of money to employees and vendors and is left with nothing.

The difference is that smart investors/owners are aware that the possibility of failure is inextricably tied to any attempt to excel, and allows people to try things that might fail in the pursuit of success.

In our current political climate (and probably in other climates as well), governments are dumber, and tend to drive their staff to manage towards over-safety and covering of asses rather than towards best outcomes.

All of what you say is correct; but I think the answer is to look for ways to change the status quo. There are ways to do that, it just takes engagement and creative thinking.

Can't you build an MVP with dummy data?

Reply on news.ycombinator.com