27 May
2016
27 May
'16
12:27 p.m.
On 2016-05-27 12:16 PM, Alan Perry wrote:
It seems that Texas could take some lessons in "reducing costs":
https://www.texastribune.org/2015/02/01/cost-overruns-and-bungles-state-con…
But, "Since fiscal 2008, Texas has paid Accenture more than $6.3 billion
for a range of projects, including Medicaid payment services, according
to the state comptroller?s office."
http://www.mystatesman.com/news/news/state-regional-govt-politics/a-trouble…
It's almost like there's something else going on, when billing gets into
the 8-11 figure range! Oh, wait, what if we google "accenture kickbacks"???
--Toby
On May 27, 2016, at 08:41, Swift Griggs
<swiftgriggs at gmail.com> wrote:
I worked on F35 software 13 years ago. I am not an aviation systems guy, but I was an
expert in a technology being used, which is why I was on the project.
I am both shocked and not surprised that development of the plane has taken so long. The
software guys there experienced with military contract work said that the project was
typical at that point. I left being amazed that anything that comes through the process
ever flies.
The biggest problem that I saw then was technical choices made without considering the
implications of the choices, followed by kludge after kludge to get around yet something
else they hadn't considered. I see that all of the time on other projects, but the
prime contractor and sub-contractor (and sub-sub-contractor) arrangement that stuff like
the F-35 is designed and built make it hard to change a poor technical choice made before
the work is subcontracted out.
BTW, the primary poor technical choice that I saw was made to reduce costs, not for
lock-in or to give some preferred company business.
On Thu, 26 May 2016, Toby Thain wrote:
We're pretty much already there.
Agreed. You should hear one of my buddies talk about the air traffic
control software he wrote which was replaced with some horror.
Audits of the F35 software found:
* single points of failure (grounding global fleet)
* security issues
* that software is the single biggest risk to the project
One of the principles of Unix: KISS, has been nearly completely lost.
Nobody calls a meeting anymore to say "What can we get rid of? How can we
simplify this? What is the *right* thing to do here?" It's more like "how
big of a kickback will I get if I put in this nasty thing this vendor
wants to sell?" or "Does the new system have buzz?" alan