Hacker News Reader

Comment by octorian | Hacker News Reader

I would argue that software written under government contract is inherently awful and unusable, because...

- It is driven entirely by formal requirements and specifications

- These requirements are approved by "the customer," which is a set of people completely independent from "the actual users."

- A requirements document cannot easily capture "the UI/UX doesn't suck," because that sort of thing often tends to be more subjective or not well thought out in advance.

- The developers often pat themselves on the back for meeting the requirements.

- The customer has to accept the software and foist it on the users, because it meets the requirements.

...and...

- The competition is entirely about who gets the contract to build the software, and not for which software is actually the best.

View on HN

The biggest issue with software written under government contract, firm fixed price contracts. The way these are handled is not a good way to handle software. The winning contractor has a set of requirements for the software they have to deliver. If the customer wants to change anything, there has to be a bidding process and either a new contract or an add-on contract is awarded. This makes the customer very hesitant the make changes to the requirements even in the face of user feedback.

There is also no way to get user feedback until after the final software is delivered. It would have made life so much easier when I was a contractor if we could have had a group of users come in and see the software and make recommendations for the UI.

> ...There is also no way to get user feedback until after the final software is delivered.

That's what seems so very puzzling in these stories. These shortcomings in the delivered software appear more like insufficiently tested requirements (of course, the execution could be the sole reason too).

I'm not sure if contractors are needed in order to test the requirements against the actual use-cases _before_ even initiating a bidding process for developing any systems/software.

After all the force probably wants to describe what's needed. Someone has to make sure the desired new capabilities align with actual existing and desired workflows.

Perhaps, in this navsystem case, the ability to efficiently analyse/visualise the region's depth profile could have been stated in concrete use-case form, including the response times, scaling etc. This would then become the basis to test at the acceptance stage.

The thing about this is the best software stack I've ever worked on was for a government system, driving geointelligence ground processing for the NRO. It is still light years ahead of anything I've ever seen in the commercial world, but it's driving automated systems, so there is no UI. Anything I've ever worked on in the IC or DoD that had a UI pretty much universally had a terrible UI, and I agree the root of the problem is the absolute firewall between development teams and end users. Beyond that, though, individual acquisition offices often seem quite hostile to their own users and don't make any attempt to acquire software they'll actually like using.

That last part is key.

I suspect some form of X-prize approach would be worth trying - seed out a large number of small ISVs for government software (from license management to submarine firing systems).

Spend the money not in the requirements (which as you say are usually written by a non developer with minimal experience of the problem - after all if they were an expert they would have other more useful things to do) and spend the money on building automated test rigs.

I know I sound trite, and this is not even the best way (which is to organically grow solutions to problems), but we have a small window - software is eating everything and we will need to write the first generation of software that covers all politics and I damn well want that to be open to everyone to read. The software that runs governments will essentially be law. We should be free to read our laws

> - It is driven entirely by formal requirements and specifications

Can you explain why this is a bad thing? I've found that formal requirements and specifications are almost always good unless they're just vague (in which case: they're not really formal)

> - These requirements are approved by "the customer," which is a set of people completely independent from "the actual users."

Well, yes. That is indeed a problem.

> - A requirements document cannot easily capture "the UI/UX doesn't suck," because that sort of thing often tends to be more subjective or not well thought out in advance.

I've found that very very few people actively request people to say "your UI sucks". Instead, they want "constructive criticism" and/or "describe why it sucks!". Which, is sort've fair. But it gets to be extremely tiring to explain why the UX doesn't "just suck" but is fundamentally flawed.

> - The developers often pat themselves on the back for meeting the requirements.

Nothing wrong with that either.

> - The customer has to accept the software and foist it on the users, because it meets the requirements.

The customer has to accept the software because that's how contracts are done. But they don't have to foist it on the users. They just want to show that they've been able to deliver on their promise of a software solution.

> - The competition is entirely about who gets the contract to build the software, and not for which software is actually the best.

Well that's quite a problem.

> - It is driven entirely by formal requirements and specifications Can you explain why this is a bad thing? I've found that formal requirements and specifications are almost always good unless they're just vague (in which case: they're not really formal)

I have been in various projects for government and enterprises (non military, mostly medical and banking fields) with formal requirements and some without. I can say that those without always had better GUI and people using them liked it better. I think that one major reason is that most people can't really imagine application without actually using it. Only once they are using it they can give you useful feedback (as in this is important, this isn't, make that action default etc.)

Another reason is that people that are not using it are writing requirements. For instance in a lot of medical applications, people who will write specs and requirements are Business managers or doctors (or both), but not radiology technicians and nurses that will actually use the software. So they have no idea of day to day workflow - just desired outcome. So software will suck 100% if based only on their requirements (in my personal experience).

The problem is the lack of a feedback loop. Formal requirements will never accurately reflect what is actually needed unless there is a feedback loop that makes it possible to improve/update the formal requirements as problems/issues are discovered during development. Changing a single UI element requested by astronauts apparently takes a year for NASA and a day for SpaceX. Guess which software works best?

I definitely agree that not being able to capture "UI/UX shouldn't suck" in a formal requirement is a problem. Developers have to be vigilant, or get a lot of help from QA (typically the latter).

In my experience, though, there is a bit of a feedback loop during government test events since those are often staffed by real end users. If the end user doesn't like the software they can just say it failed the test, even if it did meet the requirements as written. So at least there's a bit of an upside there.

It would be nice if that feedback with the end user could occur earlier in the process though.

Reply on news.ycombinator.com