Congressional software design

The Affordable Care Act (aka Obamacare) was a piece of legislation that did far more than just try to transform the medical care and delivery sector of the economy and also brought in such things as Student Loans under its heading in a separate section of the bill.  Be that as it may the bulk of the bill dealt with a series of mandates and payments to government (taxes and penalties), and within those the requirement of health insurance companies to provide certain types of care for 'free', plus hand out individual 'subsidies' meant that there had to be a large-scale interplay between private insurers and the public purse.  To facilitate that a series of 'exchanges' were to be set up either by the State governments or, if they opted out of Obamacare, the federal government.  Thus there are a whole list of exceptions, exemptions, requirements and so forth that differ per State that the entire system must provide for, and these vary from State to State, as well.

In the previous part of my life before ill-health befell me, I worked for the federal government on the DoD civil side for an Agency that had some actual things to produce for the military.  As I was technically astute and able to deal with large scale bureaucracies (my prior university experience gave me that) I was able to shift from production work, which I enjoyed, to process improvement (or one of its synonymous variations over time) and then to new system procurement.  Thus I got to learn the government side of contracting, specifications and requirements: the whole series of hoops to go through to show that what you wanted would work, it had a set cost and it would have a series of set functions while interacting with previous work systems.  This required a whole set of understanding from the system level architecture to data file types and their metadata, library storage of digital work, shifting work from physical media to digital media and back again...plus all the network architecture for a closed system, software specifications to do particular types of work, and the equipment that would be required to proof and make press ready printing plates.  I became a one-man band of specialists and held a number of specialist hats for the agency as well as the Contracting Officer Technical Representative (COTR) hat for the project.

In that era of the late 1990's the federal government was shifting from the old procurement systems of detailed specifications and looking to utilize Commercial Off The Shelf technology (COTS) and go from a 'low bidder always wins' to 'best value can win' paradigm.  That last meant that if a contractor actually exceeded minimum specifications and offered more value for the dollar than the lowest bidder, it was possible to seek a change in funding levels with a justification for it.  I got to experience that and a firm from the old 'sole source' days trying to leverage its contacts to win with a lowball and then up the price through a series of Request For Changes (RFCs).  In contracting parlance the RFC can start to add to the cost of the contract if accepted by both sides, although either side can propose one.  The US Navy is infamous for their massive cost over-runs due to the number of RFCs on ship construction... luckily I was working on a simple IT project, but knew the RFC dance from my time in the agency.

For a contract Request For Proposal I had a tight set of specifications, workstation requirements, networking requirements, library storage system requirements, software requirements... an entire system specified for with minimal performance levels to it.  That went about 20% over on final award, but we got way more for that money in the way of reliability and software backing than the lowball bidder could ever provide.  I had spent years working with everyone from every system that would be impacted by this project not just the output groups but those on the input and library storage realm, as well as making the system Continuation Of Operations Plan compliant in case any single site were totally destroyed, so that we could at least get data to a printer with digital systems and get product.

Because I had been through the process improvement dances by attending seminars and inter-governmental meetings and just reading a lot on the subject, I was fluent on things like the Mythical Man-Month and the concept of a Death March development project.  In prior times my agency had a large scale project that suffered from the mythical man-month problem of program management, and it was a Death March as well: it was an IT system specified for in the 1980's, getting first deliverables in the mid-1990's and had a Y2K bug that would kill it.  Some items were delivered mere weeks before Y2K.

When you are specifying for how many people you need to do a project you do it in man hours or man months (or man years depending on the scale of it).  It is a generalized way of estimating how many people you need to do tasks on a project and useful for scaling personnel for a project or program.  So many people to work so many hours on X task gets you so man man hours.  Burden that by 20% and you get a realistic ballpark figure of how many actual people you need.  The burdening is to add in such things as sick time, unexpected delays, bureaucracy, etc.  Unfortunately when you have a project that has had only a few people on it and it is behind on its schedule, you start to try and throw more people at the problem.  These people are not up to speed on the project, may not know all the work that has gone on, and may or may not have the necessary skill sets to do the work.  As a program manager you need those man hours or man months of work in, however, and when you are late you do throw people at the project to burn those man hours up.  What happens, however, is that the delays get longer as the new people do take time to get familiarized with the system and when they make mistakes they have to be caught and then work re-done.  The less familiar people are with the project the more likely they are to commit mistakes which actually begins to set meeting the deadline further back.  Of course to avoid that you add more people to the project!

Ed Yourdon who wrote the Death March book (I read it in 1st edition back in the day) followed through on this mentality to see how modern program managers dealt with the problems of the mythical man-month.  Mostly they hadn't.  But a new phenomena had cropped up and it wasn't just in the Info. Tech. world, either, and that was the problem of changing customer specifications and unrealistic milestone schedules.  A death march project suffers from poor specifications for a system from the start and I read books to try and deal with just that problem as part of my job, too.  With poor specifications and milestone schedules what happens is that a project gets started with one set of specifications that then get changed in whole or in part, and prior work which was accepted now no longer advances the program to its milestones and must be abandoned.  On the IT side, however, some of that is in software code modules which may still have absolutely valid functions to help meet the schedule, so that software is kept for those functions.  New software is build around it for other functions but, when debugging must occur, problems can crop up between that older module and newer work if all the data structures haven't been well defined: old code may start to work on other parts of data passed to it due to the way it was sent to the module.  Even worse there may be dependencies in the module for information from other modules which weren't developed and that will hang up the entire development for that function to de-conflict these problems.  This eats up time.  It can invite the mythical man-month problem, and does, but also has feedback to the customer as the code structure may now need to be changed based on the newer specifications so as to avoid older software.  In theory you want to just rebuild modules from scratch, but as they have already been accepted you are stuck with them as a developer. Plus de novo work costs more, which wasn't budgeted for.

