• Home
  • Category: View All Articles

Military-industrial complex

The phrase “military-industrial complex” was coined by President Eisenhower in his farewell address to the nation in 19611. In this address, Eisenhower spoke of the deterrence value of military strength:

A vital element in keeping the peace is our military establishment. Our arms must be mighty, ready for instant action, so that no potential aggressor may be tempted to risk his own destruction.

Simultaneously, he warned of the potential danger in the growing relationship between the military establishment and the defense industry:

In the councils of government, we must guard against the acquisition of unwarranted influence, whether sought or unsought, by the military-industrial complex. The potential for the disastrous rise of misplaced power exists and will persist.

The phrase “military-industrial complex” describes the intertwined relationship between the military establishment and the defense industry that emerged during the Cold War. This relationship was and is characterized by mutually-reinforced growth. The defense industry relies on the military for contracts and the military relies on Congress for funding. Thus industry lobbying of Congress to maintain and increase defense spending grows the political and economic power of both military and industry.

The origins of the military-industrial complex can be traced back to the post-World War II period, when the United States emerged as a global superpower and faced a new threat in the form of the Soviet Union. The Cold War led to a massive expansion of the military establishment and the development of new technologies, including nuclear weapons, missiles, and advanced aircraft. During this period, the defense industry grew rapidly as companies such as Boeing, Lockheed, and General Dynamics competed for government contracts. The defense industry became a major contributor to the American economy, with billions of dollars in government contracts providing jobs across the country as well as profits for companies and their shareholders.

As the military establishment and the defense industry became increasingly intertwined, concerns began to emerge about the potential for corruption and the influence of the defense industry on government policy. Thus Eisenhower’s warning about the military-industrial complex:

We must never let the weight of this combination endanger our liberties or democratic processes. We should take nothing for granted only an alert and knowledgeable citizenry can compel the proper meshing of the huge industrial and military machinery of defense with our peaceful methods and goals, so that security and liberty may prosper together.

In the decades since Eisenhower’s warning, the military-industrial complex has continued to evolve and expand. The phrase itself has become a useful2 shorthand for the entanglement of corporate interests with government and policy-making more broadly.

One of the most significant risks of this relationship is the potential for it to lead to the prioritization of corporate profit over public welfare, such as the lobbying of politicians by defense contractors to secure lucrative government contracts and the influence of defense industry executives on policy decisions related to national security and military spending.

Another criticism of the military-industrial complex is the impact it can have on the economy. While defense spending can create jobs and stimulate economic growth in certain industries, it can also divert resources away from other sectors of the economy, leading to a lack of investment in areas such as healthcare, education, and infrastructure. Additionally, the reliance on military spending as a source of economic growth can lead to a dangerous cycle of increasing defense spending to maintain economic stability, even when it is not necessary for national security.

The military-industrial complex can also contribute to a culture of militarism, where the solution to problems is seen as being a military one. This can lead to the neglect of non-military solutions to problems and the proliferation of militarized conflict, which can have devastating consequences both domestically and abroad.

One of the key arguments in favor of the military-industrial complex is that it can lead to technological innovation and progress. Military-funded research and innovations are very often applied to other areas of society, such as healthcare or transportation. Much of this research may not have been conducted without military funding. Eisenhower noted this fact as well, and included it as yet another risk of the military-industrial complex:

Today, the solitary inventor, tinkering in his shop, has been over shadowed by task forces of scientists in laboratories and testing fields. In the same fashion, the free university, historically the fountainhead of free ideas and scientific discovery, has experienced a revolution in the conduct of research. Partly because of the huge costs involved, a government contract becomes virtually a substitute for intellectual curiosity.

The United States has the most powerful military in the world, a fact that is extremely valuable to our nation and allies. It is an invaluable deterrent against potential aggressors, it puts weight behind NATO, it ensures freedom of navigation in international waters and airspace, it backs up our diplomatic efforts and our leaders’ words. Yet the influence of the military-industrial complex on our nation’s priorities and policymaking cannot be ignored, and Eisenhower’s speech is as relevant today as it was in 1961.

Agile SE Part Five: Agility on Large, Complex Programs

Table of Contents

Putting it all together

In this series we’ve introduced agile concepts, requirements, contracting, and digital engineering (DE) for physical systems. These things are all enablers to agility, they don’t make a program agile per se. The key for agility is how the program is planned and functions prioritized.

Agile program planning

A traditional waterfall program is planned using the Statement of Work (SOW), Work Breakdown Structure (WBS), and Integrated Master Schedule (IMS). This basically requires scheduling all of the work before the project starts, considering dependencies, key milestones, etc. Teams know what to work on because the schedule tells them what they’ll be working on when. At least in theory.

Read More

College interviewing tips

