3 Things Developers Can Learn From Healthcare.gov

I'm sure there are more than a few Project Managers out there who have watched events unfold over the past month with a lot of head-scratching, I know I am one of them.  The troubled roll out of Healthcare.gov has flamed passions on both sides of the aisle, but when you look beyond the politics of the situation, I think there are actually some valuable lessons for developers.  The things I've taken away from the roll out revolve around its 3 most obvious shortcomings as I see them.

Timing is everything: 

Anyone who has ever been part of a software development project knows that initial estimates for a completion date are rarely accurate.  Having a hard deadline usually gives executives the warm  fuzzies because they feel like they're better able to plan, but the reality is you have to be more flexible.  The reason for this is that in the early stages of a project, you don't know yet what you don't know and you have to allow your team to be able to inspect and adapt as their needs require.  I think everyone can agree it's wiser for a shipyard to push back a deadline and take the criticism than it is to launch a ship that won't float.  As the saying goes, you never get a second chance at a first impression.


Think like a user:

When it comes to things like uptime or secure transmission of sensitive data, you can't discount the experience of the user.  If interactions are negative, you'll always have trouble getting users on board.  So, it's incredibly important to incorporate user experience as much as possible when dealing with the logistical concerns of development.  A lot of developers tend to have a narrower view and assume that user experience just has to do with the interface design.  It has become clear that it has a lot more to do with the level of expectation people have for software these days.  If you force yourself to think like a user, you'll see and experience the things that they do when they use your product.  If a user doesn't particularly like a feature or an interaction, then you shouldn't either, and you should focus your efforts fixing it.  That can be a difficult mental leap, but sometimes you just have to do it in order to deliver the best possible experience.  As an alternative, bring in some outside eyes and Early Adopters to have a look at things.  You'll often get the most honest opinions from people that don't know how your application is supposed to work.  If you include these points of view throughout development, it keeps you from getting side tracked.  


Testing, Testing, Testing!

As a Project Manager, supporting an open dialogue between testers and developers gives you a chance to stay ahead of events in many cases.  Conventional wisdom suggests that throwing more developers into a project means it will get done faster, and with fewer bugs but Brook's Law shows us that's actually not true.  There is a point of diminishing returns when you increase the number of people making code decisions because of of the ramp up period and the extra layers of communication.  It's wiser, instead, to bring on additional testers since they will help your developers to fix problems right away, before they have a chance to fester.  


As some US agencies have realized recently, it's very difficult to accomplish realistic development goals when a project has political components attached to it.  The problems are compounded when a product or service needs to potentially service tens of millions of customers on day one.  Fortunately, if you focus your resources and efforts around timing, user experience, and test driven development, you can avoid the kinds of logistical disasters we've seen recently.  

 

Shiraz Hemani
CEO - Spire Business Services

 

Image Credit: 1

Shiraz Hemani