Why is there so much customized software in the federal government?

During my tenure as federal CIO in the Obama administration, one of the things that shocked me most was the enormous amount of custom code that has been (and continues to be) written over the years to support the federal government. Nearly everywhere I looked, I found that regardless of how old or how new (from mainframe all the way to modern cloud), the business applications of the federal government were invariably (and quite alarmingly) almost always based on custom software applications.

I wanted to understand why this was so, and more importantly, what could be done to change the pattern -- as it has been my experience that custom code is almost always the most expensive option (by far!) over time. I won't go into a full explanation here as to the reasons why. In short, it has to do with the cost of maintaining and supporting code that is unique, often in a language for which it becomes difficult to find programmers and support skills, and the accelerating pace of business change (which often causes major re-writes of custom code). 

In today's digital era, it has become a standard refrain that for every need, "there is an app for that!" In most cases, there are multiple "apps" that will satisfy the need. I believe the same is true for many federal government needs. Why then do we still do so much custom development? What are the cultural and institutional norms that drive this behavior?

Here is what I found out when I dug deep into the issue:

• Shiny object syndrome: There is always a strong urge to use the "latest" and "greatest" technology/methodology that is available at any point in time, but the choice to do this is often made before the entire ecosystem around the underlying core technology has matured and is available in the marketplace. Inevitably, over time, better standardized tools, commercial applications and scalable re-usable software components emerge on any new technology platform that is widely used. Using these tools, along with commercial applications and robust scalable platforms, can save an organization a lot of money (by relying on source code that the agency doesn't have to maintain and support), save time (software has already been written), and can often provide greater flexibility when business processes change (by offering a configuration change vs. code rewrite).
  
  A more modern approach is to develop a solution using short "sprints" to deliver chunks of core business capabilities on standardized platforms, using explicit business outcomes as the guiding force. Yet being "agile" or having a "product management "approach (some of the currently fashionable "shiny object syndrome" buzzwords) for implementing solutions doesn't mean agencies need to write a lot of custom code, nor does it remove the need for planning and management. All of these current techniques can be applied in a low-code or no-code approach.
• Unique requirements: How often have we heard the phrase, "…but we're different!" to justify a custom application? While real and important differences do exist for many federal functions, I've yet to find any agency that is 100 percent unique in all of its requirements or its business operations. So, why not use readily available commercial capability (e.g. commercial-off-the-shelf, or COTS, software, cloud apps, etc.) from established suppliers that have good government experience and demonstrated expertise for the common things that are not unique (the 80 percent solution), and instead focus on the mission-differentiating things where custom code can make a difference (the critical 20 percent solution)? Doing so would greatly speed up the time to market, and would improve the overall functionality of government applications.
• Overspecification: Often, custom software code comes about because agencies over-specify the capabilities that are expected in a systems procurement effort. Such detailed requirements often mean that the only way a particular requirement can be satisfied is through custom code. I can't tell you how many times I've seen specifications for new applications that, in fact, describe in detail the way the old system worked (which was custom code) with some added whistles and bells. On the other hand, some of the best new implementations I've ever seen came about because the design team and the sprint implementation teams focused on a customer-centric user experience (a customer journey) and quantifiable business outcomes. They figured out quickly what work they didn't have to do, and instead leveraged well-known commercial and open source solutions to deliver the "heavy lifting" work in the background while focusing their design efforts on where the application experience meets the customers on their platform and device of choice.

The bottom line: Speed to solution, lowest lifetime cost and the best customer experience are optimally delivered by leveraging well-known COTS and open source solutions, and by restricting custom software development to the rarest of cases where there is no viable alternative. CIOs should carefully consider this when looking at how to modernize their agency capabilities.