I clicked on this curious as to whether I had worked on any of these. And yep. 3 of them -- 3 out of the top 4 worst in the Americas. The DoD has some successes though.
well, and this is just a personal suggestion, maybe you should stop sabotaging the companies you work for? Or hire yourself out for your ability to sabotage competitors?
But there is a profession dedicated to preventing these kinds of failures: Systems Administrators.
Proper infrastructure engineers (or "site reliability engineers" as google now calls them) are key for helping architect highly available systems like this; Yet the trend seems to be forcing software engineers follow tutorials from google on setting up key pieces of infrastructure nowadays.
Edit: it's ettiquite to say why you're going to downvote someone, if what I said wasn't relevant please let me know.
Haven't you heard? With Amazon and Heroku and Google, SREs are obsolete! Your developers can manage their own infrastructure. /s
Our own company learned the truth about requiring an operations team the easy way - they hired some and their reliability went up. Outages started being handled before it impacted customers.
It's been fun watching the volume of "Oh Shit" emails dropping precipitously.
I did not downvote you, but I disagree with your premise. Systems administration is only part of the problem, and only in some cases. A non-inclusive list of other causes include failing to understand the intended purpose of a system and the environment it is to operate in, and losing control of the design.
I would agree with what you said, but I would argue that the points you raised still fall into the realm of systems administration.
Identifying scope and purpose, and it's impact and documenting the design are just some of the things an platform operations team is -supposed- to take care of.
If you expand the definition of systems administration to include everything, it doesn't get you any closer to a solution.
The largest problems of development have nothing to do with administering anything (edit: for example, bad design often results from bad design decisions that are neither prevented nor fixed by seeing that the required documents have been written.) The idea that Winslow Taylor's principles can solve these problems is a fallacy - a commonly held one, but a fallacy nonetheless.
You're definitely falling prey to a short-sighted and overly cynical point of view.
"Never attribute to malice that which is adequately explained by stupidity" and never use the stupidity explination to overlook the fundamental complexity of a software project.
What you have here is a lot of non IT professionals, without siginificant IT experience, attempting the most complex IT projects ever considered, without the pressures of ship-or-sink, investors looking for progress reports, or even the benefit of working with their own employees (usually multiple groups of contractors work on these big projects). Also, they're not trying to build a MVP and iterate. They're trying to build Rome in a few years.
When you think about the hurdles these projects face, of course they fail. The government trying to do a huge software project is like a kid seeing a master level parkour video on Youtube and not understanding the lifetime of practice that went into the sport. They're just going to jump off the roof and break their ankle.
Of course in a sample size this large corruption is an issue. However, with zero corruption and only the best intentions, we'd see substantially the same results.
What you have here is a lot of non IT professionals, without siginificant IT experience, attempting the most complex IT projects ever considered
It seems like this boils down to "People should not hold strong opinions on things they don't understand."
I've seen so much time and money wasted on nonsense endeavors just because clueless people insisted things had to be done a certain way without consulting they people they pay to make sure their stuff runs right.
Only those that haven't worked in DoD / federal systems could ever think that laziness / stupidity is not a major root cause of so many DoD IT project failures. There's a lot of successes when using smaller, elite contractors but complexity intertwines with stupidity as larger contractors must be brought in to handle the bureaucracy and their hiring standards are basically abysmal. Why? They were very much incentivized to hire butts in seats on contracts historically, not to be effective at executing them to technical satisfaction.
Someone needs to call out DoD for what it really is in the US - federal Public Works program that's approved by neoconservatives.
Yeah, it's definitely a failure of project management. I'd like to point out that GOV.UK have greatly improved in this regard recently. Mostly by the old fashioned approach of having senior permanent staff who know what they're doing.
Contracting out at the top level (ie, including all the project management) is just a way to guarantee a money sink, because either you have a huge inflexible spec built into the contract or you have an area of vagueness where responsibility can be dodged.
Project management is pretty f* hard. People are not computers, time won't run backwards and money don't grow on trees. Organizations won't wait cooperatively for you (as CEO) to implement your project and your vision. Politics kick in and good luck getting out.