For several years I’ve been volunteering as an alumni interviewer for my alma mater. It’s enjoyable to spend a bit of time interacting with a younger generation and exploring their interests; my optimism is buoyed by their potential.

Read More

Minimum Viable Product (MVP): You’re doing it wrong

Quibi was a short-lived short-form video app. It was founded in August 2018, launched in April 2020, and folded in December 2020, wiping out $1.75 billion of investor’s money. That’s twenty months from founding to launch and just six months to fail. Ouch.

Forbes chalked this up to “a misread of consumer interests”; though the content was pretty good, Quibi only worked as a phone app while customers wanted TV streaming, and it lacked social sharing features that may have drawn in new viewers. It was also a paid service competing with free options like YouTube and TikTok. According to The Wall Street Journal, the company’s attempts to address the issues were too late: “spending on advertising left little financial wiggle room when the company was struggling”.

If only there was some way Quibi could have validated its concept prior to wasting nearly two billion dollars1.

Read More

Agile isn’t faster

A common misconception is that Agile development processes are faster. I’ve heard this from leaders as a justification for adopting Agile processes and read it in proposals as a supposed differentiator. It’s not true. Nothing about Agile magically enable teams to architect, engineer, design, test, or validate any faster.

In fact, many parts of Agile are actually slower. Time spent on PI planning, backlog refinement, sprint planning, daily stand-ups1, and retrospectives is time the team isn’t developing. Much of that overhead is avoided in a Waterfall style where the development follows a set plan.

Read More

You Don’t Understand Murphy’s Law: The Importance of Defensive Design

CALLBACK is the monthly newsletter of NASA’s Aviation Safety Reporting System (ASRS)1. Each edition features excerpts from real, first-person safety reports submitted to the system. Most of the reports come from pilots, many by air traffic controllers, and also the occasional maintainer, ground crew, or flight attendant. Human factors concerns feature heavily and the newsletters provide insight into current safety concerns2. ASRS gets five to nine thousand reports each month, so there’s plenty of content for the CALLBACK team to mine.

The February 2022 issue contained this report about swapped buttons:

Read More

Agile SE Part Four: Digital Transformation

Table of Contents

A quick detour

This article is a quick detour on an important enabler for agile systems engineering. “Digital transformation” means re-imagining the way businesses operate in the digital age, including how we engineer systems. As future articles discuss scaling agile practices to larger and more complex systems, it will be very helpful to understand the possibilities that digital engineering unlocks.

Digital engineering enables the agile revolution

The knee-jerk reaction to agile systems engineering is this: “sure, agile is great for the speed and flexibility of software development, but there’s just no way to apply it to hardware systems”. Objections range from development times to lead times to the cost of producing physical prototypes.

Read More

Agile SE Part Three: Agile Contracts and the Downfall of Requirements

Table of Contents

The antithesis of agile

Requirements are a poor way to acquire a system. They’re great in theory, but frequently fail in practice. Writing good requirements is hard, much harder than you’d think if you’ve never had the opportunity. Ivy Hooks gives several examples of good and bad requirements in the paper “Writing Good Requirements“. Poor requirements can unnecessarily constrain the design, be interpreted incorrectly, and pose challenges for verification. Over-specification results in spending on capabilities that aren’t really needed while under-specification can result in a final product that doesn’t provide all of the required functions.

If writing one requirement is hard, try scaling it up to an entire complex system. Requirements-based acquisition rests on the assumption that the specification and statement of work are complete, consistent, and effective. That requires a great deal of up-front work with limited opportunity to correct issues found later. A 2015 GAO report found that “DoD often does not perform sufficient up-front requirements analysis”, leading to “cost, schedule, and performance problems”.

And that’s just the practical issue. The systematic issue with requirements is that the process of analyzing and specifying requirements is time consuming. One of the more recent DoD acquisition buzzphrases is “speed of relevance”. Up-front requirements are antithetical to this goal. If it takes months or even years just to develop those requirements, the battlefield will have evolved before a contract can be issued. Add years of development and testing, and then we’re deploying last-generation technology geared to meeting a past need. That’s the speed of irrelevance.

Agile promises a better approach to deliver capabilities faster. But we have to move away from large up-front requirements efforts.

Still from Back to the Future Part 2 with subtitles changed to: Requirements? Where we're going, we don't need requirements!

Agile contracting

Traditional requirements-based acquisition represents a fixed scope, with up-front planning to estimate the time and cost required to accomplish that scope. Pivoting during the development effort (for example, as we learn more about what is required to accomplish the mission) requires re-planning with significant cost and schedule impacts. The Government Accountability Office (GAO) conducts annual reviews of Major Defense Acquisition Programs (MDAPs). The most recent report analyzing 85 MDAPs found that they have experienced over 54 percent total cost growth and 29 percent schedule growth, resulting in an average delay of more than 2 years.

