Live data from Hacker News

The way government does tech is outdated and risky

washingtonpost.com

131–140 of 145 posts

Re: The way government does tech is outdated and risky

#131

Earlier quoted context omitted.

> I firmly believe that procurement acts this way not because the government is fundamentally incompetent, but because the Public, and thus Congress, BELIEVES we are incompetent There's almost 3 million federal workers. Many more if you include people who work on government contracts. The Federal Government is by far the biggest enterprise in the US by both employees and revenue. With such a large organization, there…

> Honestly I'm not sure what a good solution would look like, but I don't think it's as simple as "trust us." I agree -- this is not a simple challenge. But I don't think stultifying bureaucracy is the answer, either. There must be some government out there, somewhere in the world, that has sorted out an efficient, effective procurement process.

Perhaps you should look at the smaller countries. Like Singapore?

Re: The way government does tech is outdated and risky

#132
post #50
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…

I kind of like the idea of every government function has two independent providers that compete for funding, and citizens could choose which provider to use. I'm sure that system would blow up in some other way, however.

Just vote with your feet.

Re: The way government does tech is outdated and risky

#133
The most important part of this article is paragraph two, for without the exclusivity present in the government procurement process, it's unlikely we'd have a lack of innovation in regard to development practice.

I've led or worked on tech contracts and grants for ED, HHS, NSF, CDC, and others. Several people have pointed out some important points that are not getting enough attention in my opinion:

by @mcone: "The procurement rules were designed for that, yes. But in real world scenarios, those rules effectively do exactly the opposite. Since there are so many hoops for potential vendors to jump through, only the most established players get to bid on most contracts. And in my experience corruption and cronyism is still alive and well in federal IT contracting."

It's true, incest between government and industry is rampant and has led to wide spread cronyism despite the system's best efforts to limit the effects. People that once worked for company X, now serve on the proposal review panels when company X competes for work. No, they don't receive direct compensation and thus there is no immediate conflict of interest, but the reality is humans are drawn to (or don't want to disappoint) the people they know (former colleagues) and thus pick their old companies. In addition, they know there is a chance they may once again return to said company (so there is long term conflict of interest potential).

