As a research company dedicated to transitioning real capabilities, we focus on problems where technical innovation can unlock operational choices.

For example, it’s long been assumed that interoperability can either be upgradeable or scalable, but not both. Our STITCHES Toolchain started with the realization that a change in approach to (and a better toolchain for) interoperability could let us simultaneously achieve both. This allows for shorter platform development timelines (because they can be adapted later), decreased costs, and increased flexibility to adapt to future needs.

We believe that it’s possible to know whether a problem is solvable without knowing what the solution looks like.

How? We think a lot about information theory and whether the problem provides enough information for a solution to exist. If we don’t believe a problem is solvable, we will look for a different version of the problem that addresses the same need but can be solved. This is a huge factor in how we decide which projects to bid and work on. We often choose not to bid projects because we don’t believe the problem, as defined, can be solved.

Defining the right problem is often just as hard (and even more important than) finding the solution. Therefore, we seek to understand key operational issues that drive the need – which is not always the same as the technical solution users think they need or what other engineering efforts have tried to provide.

In our experience, removing unnecessary (but seemingly useful) edge cases often converts a problem from impossible to tractable.

For example, with STITCHES we realized that historical problem statements required an absolute semantic, or that messages have universally defined meanings (which they don’t!). This simple assumption alone was enough to make the problem impossible. Relaxing this assumption unlocked key degrees of freedom in the solution space that allowed us to develop STITCHES.

We bring together people with different backgrounds to form cross-disciplinary teams with a range of toolsets at use. As odd as it might sound, we often find ourselves leveraging ideas from physics and control theory directly in our software architectures or experimentation designs.

Practically, our goal is to find clean representations of the problem and solution that allow us to decouple concerns, so we can design an architecture that allows us to explain when it works and when it doesn’t. Sometimes, this means that we have to create control structures that continually work (at run time) to make sure the decoupling that we want to assume actually holds true.

Transitioning real capabilities requires showing real, useful results early on. (DoD budgeting means that it can take 1 – 2 years for folks to secure funding after they realize they want your technology.) This often means developing both applications and toolchains in parallel. While we don’t hold teams to specific software development styles, we do believe in providing incremental functionality that meets user needs through regular releases.

Along the way, we do plenty of prototyping to explore the space, often re-implementing once we have clarity on a design. While re-writing might sound inefficient, we’ve found it to be quite the opposite: the 2nd implementation is often much faster, and, as good architectures reduce the bug surface (a lot!), we’ve found that this approach lets us spend more time on the innovative design work and a lot less time finding bugs and fixing them.