> In my case, even the most expensive plan for our family in the State of Maine, where we live, is half the cost of what we are currently paying, exclusive of any subsidies.<p>The elephant in the room is that this is not the typical case - <a href="http://www.forbes.com/sites/theapothecary/2013/09/25/double-down-obamacare-will-increase-avg-individual-market-insurance-premiums-by-99-for-men-62-for-women/" rel="nofollow">http://www.forbes.com/sites/theapothecary/2013/09/25/double-...</a>
If there is anything that can come of good of my taxes (a ridiculous amount of it in fact) is that we should educate people on the difficulties of software development. This would make a fantastic case study on what I presume are the issues at hand:<p>- Maintaining complex code (+1mil LOC)<p>- Classic "waterfall" approaches to software development (and the inherent problem with trying to blueprint requirements up front)<p>- The mythical man month[1]<p>- Change management<p>Funny thing is...these are all human problems.<p>[1] - <a href="http://en.wikipedia.org/wiki/The_Mythical_Man-Month" rel="nofollow">http://en.wikipedia.org/wiki/The_Mythical_Man-Month</a>
Thoughtback [<a href="https://thoughtback.com/" rel="nofollow">https://thoughtback.com/</a>] sent me a pertinent reminder this morning. No affiliation, just a great tool.<p><pre><code> Organizational metrics, which are not related to the code, can predict software
failure-proneness with a precision and recall of 85 percent. This is a significantly
higher precision than traditional metrics such as churn, complexity, or coverage
that have been used until now to predict failure-proneness. [1]
</code></pre>
[1] The Influence of Organizational Structure On Software Quality: An Empirical Case Study<p><a href="http://research.microsoft.com/apps/pubs/default.aspx?id=70535" rel="nofollow">http://research.microsoft.com/apps/pubs/default.aspx?id=7053...</a><p>--<p>edit: formatting
I bet you half the problem is the software being specified in a synchronous and not asynchronous manner.<p>If a flow chart is expressed synchronously, it immediately bottlenecks around the slow backend systems. e.g. check the applicant has 4 kids, and if that checks out, present them with these options.<p>I attribute some of these problems to inadequate advances in today's mainstream programming languages.<p>For instance, if futures/promises were common parlance in programming, some of these bottlenecks would have been identified earlier.<p>I once read an interesting essay on what future programming languages could work on. One of the interesting ideas is a language that allows programmers to implement undo/redo easily. Recently there was a blog post about fuzzy computing, where a function is able to return approximate values when it is busy. The Knight Capital incident teaches us that if we architected our monitoring systems the same was as intrusion systems are done, we could have stopped activity when suspicious incidents occur outside the normal operating range. There was another incident where a Japanese trader accidentally keyed in the wrong number and promptly lost his employers a lot of money. Languages that incorporate ideas like validation and expected values as first class constructs might be able to help here. The Adriane reminded us how badly humans do when reasoning about systems where multiple agents perform the same task.
I can't wait to see what the report of it didn't work actually says. It's quite possible that one of the services that the website hit couldn't handle the traffic which in turn caused a bottleneck in other systems.
Wow, this particular excerpt from the article is stretching things a bit too thin:<p>"Clearly there are problems with the government’s IT procurement processes, but if the same level of dysfunction had been present in the software behind Obama’s political campaign (as it was, apparently, behind Romney’s) the President would have never been reelected."<p>Really? I doubt the campaign websites were the deciding factor.<p>Anyway, a lot of speculation in this article...not very insightful or informative.
Why government software projects go wrong [<a href="http://www.mrobinson.ca/2012/09/why-government-software-projects-going.html" rel="nofollow">http://www.mrobinson.ca/2012/09/why-government-software-proj...</a>]<p>ibid - Part 2
[<a href="http://www.mrobinson.ca/2013/08/government-projects-going-wrong-part-2.html" rel="nofollow">http://www.mrobinson.ca/2013/08/government-projects-going-wr...</a>]
I didn't see anything that meant it was doomed from the requirements stage.<p>This was more of an Obama love fest and defense of ObamaCare than a technical article describing who the backend was doomed.<p>For what this cost to build it could have been much better, much simpler, and handled the scale gracefully.<p>Yes privacy concerns keep it off the elastic cloud. (not a point mentioned in the article)<p>Yes authenticated users limit caching and make scaling harder. (not really mentioned)<p>But when you are talking about everyone in the US, you only have so many combinations. Income in something like 32 ranges, number of kids 1 through 12 (greater than 12 they are all free) a bunch of ages.<p>We just saw a post that only 15 searches are new to google each day, so the number of combinations is much less than search which does lots of caching.<p>The requirements were messed up, the implementation was. Clearly not built by people who had ever done "Facebook scale" stuff.