We will start by establishing what technical debt is. In programing it is the concept of creating extra work in the future by implementing good enough for now over the best solution. If this debt is left to build and not paid down, it will lead to catastrophic failures down the line which cost far more to fix after they are deployed. This concept holds when acquiring COTS systems and tools as well as custom development. Just think how often you hear the phrase this is an interim solution while we work on a long term solution. That is the sound of debt ringing up and that debt piles up faster and higher in the government than anywhere else. The reasons why may surprise you.
- Engineering by Consensus This is hands down the biggest culprit of mounting tech debt (as well as many other frustrations). The DoD has a seemingly infinite number of concentric circles of committees involved in every project. When tasked with engineering a solution to a business problem, teams create solutions by trying to build consensus across; process owners, stakeholders, requirements owners, security, configuration management, developers, admins, and the list goes on. This process only ensures the solution will be a patch work of «good ideas», bits and pieces of various tech, and universally hated in the end.
- Acquisition Cycle It takes the government a long time to procure anything and despite multiple attempts to streamline IT acquisition the government does not even close to how quickly and efficiently the commercial sector can buy IT. See number 1 and 3 for many of the reasons why.
- Security This is known as information assurance (IA) in the DoD world. When a new platform or framework comes out, you can not just toss it over to a red team and ask them to rip apart looking for exploits and vulnerabilities. Instead you have to feed it to a convoluted and esoteric accreditation process that is more about paperwork than pen testing. The mere thought of entering this process drives many to use outdated tech that is already anointed «secure»..best solution be damned.
- The energizer bunny effect No matter how over budget, behind schedule, and poorly performing an IT project is, it never seems to go away. We have all heard phrases like, we have worked on this for 2 years, we just need better requirements, no you need to kill it. The sunk cost fallacy is rampant in the government as we constantly throw good money after bad. This is also the pit fall to the interim solution approach, once a team is formed to build and support that solution they never want to sunset it. Just one more course correction and we will be on track..keep swiping the credit card, we will deal with hat debt in the long term solution.
- Large Teams A small team of A players can run circles around a large team of B and C players. When it comes time to implement a new platform or develop a software solution there is a drive to build large complicated teams. For some reason success seems to be measured by the size of a budget versus the effectiveness of the solution. Large teams bog down development and delivery just by their sheer mass and if we are honest, those large teams usually consist mainly of B and C players hired quickly to fill seats..and the debt piles up.
While these challenges are daunting they are not insurmountable. There are pockets in the government that have over come them such as 18F. The strategy should be small, frequent and iterative deliveries of capability to production, utilize modern technology stacks, and field smaller teams of highly talented people. Embrace the security challenge for what it is and kill bad projects fast and dead. This will keep debt in check and lead to better solutions overall.