U.S. HHS Secretary Kathleen Sebelius has been put in an impossible situation with the Healthcare.gov debacle. How do you fix something that was doomed from the start? A lot of the problem stems from the way governments are forced to buy goods and services. To avoid graft and deliberate underbidding, all contractors must go through a tendering process which includes detailed descriptions of the work to be performed and outcomes. This process works reasonably well when you are building a bridge or a road, but for a complex software project which involves untold variables, it sucks.

Software development is not like building something tangible. There are far more moving parts and it’s virtually impossible to document the entire development plan before you’ve started. The approach must be a patient, segmented one. You build a bit, test, and fix any bugs (which are always more than you expect) before proceeding. Then build a bit a more, test, and fix any bugs. Repeat process until you have a body of code that plays nicely together and you can isolate any new bugs quickly.

At Feedlogic, we have been in software development for over 12 years and have learned that this is the best approach.  From a financial management standpoint, this can be frustrating. A CFO wants to know exactly how much it’s going to cost and when it will be done so that it fits into a budget. But software development defies budgets and hard deadlines due to its fluid nature.

Feedlogic typically creates a master plan which outlines what language it’s going to be programmed in, what we want the software to do (functionality) and how we expect the user to interact with it. It’s a road map which is specific in the destination, but not so specific in the routing. We arrive at the specific routing through a lot of collaboration.

Our main tool is a cloud-based project management system which allows us to assign specific tasks to multiple programmers throughout the world working on one or more projects at the same time. This system allows us to track what each programmer is working on and make rapid adjustments as necessary based on changing priorities. It’s akin to making constant small adjustments to the rudder of a boat rather than large, costly changes to your bearings when you have drifted far off course.

Importantly, it’s not just software programmers that have access to the system. We have our own engineers and sales people in there to provide feedback on products as they have tested them in house and in the field. We even allow some of the employees of our distributors to participate and provide perspectives from their local situations. It’s all very democratic and it works. If you develop software in a void (i.e. with no stage testing and no real feedback from your entire internal team and your customers) you will have a train wreck.

We aren’t perfect, but we have a better track record than the government when it comes to software development and web programming. Our message to Obama and the architects of Healthcare.gov: stick to governing and let the private sector handle technology projects in its own way.