Tag: software development

I have purposely tried to not comment about the Healthcare.gov website and it’s issues, but the landslide of wrong-headed information written on the subject has prodded me into adding my small voice on the upside that someone reading my this post will learn from this software development fiasco that we all have paid so dearly for.

Most unfortunate for those trying to learn from this is that the issue is so politically charged that to discuss it objectively is nearly impossible. The desire to place blame is too deeply ingrained in the human psyche to not point fingers – and this, for anyone capable of laying politics aside is the second lesson – the lesson that assigning blame is a human instinct that is not always productive in solving problems. Root cause analysis is essential to fixing systemic issues and may tangentially point to individual failings, but placing blame should not be primary.

And this leads to the first problem – the fact that this issue can rarely be discussed without politics. Once we have chosen sides, not only do we move from objective root cause analysis to finger pointing, but we begin to be tainted with confirmation bias in that everything we hear, read, experience is pulled through this lens. Therefore, this means that anything contrary to our preconceived political leanings are completely ignored or logically forced into their respective procrustean bed.

In my agile world the cautionary tale is about how office politics can certainly derail our best efforts to be agile. It is only in an apolitical atmosphere where true organizational change can occur. Where facts are not valued and the truth depends on the individual posting it, then the frank, brutally honest conversations (borrowing from Jim Collins’s saying in his book Good to Great)  that are necessary to effect real change are never had. In some cases the only people capable of such brutal honesty are consultants with no vested interest or employees so fed up with the politics that they no longer fear losing their job.

One other political struggle that this instance has exposed is the continual struggle between the agile and waterfall camps. Each side has cherry picked their arguments in attempt to bolster their claims and for me to weigh in on one side or the other does little to further understanding. Of course, I come down on the agile side and believe that this project’s failures can be tracked fundamentally to the fact that the project was in no discernible way agile. This argument is not even vaguely interesting to me.

The most interesting point I have heard (and agree wholeheartedly with) is that there are a number of individuals, myself included, who feel, given the proper non-political circumstances could accomplish this work for a small fraction of the cost with a much smaller team. The reason for our confidence is that most of us already have. interestingly not a single soul who has accomplished something of this magnitude has done so using anything other than agile methodologies.

While the political right claim it is big government’s fault, this argument is somewhat disingenuous because the entities that failed are precisely the private sector companies that are supposedly our economic white knights. The real problem, when all the red herrings are swept away, is the procurement process itself that only allows for the largest, bureaucratic and bloated from the private sector to win contracts. Those companies who, by the very necessity of being small, are nimble will never get these contracts so failure is to actually be expected at the same rate (or worse) identified over the years by The Chaos Report.

A long time ago, government misinterpreted Winston Royce’s “waterfall paper” and all contracts are written to favor waterfall development which has been shown to be a poor methodology in delivering complex software. Again and again we run into the core issue that the nature of software development is fundamentally misunderstood as being merely complicated so that throwing money and bodies at a problem (and these bodies can reside anywhere, with any company like interchangeable widgets) will lead to success. Because software development is complex it works best under agile which emphasizes feedback and communication. Simply the fact that so many vendors were working this project shows the complete lack of knowledge and gross incompetence of people who are paid well to supposedly understand software development. In fact, if people in charge actually understood software development then they would have known the job would have been done much better with a small band of government workers and not the disaffected armies of “private” companies.

The reason I and my agile friends know we could have done the work for much less and with infinitely better quality is because we know what software development is and we would have used smaller teams, fewer teams and co-located teams. We would have increased feedback and communication. We would have completed the most critical scope first and phased in improvements. We would have used test driven development and continuous integration and testing to ensure performance all along the way. In other words, we would have operated in a completely egalitarian, non-political manner and achieved success.

What are your thoughts?

– Larry Apke