Sure, many people make the same mistakes. I'd hope that for a BILLION dollars, you could hire a couple of project managers who are actually competent. Plenty of companies have incompetent people, but plenty have lots of competent people who successfully complete projects - Google, eBay, Facebook, and a thousand other companies are competent at large scale IT projects.

If, like most projects, your budget is around $100K, you might end up with some typical incompetents in key positions. For a billion bucks, you should be able to have really, really good people in the key leadership positions making sure the project gets done. Was the person running the healthcare.gov project competent? Nobody was running it! I hope that's not like your typical project, I hope you actually HAVE a project manager at the head of most of your projects.

> Of course governments should be better at spending public money, but how can they be better

#1 Put someone in charge of the project.
#2 Choose someone who has successfully led a large project before.

You knew that at Slashdot.org, you'd find "news for nerds". You intentionally loaded Slashdot to get what is on Slashdot (news, discussion).
You knew that at Slashdot.org, you'd find ads. You intentionally loaded Slashdot to get what is on Slashdot (ads).

So yes, you did ask for the ads, just as much as you asked for the discussion - you intentionally requested a page that has those things.

If you want a discussion without ads, nntp or IRC is for you. You are welcome to pay Dejanews directly rather than paying Slashdot indirectly.
If you choose to come here, to a site with ads, knowing that the service provided to you is provided by ad revenue, don't bitch about receiving exactly what Slashdot offers - news and discussion financed by ads. If you don't want what Slashdot offers, don't come to Slashdot. Simple.

> almost every large project during my 30 year IT career had the same issues and reasons for failing

They spent a billion dollars to post lorem ipsum https://www.healthcare.gov/med...

If almost every large project you're involved with is similar, we've learned one thing: Don't hire Chadster!

I think you took a wrong turn somewhere and ended up on http. If you want to pay cash to have discussions, you want to be on nntp newsgroups.
Here on the web, ads pay for the sites, such as this one, so you don't have to pay cash.

> Did our jets get faster and lighter and cheaper?

Yes. Especially lighter and cheaper PER PASSENGER, which is the goal for passenger jets.

> it still takes the same amount of energy to fly across the Atlantic.

Nope, fuel efficiency and energy efficiency have improved significantly.

Bettridge's law says no.
Moore's law says yes.

In the battle of the eponymous laws, which law rules supreme? Find out in this week's epoch TFA.

At very least, start documenting new stuff via a wiki, before new commits get integrated. Better yet, documenting a new feature BEFORE coding it can increase quality and reduce development time by causing developers to think through the user experience before implementing something.

We also have our support and and customer service people copy/paste emailed answers to the documentation wiki so they aren't typing the same thing repeatedly and the information can be found without emailing support in the future. That doesn't require writing any more documentation, just copying and pasting info you're already writing.

You really do need to initially invest in building some community, if you want a community who will provide bug fixes and new features for you. It doesn't need to be a large community. Two or three or other companies / developers using the software, sharing development costs, can make a big difference. That can provide the critical mass to keep the project going and attract occasional contributors.

My primary job is working on specific open source software. The larger framework is used by many organizations. Some modules are used by three to five organizations. If three other organizations are using it and helping with development, that's a lot of work I don't have to do.

A couple of words went missing from my post, such the sentence you quoted didn't end up meaning what I intended to say

> steam from one reactor core piped to different turbines

I did NOT intend to say that steam from one reactor should be piped to multiple turbines. As you indicate, that could well create additional, unnecessary complexity.

What I intended to say is that you should be able to replace or service the turbine module without digging into the reactor cite module, because they are connected only at limited points. If you've worked on cars much, you may have spent 30 minutes replacing a water pump on an old truck, and six hours replacing a water pump on a newer car. That's what I was talking about, but missing words garbled my message. Clear lines of separation between different modules, with well-defined connections between them, should make maintenance simpler and faster.

Sorry about the dictionary shit, but you still kept on about "lots of little reactors" being a bad idea after I stated plainly that I wasn't suggesting such a thing.

> Big turbines with lots of high pressure steam get the job done far better than little ones. Of course you could have something like a lot of little pebble bed reactors

Modular
noun
something, as a house or piece of furniture, built or organized in self-contained units or sections.
http://dictionary.reference.co...

Modularity has nothing to do with big versus small. Think of a modular home for example, it's not made up of lots of little homes. Modular means steam from one reactor core piped to different turbines, for example, because the turbine attaches to the reactor core only at defined interface points, otherwise they are separate modules. Which means you can do maintenance on a turbine module without touching the reactor core.