• Home
  • Category: Thoughts

A fighter jet isn’t a smartphone… but it could be

I can’t tell you how many times I’ve seen a senior DoD leader hold up their smartphone1 and wonder aloud why their military systems can’t work as seamlessly.

The answer is simple: There is no market that incentivizes companies to build seamless products for the military. Androids and iPhones work so well because there is competition. If Facebook Messenger2 starts releasing buggy versions, users will uninstall it and switch to Signal or Telegram or Snapchat or dozens of other messaging apps with various capabilities. Conversely, if a developer creates a fantastic new app that disrupts the incumbents, everyone will quickly switch to it. This forces the entire industry to continually innovate3.

Apple and Google are also in competition, thus it’s in their interests to foster ecosystems of hardware and software developers that in turn build and maintain market share for their products. The market results in the success or failure of the companies in that ecosystem and that competition results in excellent consumer technologies.

Good enough for government work

The US defense industry is not a competitive market, at least not in the same way4. Incentives across the military-industrial complex are misaligned and our nation’s security suffers for it. Even when everyone involved has the best of intentions, military prime contractors only win projects when they’re just cheap enough, just fast enough, and just good enough.

We joke that it’s “good enough for government work”, but the warfighter and the taxpayer deserve better.

Open architectures

The solution is relatively simple, at least in theory: the government needs to support the creation and enforcement of modular open system architecture (MOSA) standards for every aspect of the battlefield. We have a model for this already: Future Airborne Capability Environment (FACE) is an open software standard and certification process for military helicopters developed as a consortium between government acquisition agencies and major prime contractors. FACE has many benefits:

  • Software reuse across platforms: Solutions developed for one platform can be reused on all compliant platforms, with no or few changes
  • Plug-and-play: Systems can be easily reconfigured for different mission sets
  • Speed and reliability: Developers can easily understand the interfaces and capabilities and automated compliance checking ensures the delivered solutions will work
  • Competition: Anyone can develop to the published standards and offer competing products
  • Sustainment: If a supplier goes out of business, their components can be replaced easily without being hampered by proprietary interfaces
  • Upgradability: Software updates can be released faster and with less risk, as long as compliance checks are passed

All of this adds up to cost and schedule savings as well as the potential for more capable solutions. In addition to being an effective approach, FACE serves as a case study for other acquisition organizations on how to develop their own open standards and enforcement, which is helpful now that federal law requires the DoD to use MOSAs in systems development.

Future vision: There’s an app for that

I’m excited for the ecosystem that this surge will create. I imagine a future where warfighters choose what apps to use from an available library, just like an app store. Instead of program offices acquiring specific technologies, MOSAs will enable them to open up the competition and allow multiple vendors to make approved apps available, and then pay them proportionally by hours of use. This is better for the warfighter as they’ll be able to choose the solution that works best for their needs and mission. This is better for the government as they’ll offload development risk and funding. And this is better for innovative developers who truly care about delivering the best solutions, who will be financially rewarded for creating the best solutions.

That’s a big vision, and a lot has to change before we can get there, but it’s just one of the possibilities opening up as we push toward developing and adopting MOSAs. If you’re interested in learning more and becoming part of the conversation, a new community called MOSA Network was recently launched. Start here with a brief analysis of the Tri-Services Memo based on the new law:

What’s your vision for a MOSA-enabled future? How else can consumer technologies inspire better battlefield solutions? How will you engage in the MOSA network?

Postal vehicles: Function over form

One of my favorite items in my small model collection is a 1:34 scale Grumman Long Life Vehicle (LLV)5 with sliding side doors, a roll-up rear hatch, and pull-back propulsion. The iconic vehicle has been plying our city streets for nearly 40 years, reliably delivering critical communiques, bills, checks, advertisements, Dear John letters, junk mail, magazines, catalogs, post cards from afar, chain letters6, and Amazon packages.

Read More

What makes a good human factors engineer? Five critical skills

Recently, the head of a college human factors program asked for my perspective on the human factors (and user experience) skills valued in industry. Here are five critical qualities that emerged from our discussion, in no particular order:

Systems thinking

Making sense of complexity requires identifying relationships, patterns, feedback loops, and causality. Systems thinkers excel at identifying emergent properties of systems and are thus suited to analyses such as safety, cybersecurity, and process, where outcomes may not be obvious from simply looking at sum of the parts.

Read More

Military-industrial complex

The phrase “military-industrial complex” was coined by President Eisenhower in his farewell address to the nation in 19617. 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:

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

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-ups8, 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

“Diversity of thought” is the “all lives matter” of corporate inclusion efforts

For at least the last decade, engineering companies have talked a great deal about “diversity and inclusion”. Inevitably, many people9 have the takeaway that this means “diversity of thought”. This is like telling a Black Lives Matter supporter that “all lives matter”; of course all lives matter, but that’s completely missing the point10. Diversity of thought is important to avoid groupthink and promote innovation; but that’s not the point of diversity and inclusion efforts11.

Diversity and inclusion means making sure that teams are actually diverse, across a range of visible and not-visible features. Why does that matter?

Read More

Agile SE Part Zero: Overview

“Agile” is the latest buzzword in systems engineering. It has a fair share of both adherents and detractors, not to mention a long list of companies offering to sell tools, training, and coaching. What has been lacking is a thoughtful discussion about when agile provides value, when it doesn’t, and how to adapt agile practices to be effective in complex systems engineering projects.

I don’t claim this to be the end-all guide on agile systems engineering, but hope it will at least spark some discussion. Please comment on the articles with details from your own experiences. If you’re interested in contributing or collaborating, please contact me at benjamin@engineeringforhumans.com, I’d love to add your voice to the site.

Read More

Learn from the mistakes of others

The problem with being too busy to read is that you learn by experience… i.e. the hard way. By reading, you learn through others’ experiences, generally a better way to do business…

General James Mattis

The most successful people in any profession learn from the experiences of others. You can learn from their successes, sure. But don’t focus on doing things exactly they way they did, you’ll stifle your own innovation. Instead, understand their successes, extract relevant lessons, and forge your own path.

More importantly, learn from others’ failures and mistakes.

That’s why I publish a Reading / Listening List. As of the publishing of this article, 5 of the 6 recommendations are about poor engineering and design12. I find these stories fascinating, enlightening, and valuable. By avoiding the pitfalls of the past, we improve the likelihood of success in our own projects.

It’s okay to make mistakes, but strive to at least make original mistakes.

Board man gets paid

For years I’ve been advocating for the effective inclusion of human systems integration (HSI) in the systems engineering (SE) process. I had to address a persistent misunderstanding of what HSI is and how it relates to human factors; while that can be frustrating, I recognized that it wasn’t going to change overnight. Instead, I worked diligently to share my message with anyone who would listen.

Recently, my diligence paid off. I was contacted by a group putting together a proposal for a defense contract. The government’s request outlined their expectations for HSI as part of the systems engineering effort in a way that the proposal team hadn’t seen before. Someone on the team had heard me speak before, knew I had the right expertise they needed, and reached out to request my support.

Read More