When I first came to Silicon Valley in 1979, I hooked up with a company called Personal Software. I was under contract to create a product, called VisiText, and was paid an advance and promised royalties. It was a small company when I started, but before I delivered the product, it had grown several times its initial size, had raised venture capital, had new management and a new name, VisiCorp.

The new engineering guys came from the US government, where they did things differently from the seat-of-the-pants method we were using to create our Apple II and IBM PC software. They believed their methods would yield a better result.

They'd fully specify the software, the user interface, its internal workings, file formats, even write the user documentation, before a single line of code was written. Then they'd hand the parts off to development teams who would independently of each other create the components. Another team would do the integration. The end result would show up in the users' hands without anyone from the company using it. (This is the way I understood it, it was a long time ago, and they were foreign ideas, so take this with a grain of salt.)

They got to try their way of doing things with a couple of big products, VisiWord (the replacement for my product, which never shipped) and VisiOn. Both products were disasters. VisiOn was an early front-runner in the race for personal computer GUIs, a race that was eventually won by Microsoft Windows. It was unusable. The company, which had bet its existence on these products, died.

The same team went on to another tech company, Ashton-Tate, where they did the same thing, and killed that company too with a disastrous release of a product called dBASE IV, which was then the leading database software for personal computers.

I suspect their approach works for projects like flying astronauts to the moon, or shooting ICBMs at the Soviet Union, where there's no chance to try things out before you go "live." They have to work the first time. And in some cases security is a huge issue, and you don't want too many people to understand the whole project.

The point of this story is this. Where people in commercial software iterate and refine based on actual use of the product, something we did then instinctively, which has now been formalized in various disciplines, the government method doesn't work well. A startup could have done a better job at healthcare.gov. I don't care how sophisticated the backend is, the problems the site has look like the ones the VisiCorp products had. Not enough human involvement in the process. No communication. Too much reliance on initial vision. No refinement, no pivots. It's pretty clear that this website wasn't loved. I know that sounds dorky, but the products you love were loved by the people who created them. They were created by smelly imperfect humans, the same kind of people who use them.

Perhaps the only way this is going to get fixed is by developing a parallel system alongside the broken one, to fill in for it as soon as possible. A Google or Yahoo or a startup formed with experienced developers could do an excellent job here, imho. And here speed is of the essence, if we want to save the health care system of the United States, a very worthwhile goal, imho.