I follow news about Affordable Care Act in general because it is affecting me now as a long-term individual-market subscriber.  

Besides a personal stake in the overall program, I am curious about the ongoing drama of the failures and delays of implementation of the software and IT required to make the legislation work.

In the popular news stories, a lot of the blame goes to poor program management and poor definition of requirements while software was being designed, implemented and tested.   A lot of the blame goes the extreme complexity of the undertaking.  There is blame on competence or even fraud of the contractors.  I see where fingers are pointed but rarely do I ever read of the counter-arguments.

Most of the software projects are completely new systems that are built from the ground up using all the latest software practices and technologies.  I agree they had the huge challenge of integrating with a huge number of legacy systems over many different agencies and developed with different technologies and practices.  

Integration with a single instance of a legacy system, no matter how old or how poorly understood may require a lot of effort but it is not complex.   Many vendors develop highly reliable and successful software for medicine that involves some integration with the human body, a really complex legacy system that exists without any documentation or owner manual from the developer.  It is reasonable to expect that we can build software to integrate with legacy systems within a budget of time and money.

The seemingly reasonable budgets of time and money appears to have been overwhelmed by the very large number (or even uncertain number) of legacy systems that needed integration.

The overall project of implementing all the necessary pieces for the affordable care act was ambitious in scope.  We live in a time when we need to tackle ambitious projects.  Software science has evolved over 5 decades to become very mature.  It seemed reasonable to expect that the available tools, practices, and technologies would be up to the task of tackling exactly this type of scope within the generous budgets provided (with clock starting at the enactment of the legislation).

I wonder if the state-of-the-art of software science has let us down.  Maybe the software science needs more time to mature.  Maybe some recent advances in the software practice are counter productive: that older practices may have been more productive.

My only access to anything related to these software systems is what I read in the popular general-audience news stories.  I use my imagination when people talk about monthly mock-ups or using the latest of software trends.

Earlier software practice would first document requirements of the project and then decompose the requirements to units that would be available for software designers and developers.   Often this documentation was sufficient to allow an individual to develop independently or with voluntary collaboration.   In the extreme, this was described as a waterfall model and has been discouraged since at least the 1980s.  Among its many problems are the difficulty of agreeing on the requirements and the inconsistent quality of the developed modules.   Despite the problems, many legacy systems were built with some variation of this model.

Newer practice discourages both independent individual development and extensive up-front requirements definition.  Instead of working toward long term goals, they work on very short term goals to present a working project that can then be evaluated to determine requirements for future iterations to approach the long term objective.  The theory is the team will work more effectively than individuals and the large-scale requirements will emerge gradually through iterations.

If these practices were employed in the software projects for the affordable care act, it doesn’t look like they did very well.  It is impossible to know if the discarded older model would have worked well.  The older model did prove itself by building many of the currently working legacy systems, many of which are very complicated especially when considering the time when they were built.  But may today’s challenges are qualitatively different.

In my on-going theme of exploring the meaning of intelligence, I focus in on the assumption of modern software practice that a team can be intelligent.  Estimations of a team’s intelligence range from greater than the sum of the individuals to no less than the intelligence of the weakest individual.  

We optimistically assume that only very rarely would the collective intelligence of the team be less than that of a single individual on the team.  Groups of individuals can be a team, but they can also be a mob.  Tasks may be better trusted to well-informed individuals than to poorly informed mobs.

I don’t know what is ailing the software development progress for the affordable care act.  I do recognize that it appears to be progressing and getting closer to where it needs to be.  Perhaps we just under-estimated how much time would be required for even vastly more productive software practice.  But I can imagine that my personal stress would be pretty high if I were on any of those teams today.