I'd never in a million years argue that Deloitte did an awesome job on a large government contract, but it's mind-boggling to watch the regular ritual of HN posters blithely insist that anything more over $20K and a pile of pizzas for government infrastructure is a scam.

Not only do I think thats a strawman (I don't see that base level argument given that often on hn), but even if it wasn't, the truth is there is a lot, and I mean a fuckton, of money waste at the government level on IT projects. Trying to act like just because they aren't all a scam doesn't mean there isn't a systemic problem of waste that still needs to be addressed, and there are plenty of examples in even recent history that prove this point. More than just waste, the intention to fill good ol boy pockets in priority over getting the job done has significantly weakened the function of the projects, for example, the national security implications of abandoning thinthread that William Binney and Thomas Drake talk about... as just one in a myriad of examples. Virginia didn't have multiple counties become the new primary growth centers of millionares because of fair and balanced bids... and anyone pretending otherwise doesn't know how DC works.

The story of Healthcare.gov is pretty much the poster for this. They didn’t need to bring in a bunch of clever people to figure out requirements, that was already done and the site just didn’t work. To fix it they had to bring in a team of tech experts, who largely just did tech things —- competently and at a lower cost than the contractors who did the first iteration. https://www.google.com/amp/s/amp.theatlantic.com/amp/article...

While true, the team that was chosen also did not had the experience with public facing sites.

The contract was given to a team used to do intranet websites in classical JEE format and the letting them lose in such a project, designing as they knew.

https://changelog.com/gotime/154

> Trying to act like just because they aren't all a scam doesn't mean there isn't a systemic problem of waste that still needs to be addressed

No, of course not. But it's undeniable that these threads on HN (and other engineering-dominated forums) always include a healthy dollop of "I'd have done that better, because I'm a good software engineer" disdain. It's often paired with ignorance of how large-scale enterprise and government contracts and procurement work, what roles are necessary for large-scale projects with a significant discovery component, and what the planning process looks like when a team can't afford to launch-and-get-feedback or fail-fast-and-learn their way to a full specification.

I mean, this Deloitte project and the rollout are clearly a shitshow on a million levels. They got a no-bid contract for an eye-popping sum, then more than doubled it before the building even started! But the approaches boldly prescribed in most of the comments here wouldn't have produced a working system at the scale needed, either — only a cheaper broken one. A cheaper failure is still a failure.

Tech people are just as vulnerable to the Dunning-Kruger effect as the rest of the population.

Try offering it to them to do the job and see how quickly they change their tune.

> most missteps happen early, dooming projects before anyone sits down to code

This one is more insightful (in the big non-tech enterprise / government spaces). Because the takeaway for most HN developers who flip between projects should be: (1) learn how to recognize one of these projects & (2) stay away / find a new job when you do.

You'll save years of your work.

How might you recognize a project like this?

Ask yourself some critical questions.

- is the scope well defined?

- do I understand the value add and agree with it?

- do I feel as if all stakeholders are aligned and adequately involved?

- do I think the team can pull it off ?

- do I think the mood and style fits myself?

- do I think the timelines and budgets are realisitc?

- do I agree with the level of transparency from management?

Etc etc

Ask yourself these questions - and more - and you will discover the answer for yourself.

In the end listen to your guts.

One important nuance: A project can be a major fail overal but a big success for you. Big check, new knowledge, rich connections...

In addition to what others have said, from my previous experience:

- Does the customer have an IT org capable of fulfilling basic tasks you won't be authorized to do (app / db access, AD / rights modification, firewall adjustment, AV adjustment) in a timely manner?

- Can the customer provision necessary machines in a timely manner? If using VMs, is the virtualization team competent with their chosen platform?

- Does this project directly threaten the job of anyone whose blessing / help is required to successfully deliver the project?

- Is your leadership / your customer champion intelligent and willing enough to say "No" to scope creep when the customer gets excited?

- Do the PMs attached to the project have a basic understanding of how software is built and the systems involved?

- Does their management understand the actual processes being interacted with? (Major red flag! If their management / leaders say things in meetings that demonstrate a basic lack of understanding in what their own people do, run)

I think a tell-tale sign is if they apply the waterfall approach.

That won't save you at all. A lot of federal IT contracts are now written to mandate using Agile or Scrum. Many other forms of dysfunction that doom projects remain.

Didn't the guy who coined the term give it as an example of a development model that never worked?

they will say "agile", but will mean , "all requirements up front with an increment delivered every sprint".

which works very well if the developers and the customer really know what they want when the project starts.

It also almost certainly applies to whatever every person here works on, no matter what industry you're in or how close to pure tech it is. In fact, I'm not sure I can think of a single field where even the most brutally difficult software tech problem is actually the difference between success and failure. It can be a prerequisite, and it can often be a bottleneck to iteration speed, but it's never the real problem, which is something SWEs need to understand in order to move up into leadership.

It makes me wonder what the heck they do at their day jobs. Requirements gathering is the impossible part.

This guy governments.