While you can't be positive, this appears to be an instance of what has become one of the standard approaches to dealing with troubled SW development. That is: the thing doesn't work, and things are looking bleak... what do you do? Simple, if you don't understand how SW is stitched together, and designed - you just throw cash at the problem. The mentality is: if it takes one woman 9 months to create a baby, and you need a baby in one month, what do you do? You just hire 8 more women, and viola, you put 'em all to work, and out pops the baby in one month... or so the inept thinking goes. Alas, like all custom SW development, that just isn't how things work – as John noted, the bearer of bad news to those who think they can “command” the existence of software, the messenger, always gets executed (fired).
The Healtcare.gov type of SW is, in the main, custom - that is, it has to be designed; and the chance of it working increases when designed by someone who knows, and understands the boundary conditions necessary for system operation, eg. how many users will be supported at any given time; how much storage is require, and where it's to be logically, and physically located; how the storage access is to be distributed - so that users get a reasonable response time -; how is the compute load to be distributed, physically, and logically; how will the system deal with heavily loaded conditions - simply grind to a halt, or blow users off by telling them to come back later -; can what is being designed be scaled easily (made larger easily, with the expectation that the larger version will also work) - the hardware and SW necessary to handle 1500 users is not the hardware and SW necessary to handle 20k simultaneous users; how is the load to be distributed to the available hardware/SW as user demand increases; is transaction logging/archiving necessary - more storage, more time. All of these, and other requirements are unique to each system being developed. While all interactive systems have some commonality, each system in development is custom and unique, understanding, of course, that all systems use off-the-shelf Databases, and other "canned" SW.
The end result of the unique nature of individual "troubled" systems is that you can have "super" people - the A-team, if you will - and when put on a distressed project, the fact is that they are not like painters, they don't just grab a brush, and start painting. The fact is, on the front end they can't do much as they know almost nothing about the system's design. With SW development new people are a burden, and for a period of time contribute little as there is a finite period of time required for them to "come-up-to-speed" and be of any meaningful use on the troubled system's design and implementation. More people, and more cash just won't make it instantly any better – no matter what the little Red in the WH might want, or say - it's the reason that life experiences are so vital. The "education" task, when adding people to a troubled project, is in itself a problem. The difficulty is that much of detailed documentation that may exist are often almost useless as they were usually done on the front end when it was perceived that there was lots of time – and now that things have been frantic for a while most things have been altered/changed. How things are to be designed, and are supposed to work lives, in the main, in the heads of those working on the distressed project, as, because everything is behind schedule, there is no time to document or update anything except databases, file structures and data definitions - the stuff actually used by all the programs. That means that the worker-bees have to be taken away from the already distressed task to answer the questions of the newly arrived A-team who, while bright and experienced, don't know squat regarding how this particular distressed project has been designed and is supposed to function. Essentially, at least on the front end, the A-team not only doesn't help all that much, but the necessity to "educate" them detracts from the labor being directed to the distressed task. Ruffled feathers – personalities - may in fact cause some of the informed to use the opportunity exit the “pressure cooker” and up and quit, taking with them a treasure trove of undocumented information. – don't think I was ever on a project that had realistic time/delivery goals, you just worked through the issues until testing said it was functional, eg. fast enough and reliable enough for extensive testing.
Judging from the contract awards -
http://about.bgov.com/2013-10-24/late-i ... -law-woes/ - this project didn't appear to actually get started in earnest until roughly March of 2013. (Need to be aware that this article's author was at one time a speechwriter for Geitner, and a medical adviser to HHS – not sure what that means, but it makes me question everything - could be a whistle blower, could be providing cover.) Can't be sure, but it looks as though, from the contracts, that somebody figured that they were going to throw together a system in a year or so in 2010, and 2011, then in late 2012, and when reality set in in March of 2013 it led to the standard uninitiated response to a troubled project - throw money at the problem. As John explained in the article there are problems that money just can't instantaneously fix. Given time - something Obama doesn't have -, a functional design - something that can't be reasonably assessed given the volatile political nature of the issue, and the propensity of those in this administration to simply lie, distort, and deceive - and capable people there is the prospect that this problem can be fixed - eventually. Additionally, should the design be flawed there are capable people who can re-design, and re-write the project so that it will, eventually, function – but they probably are not the buddies of Michelle Obama. What can't be fixed is that this is an illegal, un-Constitutional power grab that seeks to insert itself into the lives of 316 million Americans, less Congress, who exempted themselves, and this Administration; and while that is bad, the underlying basis of that grab - socialism - is based upon the precept that you think that you can seal what isn't yours and expect people to replace it by personal initiative so that you may steal it again over, and over again - a process that has kept sub-Saharan Africa in the third world; caused the economic crash of all of Eastern Europe; and the failure of the old Soviet Union; in addition to not working in the Plymouth Bay Colony in colonial America.
In an attempt to illustrate how bad developmental difficulties can be: I worked for a company who developed a truly revolutionary piece of computing HW - very, very, nice. They had to develop an operating system - it was an extraordinary piece of work - a master work. But the OS had 100s of thousands of lines code - not 500 million, a number that without explanation, is without credibility, as it is beyond the scope of the human capacity to fathom, much less to manage. So, as the company was in the computer biz, they told their sales force to go sell some of these new machines – as, at last the long and often delayed project was finished and ready for sale, and customer delivery. And that's what the sales force did. Then customer deliveries started to happen. With customer deliveries, the enormity of the SW mess became apparent - this project was the largest single development project, in terms of money, and people that this computer company had ever undertaken. So, visualize if you will, this company has 10 - 15 of these machines installed in customer facilities, and the customers have paid from 300k - 500k per machine - so these were relatively high profile installations, and to say that the customers were less than happy would be a gross understatement, as these premier machines couldn't be made to stay up for more than a few minutes at a time.
What to do?
The company pres. came out and visited - personally - each customer. He made no attempt to white wash the problem. He asked each customer for a purchase order for an older system that was known to be capable, and reliable. The customer didn't have to pay for the older system for 18 months. At the end of the 18 month period if the new system - the mess - didn't do everything that it was originally billed to do, the customer could keep, and pay for, the older system and return the "new" system at no cost – in the interim the customers were encouraged to use the new machines and provide feedback as fixes proceeded. Many, not all, of the customers agreed and kept the new machines... it was an 18 month period of intense development, and testing, but it wasn't long enough. Five years after the fact that new machine was the center-piece of that companies' product offering - a shining star, and it took 3-5 years to completely "fix" the OS containing hundreds of thousands of lines of code. And this was done by the very best accomplished SW development people – creative innovative people who routinely worked 10, 12, 14 hour days - those on the A-team don't work 8 hour days, and they don't play golf, and they don't play basketball, and they don't party with Beyonce, or Jay-Z. The message is that large system development, when rushed, always turns out badly - Presidents may lie, Cabinet members may lie, Project Managers may lie, Analysts may lie, Programmers may lie, but software never lies: SW is what it is, if well designed, and tested it mostly works, if not well designed, or tested it doesn't work; and no amount of lying will change that.