Another point that hasn't been discussed is how the government's procurement process provides next to no incentive for companies to efficiently produce good products. If our industry loves the DRY concept, everything about the gov procurement process points to a !DRY (or do repeat yourself). We built and rebuilt the same database for offices of the government that shared a building with one another. But because everyone is in a silo, they don't collaborate well and don't realize that they could pool their needs to develop more universal products. (And on the industry side, as long as gov continues to work this way, they don't even have an incentive to re-use their work or propose innovative, generalizable solutions.)

And for those of you that might say, 'but can't you win a gov contract by bidding lower by working off of existing work?' The truth is price has very little to do with who gets selected for a gov contract.

Re: The way government does tech is outdated and risky

#134
post #129

Earlier quoted context omitted.

I always thought waterfall was inherently iterative you could jump back up the stack at any point in the process one sucsessfull project I worked on at BT (management system for the Uk's SMDS network) had several instances of going back and redoing stages before we even got to the final development phase.

Have you ever seen water jump back up a few stages of a waterfall? (Hint: no.) It's called the Waterfall model exactly because that kind of thing is explicitly not part of it (see Figure 2 in the Royce paper linked above). That's the whole point of the name. It goes without saying that no software development effort has ever lived up to this standard. Nonetheless, the fact that it is not possible to develop non-trivi…

You're being a bit too literal. The name came from the resemblance of a diagram in the paper to a waterfall. The name wasn't meant to constrain the methodology to strict characteristics of a waterfall. The steps are meant to be followed in order. It is gated. But, nothing constrains the steps from being repeated. That is the crux of the difference between Dr. Royce's paper and what the military formed as a standard based on the paper.

I took a college comp sci course a few years ago. The professor talked for a few minutes about the Waterfall methodology. In short, she said "we in academia gaffed by promoting the Waterfall methodology for several decades. It's now cause for laughter in academic circles when someone proposes the Waterfall method for software development."

Re: The way government does tech is outdated and risky

#135
post #129

Earlier quoted context omitted.

I always thought waterfall was inherently iterative you could jump back up the stack at any point in the process one sucsessfull project I worked on at BT (management system for the Uk's SMDS network) had several instances of going back and redoing stages before we even got to the final development phase.

Have you ever seen water jump back up a few stages of a waterfall? (Hint: no.) It's called the Waterfall model exactly because that kind of thing is explicitly not part of it (see Figure 2 in the Royce paper linked above). That's the whole point of the name. It goes without saying that no software development effort has ever lived up to this standard. Nonetheless, the fact that it is not possible to develop non-trivi…

The first formal description of the waterfall model is often cited as a 1970 article by Winston W. Royce,[4][5] although Royce did not use the term "waterfall" in this article. Royce presented this model as an example of a flawed, non-working model.[6] This, in fact, is how the term is generally used in writing about software development—to describe a critical view of a commonly used software development practice.

http://en.wikipedia.org/wiki/Waterfall_model

Re: The way government does tech is outdated and risky

#136
post #125
post #121

Earlier quoted context omitted.

This is simply historically incorrect. Waterfall means a single pass by definition. Royce described the pre-existing state of the art - the single-pass model (Waterfall) - and suggested a modification to a 2-pass model. (This can be seen as a precursor to Boehm's n-pass Spiral model.) To suggest that the single-pass model was invented later as a corruption of Royce's paper is nonsense. Virtually all software was deve…

In the version of the paper linked earlier in the forum, I take the following to mean two passes: build a model and then use lessons learned to build the final product. But it's a matter of interpretation and semantics. My own interpretation is contradicted further down in my comment by someone from that era (see the Larman paper linked). C'est la vie, I'm sticking with my interpretation. I think we can agree that Ro…

The mistake I believe you're making is in assuming that because most people reference Royce's paper for a description of Waterfall, that means that the definition of Waterfall is whatever the main subject of that paper is. This does not follow.

The paper describes a number (more than 2) of possible models. The main subject of the paper is probably the "2-pass waterfall" diagram in Figure 7. However, when people refer to this paper in the context of the Waterfall model, they mean Figure 2. The Waterfall model is called the Waterfall model because Figure 2 looks like a waterfall, with the water never flowing uphill.

Figure 7, however, was largely ignored. (Though Brooks later recapitulated it as "Build one to throw away; you will, anyhow". I don't know whether it was influential in the development of the Spiral model or not, though it seems like a logical progression.) As far as I know this model never even got a name attached to it. Its influence pales in comparison to Figure 2, which was the first and best published reference to a design process that almost everybody accepted as "ideal" at the time.

Note that when Brooks tells the story in The Mythical Man-Month about making the mistake of getting a large group of mediocre engineers to write specifications instead of giving the job to a small group of elite engineers because he didn't want the larger group just sitting on their thumbs for a year, this was all happening in the mid 60s. Here's another contemporary quote:

The most deadly thing in software is the concept, which almost universally seems to be followed, that you are going to specify what you are going to do, and then do it. And that is where most of our troubles come from. The projects that are called successful, have met their specifications. But those specifications were based upon the designers’ ignorance before they started the job. —Doug Ross, 1968

Winston Royce did not invent the Waterfall model in 1970, he was just describing the already-dominant paradigm as a prelude to proposing something different. The model had been around forever, Royce provided a convenient diagram (Figure 2!) in the course of trying to critique (or even replace) it, and the name "Waterfall" got attached later.

> Note that, in the section referencing DoD-Std-2167, the author of the DoD standard does state explicitly that he understood Waterfall to be one-pass.

Of course he did, and he understood it correctly. The thing he didn't understand was that it was a terrible idea.

Had he (properly) read Royce's paper, he would have seen that it actually advocated a slightly better (but still pretty terrible) idea, but that idea was not and is not the Waterfall model. The Waterfall model is the one in Figure 2 that looks like a waterfall. Hence the name.

> My own interpretation is contradicted further down in my comment by someone from that era (see the Larman paper linked). C'est la vie, I'm sticking with my interpretation.

Um, OK then.

Thanks for the link though, it was really interesting.

Re: The way government does tech is outdated and risky

#137
post #131

Earlier quoted context omitted.

> Honestly I'm not sure what a good solution would look like, but I don't think it's as simple as "trust us." I agree -- this is not a simple challenge. But I don't think stultifying bureaucracy is the answer, either. There must be some government out there, somewhere in the world, that has sorted out an efficient, effective procurement process.

Perhaps you should look at the smaller countries. Like Singapore?

I like that idea. There might be a good process in place at a smaller scale that can be scaled up.

What is it about Singapore's procurement process that stands out to you? (I don't know anything about it.)

Re: The way government does tech is outdated and risky

#138
post #119
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

On their end they are probably saying "Mission Accomplished." I'm laughing because of the situation, but that is just terrible.

Re: The way government does tech is outdated and risky

#139

That diagram for the "waterfall" approach that they yanked from Wikipedia is a complete straw-man representation. It's nonsense. Here is the actual, original source for the Waterfall approach, first published in 1970: http://leadinganswers.typepad.com/leading_answers/files/orig... If people would just bother to scroll past the first couple of pages, they will notice that the approach already includes some iteration c…

No, I wouldn't call that a complete misunderstanding; I'd call it a minor simplifying inaccuracy.

Quoting Dr. Royce:

> Management of software is simply impossible without a very high degree of documentation.

How much documentation?

> In order to procure a 5 million dollar hardware device, I would expect that a 30 page specification would provide adequate detail to control procurement. In order to procure 5 million dollars of software I would estimate a 1500 page specification is about right in order to achieve comparable control.

5 million 1970 dollars is equivalent to about 30 million 2013 dollars, so for a $30 million project, his advice is:

1. Write a huge stack of documentation. Literally stop everything until that documentation is written.

2. Get feedback from reality and from your stakeholders exactly once.

Sure, having one opportunity to act on feedback is better than never having any, but it doesn't fundamentally change the process or the risks involved.

What the Agile folks realized is that reliable software development is an experimental process. If you only do one experiment, you're still missing that point.

Re: The way government does tech is outdated and risky

#140
post #136
post #125

Earlier quoted context omitted.

In the version of the paper linked earlier in the forum, I take the following to mean two passes: build a model and then use lessons learned to build the final product. But it's a matter of interpretation and semantics. My own interpretation is contradicted further down in my comment by someone from that era (see the Larman paper linked). C'est la vie, I'm sticking with my interpretation. I think we can agree that Ro…

The mistake I believe you're making is in assuming that because most people reference Royce's paper for a description of Waterfall, that means that the definition of Waterfall is whatever the main subject of that paper is. This does not follow. The paper describes a number (more than 2) of possible models. The main subject of the paper is probably the "2-pass waterfall" diagram in Figure 7. However, when people refer…

Note: in the 20th anniversary 2nd edition of The Mythical Man Month (http://www.amazon.com/The-Mythical-Man-Month-Engineering-Ann...), in one of the new chapters, Brook's backs off of his original "Build one to throw away" advice.
Post reply on HN