Last week I was discussing the idea of software rewrites with a good friend. It was a relevant topic; different teams that we work with are being asked to, or are in the process of, rewriting various pieces of software. But our conversation wasn’t about the mechanics of rewriting applications; it was about the decision to do so, and whether that decision was the appropriate one.

Rewrites are costly. The costs are almost always larger than anticipated—both in time and effort—and failure to anticipate them correctly provides competing businesses with an opportunity. While the organization focuses on the rewrite, and tries to build to parity with their “legacy” solution, new features get pushed lower on the priority list. This creates a gap with evolving customer expectations; the longer the rewrite takes, the larger this gap tends to become. If competing businesses can step into it, they can seize market share while the rewriting organization is busy working towards “feature parity.” Both of us had seen this happen. It seems to be a common theme with major software rewrites.

My friend and I had learned from this experience. Since both of us had been party to rewrites that took longer than anticipated and had important business consequences, we were wary of them and argued for approaches that accounted for these business risks. Our experiences made us wonder if organizations—not just ours, but organizations in general—could effectively learn from these experiences.

The question is an important one. The tenure of engineering managers and their immediate superiors is relatively brief, at least compared to the cycle of software rewrites. Software systems can last for a generation, twenty years or more. A software engineer might see one or two major rewrites during a career. Would that give enough experiential knowledge to avoid a poor decision? We thought it unlikely, especially if managers and decision-makers were moving on to new responsibilities about once every five years.

This wasn’t an inspiring conclusion. We couldn’t help but wonder if software organizations might have real difficulties learning important lessons because of these dynamics. If average leadership tenure is less than ten years and the feedback cycle from a rewrite is double that, how can an organization be expected to learn from one?

In a world where Agile approaches and fast feedback loops have become so common, there are still aspects to our systems that have long cycles, and these can inhibit effective learning.

Watching President Obama’s speech to the U.N. the other day, as he laid out the case for a campaign against ISIL, I wondered if the same might not be true for the U.S. government. It is dangerous to draw specific parallels between American involvement in Southeast Asia—or more specifically Vietnam—and the recent entanglements in the Middle East, but for students of history, it is almost impossible not to. Similar themes reemerge, such as overconfidence in military force, an emphasis on winning tactical victories rather than defining strategic goals, and relative ignorance of the importance of historic and cultural contexts. Presidents, just like software managers, can have difficulty with long feedback loops because of their limited tenure.

In the late nineteenth and early twentieth century, with limited experience in fighting naval wars, the U.S. Navy attempted to solve this problem through the study of history. This was a core aspect of the approach of Alfred Thayer Mahan and the work of his colleagues at the Naval War College. Historical study augmented experiential knowledge and was used to illustrate broad themes. These broad themes became principles that formed the foundation of the Navy’s approach to tactics and doctrine in the early part of the twentieth century. If the performance of the Navy in World War Two is any indication, Mahan’s approach was successful.

Do software teams need something similar? Does the U.S. Government?