At feenk, we say we untangle your legacy software crises. We find the fires in your system and we guide you to extinguish them.

What kind of crises? Perhaps, you have just failed a migration. Or, the system's failures appear in the news. Or, you cannot adjust your system fast enough to keep up with the market. Or maybe, you simply do not know where to start that modernization project.

Most of these crises stem from a lack of accurate insight into the system. You do not lack the ability to solve the problem. You lack the ability to see the problem.

We start by identifying the specific problems in your crisis. We explicitly and systematically assess your system by means of auto-generated views. These views are created specifically to match your problems and they replace the typical slides and views produced through manual inspection. Why is that important? Because you are spending the largest chunk of your budget on that implicit manual inspection. By generating custom views, you free energy to actually solve the problem.

The outcome? An assessment that informs your path to action. A custom tool that can guide your further actions. And a process that is repeatable.

This Wardley Map provides an overview of the key elements in our approach.

Let's take compose it step by step.

We start from the people that face the crisis. We find they are always highly motivated, but they often face two concomitant fears: They fear changing the system, And they fear not being able to change the system. It’s paralyzing. We address this first.

A crisis always relates to a specific problem. As systems are highly contextual, assessing the problem requires custom views. Presently, people often create these views manually. This is a problem as systems are too large and change too quickly to be grasped manually.

So, we guide assessment through custom views that are generated. They are custom in that we literally create them for every problem. We say that it’s the system’s responsibility to present itself in a way humans can reason about.

What does that mean? Let’s look closer.

Most of the development effort consists of people trying to figure the system out by reading their way through it. This is directly linked to the nature of tools.

Typically, tools offer only generic out-of-the-box presentations. So, people read because that can be adapted.

We replace manual inspection through code that is specifically crafted for the problem. This is made practical by a new bread of moldable tools, such as Glamorous Toolkit.

Like this, generated custom views become a commodity that enable new strategies for decision making.

This implies new skills that are necessary to have in-house. And you want to rethink processes, too, because you just got a new feedback loop.

It’s a leap, much like testing or continuous delivery were. When tools become code, legacy needs not be an impediment anymore. It can become an opportunity.