If the consultants behind HealthCare.gov had read this book...

[Darren Dirt]

...then maybe Jon Stewart and others would not have had as much comedic material a few months ago.


http://www.hyperink.com/Effective-Programming-More-Than-Writing-Code-b1559

Effective Programming: More Than Writing Code by Jeff Atwood (the "Coding Horror" blog guy!)

What's in the book?

Your one-stop shop for all things programming.

-The Art of Getting @%&# Done
-The Principles of Good Programming
-Hiring Programmers the Right Way
-Getting Your Team To Work Together
-Your Batcave: Effective Workspaces for Programmers
-Designing With the User in Mind
-Security Basics: Protecting Your Users' Data
-Testing Your Code, So It Doesn't Suck More Than It Has To
-Building, Managing and Benefiting From a Community
-Marketing Weasels and How Not to Be One
-Keeping Your Priorities Straight

[Mr. Analog]

The problem isn't the code, it's the corporate culture endemic to most of the large consulting firms.

It works against their best interest to deliver on time, under budget or even something functional. There is no endgame plan, just install the money treadmill and keep it lurching along for as long as possible. Layers upon layers of machinery ensure the pressure is directed at the bottom where poor concepts and bad ideas are already diluted and polluted and then finally realized by tired, overworked minions...

This is bad enough in any industry but in US Healthcare, which is already a decades old mess and smothered by politics, how could it ever succeed?

[Tom]

They are also fighting with many different insurance company backend integrations. None of which are similar. They are trying to merge many disparate databases into one coherent system. I can't imagine that would ever go all that well.

[Darren Dirt]

They are also fighting with many different insurance company backend integrations. None of which are similar. They are trying to merge many disparate databases into one coherent system. I can't imagine that would ever go all that well.

True, but AFAIK *most* of the issues in the initial rollout of healthcare.gov had nothing to do with integration of complex backend data, they were almost entirely problems logging on or other basic navigational functionality that you would expect to work even in some local yokel mom-and-pop shop website, let alone something huge like this. Hence the surprise/mockery when it imploded at its release.

[Mr. Analog]

Again, this is where the upside down pyramid structure large consulting places have that cause problems like this because no one person sees the big picture, you have a bunch of people who all see different big pictures.

I've been at the "fix it" butt-end of large projects like this in the past, the worst of which at one point had FIVE architects. The "too many chefs in the kitchen" analogy couldn't be more apt in projects like these, multiple architects, multiple business analysts... there was a virtual army of developers behind something that a team of two (maybe three) could have done competently. Competing visions of how things should work whether they are right or wrong collide and create a mess, the more complex the system is coupled with more visions of how it should work ends in design anarchy.

Don't get me wrong, I've seen projects done badly by smaller, tighter teams, but at least the problems were consistent and easy to root out or refactor, when you have a symphony of errors all spackled together ... well, "wholesale re-write" starts to enter peoples' brains.

The key thing I've come to learn is that the more complex a system is the more important it is to have a single vision of how it should work, and that everyone working on that project needs to have a clear understanding of that vision. Unfortunately this isn't how companies like CGI do things, in fact I haven't seen many large projects in the last decade do this well.

It's sad in a way, consultants have really amazing tools to build truly outstanding software these days but they are hamstrung by a lack of competent planning, management and coordination.

[Tom]

Yeah... I totally agree with you Mr. A.

They are also fighting with many different insurance company backend integrations. None of which are similar. They are trying to merge many disparate databases into one coherent system. I can't imagine that would ever go all that well.

True, but AFAIK *most* of the issues in the initial rollout of healthcare.gov had nothing to do with integration of complex backend data, they were almost entirely problems logging on or other basic navigational functionality that you would expect to work even in some local yokel mom-and-pop shop website, let alone something huge like this. Hence the surprise/mockery when it imploded at its release.

I think some of it is related. It's like some of the site was attached directly to the backends and whatnot. like imagine a user admin page that fetches the entire list of users to display every load. And eventually this site has millions of users.... That kind of stupidity. But instead of a mysql or oracle database, its some third party legacy custom rolled mainframe software done in fortran, and you have to communicate to it over some dialup or ftp link (yes, I said ftp).