In a death march a project has a moving set of specification goal posts and the mythical man-month personnel problem plays into the problem as individuals begin to identify the project as one that actually can't reach its goals.  Yet because the customer wants results and money is available the project continues and begins a process of cycling through people within it, so that the people who started the death march project may be gone within a few months as the first set of changes come in and they see either a program manager unable to get the idea of hard set specifications or a customer unwilling to provide them.  Because money flows the project continues, and the personnel begin to flow as well so that the second group have not just the mythical man-month problem of not knowing the project fully, but also have already completed code that may not be well documented to deal with.  Without impeccable program documentation both outside and inside the computer code, new personnel face the daunting task of having to deal with changed functions and not fully understanding what has been done before them.  Of course the first set of changes brings problems and may break prior functions, thus requiring code rework... fine and dandy if it ended there, but a death march will see requirements and functions change yet again due to changes in management, possibly, or changes in customer specifications and requirements as they process through what the prior set of changes actually are.  The morale of a death march project is abysmal, and yet it happens often enough to have its own set of criteria adorning it and its own category of failure.

Obamacare came in with Congress setting some pretty broad but ill-conceived specifications for what would be a software project.  Plus there are hard legal deadlines set by Congress that met political realities but have no real parallel for a large scale software project.  In other words the federal customer shopped around a project with ill-defined goals and expectations and an unknown number of variables for which organizations and systems it would have to interact with.  Each State that didn't want to do an 'exchange' then changed the federal system as it must cover that State with all of its legal requirements, as well, which generate up new system requirements and interactions with previously designed code.  The number of States that refused was high, when it was expected to be only a couple of States, and that meant more had to be picked up by the federal system.  Yet that system now had to interact with insurance groups in different States each having their own data requirements.

The SCOTUS decision also gave States leeway on other parts of the law which also affected the 'exchanges' and because States took different routes on that, each of them that went away from the original template then brought with it changes to the system.

What Congress created was an ever changing set of functional variables within the system that would not allow the overall interaction to be a known quantity until a date perhaps as little as six months and no more than a year before the deliverable was required, by statute, to be in place.  In the modern age such laws that have so many parts to them become, effectively, IT projects.  They are designed by a committee.  They are carried out by an entirely different branch of government that must deal with its complexities, and yet the activation date is set to political realities not actual realities of software design and roll-out.  This latter problem is one that is well known: large scale systems fail more often than they succeed in all realms of business and government.

By not taking these realities into account the law is bad law, and is worse as a software design and integration project.  Any complex system requiring interactions between a set of knowns (federal agencies) has problems within the federal government.  The FBI tried twice in the 1990's to create a single sign on system for its agents to get access to all the databases the agency held.  It failed both times because the systems each had their own data standards, hardware and software, and some had human interaction requirements because they were never dreamt of being fully automated in the first place.  DoD attempted to revamp its pay system in the '90s, as well, and failed to replace multiple separate pay and leave systems with a single, unified one.  Another part of the DoD attempted a large scale system roll out for gathering map data and the RFC database became nearly as large as the project, itself.  And any ship the Navy has built for it will have a huge file behind it of changes done with a frequency that is mindboggling.  The federal government has problems within each of its departments and agencies, and working across them in an automated way is problematical due to the complexity of existing IT infrastructure.  When the States, private insurance companies and all the individuals in the US are added to this, along with federal and State laws that are at variance for each State, is it any wonder that this system is failing like we see it failing today?

Each of the three branches of the federal government has changed the specifications for the system: the legislative by the law itself, the executive in trying to prioritize functions, and the judicial by changing the interpretation of the law in a way unknown from all prior rulings.  Each of these entities can change the parameters, functions and deliverables of the system in an instant.  And yet the already accepted code is just that: accepted.  It is there be it functional, semi-functional or zombie waiting for some errant function to bring it back to life once more.  It is the far-reaching scope of the law that is a failure because no federal entity can deal with so much complexity.  The software is on a death march because of the inability of any of the three branches of the federal government to grasp that they are writing deliverable code requirements with variable function parameters.  Yet even if this was done by hand on paper it wouldn't work because of the rate of change to parameters of each part of the system: State, three branches of federal, insurance systems and advances in medical technology shifting the entire basis for treatments and medications.

That last is at peril with Obamacare as it puts a high price on new treatments and attempts to create a static system to deal with what already exists in the way of medicine.  Yet, with the entire genome now available for study, we are getting some of the first treatments to long-standing diseases which have the opportunity to alter what we see as medicine and health care.  You and I can adapt to that quite readily.  A large, hide-bound bureaucracy with hard coded imperatives and functions in its software will not.  Our freedom and liberty make it possible to change the entire idea of what health care actually is, and the idea of 'insurance' may get replaced by other systems of delivering health care that have little to do with doctors or pharmacies, and yet costs less and is more widely  distributed.  We are heading into an era of miniaturized labs on a chip that can do more complete work than an actual lab employing tens or hundreds of people per lab.  Similarly with stem cells that can come from each individual and be differentiated to organ based cells, these cells can be printed into a 3D matrix to be put into the body without fears of rejection factors.  Telemedicine and automated systems for analysis aren't just on the horizon with the former being here for nearly a decade and the latter now available interactively via web sites.  Incorporate these with labs on a chip and miniaturized sensors and you have something very close to Larry Niven's Autodoc: a machine capable of doing a complete bio-analysis of an individual to find systemic problems and even treat certain conditions, as well as do simple things like set bones, and call on specialized individuals or emergency personnel. 

Just take a look at the last century of medicine and compress the number of changes coming down to half or one-quarter of that time.  What sort of fit is a One Size Fits All Fits None Well system of paying for health care for what is coming?