Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The way government does tech is outdated and risky

washingtonpost.com

Post reply on HN
Print view View original

111–120 of 145 posts

Re: The way government does tech is outdated and risky

#111

Post by allochthon »

apendleton wrote: post #25
squidfood wrote: post #17

Federal Gov employee here. Can't speak for a project with this scope, but the procurement middlemen get into everything, far for the worse. Two years ago our team wanted to buy a small cluster (~300 cores, ~$50K). We talked directly to two good vendors (good recommendations from university partners) and came up with a fine machine and 2 bids for it. Sent recommendations to procurement. Procurement put it out for bid,…

I just had a conversation with a federal employee last week talking about the issue of procurement offices being a blackbox and procurement officers not understanding the technical specifics of what they're bidding out. His solution was just to become certified as a procurement officer (apparently it's 72 hours of coursework) and deal with the bids himself. He said these kinds of problems have pretty much disappeared…

According to US federal procurementology, would it be a conflict of interest to be both procurer and recipient of what is purchased?

Re: The way government does tech is outdated and risky

#112

Post by apendleton »

allochthon wrote: post #111
apendleton wrote: post #25

Earlier quoted context omitted.

I just had a conversation with a federal employee last week talking about the issue of procurement offices being a blackbox and procurement officers not understanding the technical specifics of what they're bidding out. His solution was just to become certified as a procurement officer (apparently it's 72 hours of coursework) and deal with the bids himself. He said these kinds of problems have pretty much disappeared…

According to US federal procurementology, would it be a conflict of interest to be both procurer and recipient of what is purchased?

He's overseeing the bidding process for contractors for projects that he will supervise; he doesn't personally benefit from the outcome of the selection (i.e., he doesn't own stock in companies that are bidding or anything like that), so I'm not sure how it would be a conflict.

So no, I don't think so.

Re: The way government does tech is outdated and risky

#113

Post by jacoblyles »

bchjam wrote: post #2

Does anyone else find it ironic that Obama's campaign was a picture of web execution but in his administration it's the opposite?

If someone does a bad job on a campaign, he gets fired and replaced with someone that can do the job better. Campaigns run on a limited budget - they don't have all the money in the world. They have a well defined goal and strict timeline.

Pretty much the opposite of a government project.

Re: The way government does tech is outdated and risky

#114

Post by allochthon »

sien wrote: post #43

It's not just the US government that has crazy, weird, inefficient technology. I'd be surprised if every government wasn't like this. The biggest IT failure in the world was the UK's attempt at healthcare computing that cost 12Bn GBP and didn't deliver a functioning system. I work as a contractor for the Australian government. I personally know of multiple project failures in the 10s of millions of AUD range and a fe…

You make some good points.

Thinking a little more about the situation, consider that the majority of startups fail. I would not be surprised, if one were to take a look at the success rates of internal projects in large companies, to learn that those are fairly low as well. So if the private sector is more efficient than the public sector in IT, the differences are probably more subtle than one would at first think. In both cases you have lots of capital being spent on projects that won't come to fruition. Perhaps the incentives in the private sector are a little better aligned towards a successful outcome.

Re: The way government does tech is outdated and risky

#115

Post by Proleps »

derleth wrote: post #78
JanneVee wrote: post #64

Earlier quoted context omitted.

One case I've heard is when you don't have any changing requirements and the domain is well known. E.g. engine control software.

If the requirements don't change and the domain really is well-known, why are you writing new software? Why isn't there pre-existing software you can reuse?

Because it doesn't exist yet.

Re: The way government does tech is outdated and risky

#116

Post by discodave »

xarien wrote: post #80

Coming from a 6+ year stint in a defense contracting, I can safely say that the issue with this approach happens well before the testing. The problem more often than not occurs at the requirements level.

I would argue it happens at an even higher level the 'planning' level.

One of the basic philosophical differences between the agile and waterfall approach is that agile assumes that you cannot know all the requirements at the beginning of a project. You must start building things before all the little dirty edge cases become obvious. Additionally you don't actually know if you're going in the right direction until you have something concrete to work with, even if it's mock ups or wire frames.

What I think they should of done in this case is rolled out the site in stages, probably starting with one state that had an easy backend to work with and gradually adding complexity to the site.

Re: The way government does tech is outdated and risky

#117

Post by mcpherrinm »

derleth wrote: post #78
JanneVee wrote: post #64

Earlier quoted context omitted.

One case I've heard is when you don't have any changing requirements and the domain is well known. E.g. engine control software.

If the requirements don't change and the domain really is well-known, why are you writing new software? Why isn't there pre-existing software you can reuse?

Because you can save a quarter cent per unit by changing microcontroller vendors, but you have to use a new programming language for the new one?

Because you are involved in a lawsuit with the contractor that produced your previous version and using it would possibly be an admission it met requirements, even if your in-house developers had to completely rewrite it to make it safe?

Because new safety regulations mean you have to use a FIPS approved compiler and testing procedure?

Because it's a niche product and the only people in the world who know the problem domain work for you?

Re: The way government does tech is outdated and risky

#118

Post by JanneVee »

derleth wrote: post #78
JanneVee wrote: post #64

Earlier quoted context omitted.

One case I've heard is when you don't have any changing requirements and the domain is well known. E.g. engine control software.

If the requirements don't change and the domain really is well-known, why are you writing new software? Why isn't there pre-existing software you can reuse?

If you are designing a new car engine there isn't always of the shelf software already designed and tested. There are instances like the Ariane 5 maiden flight[1] where Ariane 4 software was reused.

[1] http://www.di.unito.it/~damiani/ariane5rep.html

Re: The way government does tech is outdated and risky

#119

Post by nyrina »

joeblau wrote: post #12

This isn't going to change until there is a thought process shift for leaders on both the government and contractor side. I worked on a project that fought tooth and nail to create a project using an agile development process and it was one of the best projects I worked on for the government. It was killed due to politics, but the feedback, functionality, UX, and collaboration up to that point were great. Everything…

Sounds a bit like the contract I sent to India a few months ago.

One of my requirements was that it was able to send text messages.

What I got, was a ticked box, and an application that could also send text messages to 1 number. No, a number I could choose. One number as in, one cell phone.

And it wasn't even my own cell phone

Post reply on HN