Defense acquisition leaders talk about delivering essential capabilities faster and then continuing to add value with incremental deliveries, which is a foundational Agile and Dev*Ops concept. But you can’t do that effectively under a fixed-scope contract where the emphasis is on driving to that “complete” solution.

The opposite of a fixed-scope contract is a value stream or capacity of work model. Give the development teams broad objectives and let them get to work. Orient the process around incremental deliveries, prioritize the work that will provide the most value soonest, and start getting those capabilities to the field.

triangle with vertices labeled "SCOPE", "COST", and "TIME", the center is the word "QUALITY"
Project Management Triangle

“But wait,” you say, “doesn’t the project have to end at some point?” That’s the best part of this model. The ‘fixed’ cost and schedule contract keeps getting renewed as long as the contractor is providing value. The contractor is incentivized to delivery quality products and to work with the customer to prioritize the backlog, or the customer may choose not to renew the contract. The customer has flexibility to adjust funding profiles over time, ramping up or down based on need and funding availability. If the work reaches a natural end point—any additional features wouldn’t be worth the cost or there is no longer a need for the product—the effort can be gracefully wrapped up.

You may be familiar with the project management triangle1. Traditional approaches try to fix all of the aspects, and very often fail. Agile approaches provide guardrails to manage each of the aspects but otherwise allow the effort to evolve organically. This is a radical shift for program managers and contracting offices, but is absolutely essential for true agile development.

Agile requirements

The most important aspect of agile approaches is that they shift requirements development from an intensive up-front effort to an ongoing, collaborative effort. The graphic below illustrates the difference between traditional and agile approaches. With traditional approaches, the contractor is incentivized to meet the contractual requirements, whether or not the system actually delivers value to the using organization or is effective to the end user.

Block diagram showing acquisition models. Traditional acquisition model includes using organization defining need to acquisition organization writing requirements for contractor organization delivering system to using organization deploying system to end users. Agile acquisition model includes using organization defining need to acquisition organization creating an agile contract to contractor, iterative feedback between contractor and end users, collaboration among all groups, the contractor continuous delivery to using organization which then deploys to end users.

In an agile model, the development backlog will be seeded with high-level system objectives. Requirements (or “user stories”) are developed through collaboration among the stakeholders and the development is shaped by iterative user feedback. The agile contract may have a small set of absolute requirements or constraints. For example, the system may need to comply with an established architecture or interface, meet particular performance requirements, or adhere to relevant standards. The key is that these absolute requirements are as minimal and high-level as possible.

This enables the stakeholder requirements discovery, analysis, and development process to be collaborative, iterative, and ongoing. The resulting requirements set isn’t radically different from a traditional requirements decomposition: requirements still have to be traceable from top to bottom. A key difference is that the decomposition happens closer to the development, both in time and organization. The rationale and mission context for a requirement won’t get lost because the development team is involved in the process, so they understand the drivers behind the features they’ll be implementing. Also, because the requirements aren’t enshrined in a formal contract they can be easily changed as the teams learn more from prototyping and user engagements.

I’m getting ahead of myself, though! In the next installment of this series we’ll look at digital engineering as a key enabler of Agile SE before moving on to the importance of cross-functional development teams, the role of Product Owner, and scaling up to a large project.

What are your experiences with agile contracts and agile requirements? Share your best practices, horror stories, and pitfalls to avoid below.

Agile SE Part Two: What’s Your Problem?

Table of Contents

A faster horse

“If I had asked people what they wanted, they would have said faster horses.”

Apocryphally attributed to Henry Ford1

When people trot out that quote they’re often trying to make the point that seeking user feedback will only constrain the design because our small-minded <sneer>users</sneer> cannot possibly think outside the box. I disagree with that approach. User feedback is valuable information. It should not constrain the design, but it is essential to be able to understand and empathize with your users. They say “faster horse”? It’s your job to generalize and innovate on that desire to come up with a car. The problem with the “singular visionary” approach is that for every wildly successful visionary there are a dozen more with equally innovative ideas that didn’t find a market.

Read More

Agile SE Part One: What is Agile, Anyway?

Table of Contents

What is “Agile”?

Agile is a relatively new approach to software development based on the Agile Manifesto and Agile Principles. These documents are an easy read and you should absolutely check them out. I will sum them up as stating that development should be driven by what is most valuable to the customer and that our projects should align around delivering value.

Yes, I’ve obnoxiously italicized the word value as if it were in the glossary of a middle school textbook. That’s because value is the essence of this entire discussion.

Little-a Agile

With a little-a, “agile” is the ability to adapt to a changing situation. This means collaboration to understand the stakeholder needs and the best way to satisfy those needs. It means changing the plan when the situation (or your understanding of the situation) changes. It means understanding what is valuable to the customer, focusing on delivering that value, and minimizing non-value added effort.

Read More