Convert your FHIR JSON -> XML and back here. The CDA Book is sometimes listed for Kindle here and it is also SHIPPING from Amazon! See here for Errata.

Monday, July 30, 2012

Why is Software Hard?

A long time ago, I was in a meeting with a colleague and several senior managers for a project we were working on.  He and I managed different development teams and were being lambasted by a manager (not our own) with respect to a recent bug.  The manager had previously made some comments about his extensive history in software (not realizing that both my colleague and I had more experience in the industry that he had).  He went on to compare software development to car manufacturing.  Why can Toyota build such great cars and we still have bugs in our software?

My colleague made a very simple statement:  "More moving parts."

According to this website, a typical car has around 30,000 parts when you take it down to the level of a single component (e.g., a screw).

Yet we measure software in thousands of lines of code, and a typical enterprise application has millions, tens of millions, or even hundreds of millions of lines of code (and some of that can be 10, 20 or even 30 years old).  And those parts can touch on each other in so many different ways not limited to the laws of physical space.

Some of the best studies (e.g., COCOMO), reports and books (e.g., Mythical Man Month) from decades ago estimate software productivity as being around 10 lines of code per programmer-day, or around 2.5 thousand lines of code a year.  I had an engineer who worked for me at that point in time who produced (measurably), 100,000 lines of code a year (and that was also bug-free).   He was five times more effective than the next-best engineer I had working for me, and my team was arguably 5x better than Brooks 10 lines per programmer-day estimate.  But even so, to consider what that team could do with respect to maintaining tens of millions of lines of code, it's just daunting.

In healthcare, we add to that complexity.  SNOMED CT codes for several hundred thousand concepts.  ICD-9-CM has over 14,000 codes and nearly 4,000 procedures.  ICD-10-CM has more than 68,000 codes, and ICD-10-PCS has 76,000 codes.  LOINC has more than 50,000 terms. RxNORM has nearly 500,000 codes.

Back to the car analogy.  Imagine how difficult it would be to build anything, if the thread count of every screw was different.  At some point, it is amazing that software developers manage to build anything at all.


  1. When you want a new car you do not bring your old car and ask for a version upgrade. You get ~30,000 brand-new parts that were designed to work together, learning from prior years' experiences. Software is all about re-use and incremental changes, not new model-years. I wonder how EHRs, PHRs, and EMRs would be if we got total replacements every few model-years.

  2. Hi Keith, a while ago I was interested to know if there's anything special with healthcare or is it just us making all that up (possibly in order to create more HI jobs!). I've found these worthwhile:

    1) Rector AL. Clinical terminology: why is it so hard? Methods Inf Med 1999;38(4-5):239–52.
    2) Beale T. The Health Record: why is it so hard? In: Haux R, Kulikowski C, eds. IMIA Yearbook of Medical Informatics 2005: Ubiquitous Health Care Systems. Stuttgart: Schattauer 2005:301–4.
    3) Pronovost PJ, Goeschel CA, Olsen KL, et al. Reducing Health Care Hazards: Lessons from the Commercial Aviation Safety Team. Health Affairs 2009;28(3):479–489.

  3. Software development is far better than anything else but at the same time hard too. We can see lots of softwares getting developed for different purpose each day and the credit to these goes to all developers who really works hard to make out something fruitful that can ease your work.

  4. I cannot agree with you more. Add to that the fact that Toyota produces the same car over and over again in a production line. In software, we create it once and then create something different. We are not asked to produce a sorting routine over and over again. It is more like creating a spaceship for a moonshot one month and then submarine the next and then combine the two together the next. In the end, we are an engineering operation that gets little credit for the billions of production transactions that occur afterwards. The engineers at Toyota get the credit even though a lot of the quality comes from production.