“We cleanly separate what needs to happen from how it will happen to ensure our options stay open. We take pains to make decisions easily reversible so that no decision is ever final, because circumstances always change.”
By Doug Knesek, Flexion
Introduction
In past articles, we have explored how our Flexion Fundamentals came to be and why we place such a high value on diverse thinking. In this article, we will look at the guiding role of our second fundamental as we explore:
- The universal role of optionality
- How Flexion got here
- Putting the soft back in software
The universal role of optionality
As stated in a previous article, the Agile principles practiced by Flexion assume unpredictability and achieve effectiveness by keeping developmental options open. By making the second Flexion Fundamental a seminal part of our work, we remove the constraints that limit options during any project (and beyond). You still have to be looking for options to find them, but this Flexion Fundamental lays the groundwork for options to emerge.
Separating the what from the how has always been central to software design. Explicit separation reached the mainstream with some object-oriented languages where separating the interface (the what) from the implementation (the how) was a crucial part of the technical discipline.
The distinction between interface (the what) and implementation (the how) shows up in consumer products and service designs, from software to banking deposit slips to three-pronged plugs and outlets, and is arguably the single most significant concept for enabling options in the world.
How Flexion got here
Optionality is critical any time there is a high degree of uncertainty, enabling us to pivot in any direction to serve our clients’ changing circumstances more effectively. Separating the what and how enables us to try many potential solutions by keeping the system pliable.
But when the lines between the what and the how are opaque, the opportunity to find other ways of doing things diminishes significantly, and opportunities to create an evolvable design remain hidden. It’s the act of distinguishing one from the other (the what from the how) that reveals the potential for new options to emerge.
We agree with Robert C. Martin, in “Clean Architecture: A Craftsman’s Guide to Software Structure and Design,” when he says, “The path we are most interested in is the cleanest one. It recognizes the softness of software and aims to preserve it as a first-class property of the system. It recognizes that we operate with incomplete knowledge, but it also understands that, as humans, operating with incomplete knowledge is something we’re good at. It plays more to our strengths than our weaknesses. We create things. We discover things. We ask questions, and we run experiments. Good architecture comes from understanding it more as a journey than as a destination, more as an ongoing process of inquiry than a frozen artifact.”
But we went one step further and adapted Martin’s work in Clean Architecture to our own purposes, which we call Option-Enabling Software Architecture (OESA). Our form of architectural discipline simplifies iteratively and incrementally separating the what from the how in areas most likely to change as the client’s and users’ needs change. Deploying this strategy enables options at all scales of the product, resulting in software that can evolve in response to these changes in circumstance.
Flexion cannot exercise our other values if this decoupling doesn’t occur. For example, while we will always embrace diversity, the value of having diverse thinkers is relevant only if the system is flexible enough to try something new.
Our second fundamental enables incremental adaptations and more
Using Flexion Fundamental 2, we can adapt to changing circumstances when options fail to produce the results we anticipated. Eighty percent of the time, this is how Agile works—by adapting to impediments or challenges incrementally.
For example, if we choose a user interface design to enable a user to achieve a specific goal and it doesn’t perform to their satisfaction, we can switch this design out for a better one without jeopardizing more important interests because our what is independent of our how.
But the benefits of applying this fundamental do not stop with adaptation toward a better solution.
Faster but rarer exaptations happen, too
Separating the what from the how also creates opportunities for rapid innovation through the radical repurposing (exaptation) of the how. Here’s an example of exaptation in another industry: During World War II, Percy LeBaron Spencer, an American self-taught engineer, was working on developing radar technology for Raytheon. One day, he noticed that the “Mr. Goodbar” he was carrying in his pocket had melted when he was in the same room with an active radar set.
Spencer’s discovery led to an exaptation that used microwave-generating cavity magnetrons (a how) to cook food (an alternative what). Today, this innovative technology is used in microwave ovens, which are in 90 percent of kitchens in the U.S.
Putting radical repurposing into action
At Flexion, we have created the opportunity for exaptations to occur by holding an Options and Experiments (O&E) meeting every Thursday morning. At these meetings, individuals or teams often present a how. Maybe it’s an experiment they tried out, which led to a specific and impactful adaptation. Others in the meeting then have the opportunity to apply this how to come up with a radically repurposed what that may or may not relate to a project of their own.
Most innovation in nature and by humans is done by radically repurposing something that already exists. When somebody writes a given algorithm that solves a particular problem, and you invoke it through a clean, simple interface, there might be many more purposes for this algorithm. But if the algorithm is connected to only one use, the possibility of separating it to use elsewhere may go unnoticed.
Putting the soft back into software
By increasing optionality in our code, Flexion puts the soft back into software. Initially, the term soft indicated it was easy to change. As we’ve said, if you separate the what from the how you can more easily pivot as unexpected challenges or opportunities arise. But when you couple them together too tightly, the software becomes rigid and unchangeable, like hardware. This stymies our teams’ potential to develop more creative solutions.
Intentionally separating the what from the how enables problems and solutions to be combined in novel ways leading to resilience and innovation that directly benefits Flexion and its clients.
To inquire about partnering with us on public or private sector work, please email sales@flexion.us.
Contact one of our recruiters if you want to work at a company where your unique skills are valued.
Next installment in our Origin Stories series: Flexion Fundamental 3. Collaborate
Join us for our next article, when we’ll dig into our third fundamental and demonstrate how it relates to our core value of collaboration.
For the past six years, Doug Knesek has supported Flexion as an agile coach and delivery leader. Over the past thirty years, he has worn nearly all technical and project management hats in the custom applications development domain. Over the last decade, Doug has used his experience to apply the concepts of agility and self-organization to organizational design and evolution.
