Gut-Driven IT Development
Introduction
Following your gut can result in mistakes — a lot of them. When coupled with poor timing, an individual’s unbridled, gut-driven enthusiasm is bound to create a recipe for disaster. This is especially relevant in the realm of IT; premature optimization, leaving liabilities untreated, and reinventing the wheel are all symptoms of gut-driven development. While following your gut can be advantageous, it often produces chaotic IT solutions.
This begs an important question: how does this chaos manifest, and what can we do to stop it?
Cloud “Agnocalypse”
At our humble startup, we had a distributed monolith that was barely afloat in a public cloud. Firefighting was the norm. When problems came up, we solved them; then, we promptly moved on to the next problem. Eventually, an incident involving cryptocurrency mining helped us finally understand the dire nature of our situation. Desperate for a solution, we hired a specialist to assist.
At the time, an overabundance of blogs about cloud-agnostic platforms were dominating the tech world’s discourse. In meetings — or in our little office kitchen, waiting for our lunches to microwave — all we could discuss was the wonders of limitless portability and maximized redundancy. One particular new tool, backed by a tech giant, piqued our interest. Whenever a problem surfaced, so did this tool’s name. “Are we switching platforms?” I asked. The specialist answered, “No, but you never know when our cloud provider will wither away.”
Before long, we all started to believe that the rumors were true: this tool was the silver bullet. The team lead finally succumbed. We diverted all but the bare minimum amount of work from the managed platform to the new one. With great excitement and a quick start guide, we built a new platform. The microservices team customized the monolith to work on this platform for new customers. After devoting time and meticulous detail to this platform, we were overjoyed — it finally worked.
A little over a week after the new platform was up and running, a new hire joined us. Loudly chewing his gum, he gestured dismissively at his computer screen, noting that the platform was not agnostic enough. He had been reading the same blogs, it seemed. Unfortunately, he was totally correct. The very service that enabled the construction of the new platform entangled us with the cloud provider in ways that would require significant effort to fix.
The team began to ooze with disdain for the platform’s current state, vowing to sever all ties to the provider. Upon hearing the news, management grew anxious; but after the team shared a few Facebook Parse stories, the decision-makers begrudgingly agreed to rework the platform. We made a plan and resumed our earnest work.
One day, our services went dark. It turned out that verbose logging from a microservice had consumed all of the host’s storage, bringing both the host and its services down. In an act of solidarity, the monolith collapsed. With no self-healing, we had to intervene. In order to avoid a repeat event, we checked the managed platform for anything we might have missed, revealing several sprints worth of features. When work started piling up, we asked for help. The startup restructured the team and hired a third specialist; although, by then, its coffers were running low.
Within a week of joining the team, the new hire had flagged countless problems. He demonstrated newer ways of using the same tech and suggested a complete rebuild. In order to get on board, the others needed convincing, and heated arguments ensued. The excited conversations we’d once had in the kitchen and in meeting rooms faded into hostile silence. As tensions rose, one or two people quit, and others were asked to leave. By then, the startup was stuck with no good options. The sunk cost totally prevented us from thinking of a different approach, pushing the startup down the same road. At the same time, the team was pressed progressively harder under looming deadlines and unplanned work. Ultimately, we were forced to do the unthinkable: become cloud-provider specific.
The startup ended up with three semi-cloud-agnostic, differently-developed platforms with a bespoke-platform-native distributed monolith on a single cloud provider. The startup was bled dry; all its new initiatives halted, and the obsessive builders started to flee. Eventually, after a year of sorting out the mess, the startup could finally focus on the customers’ actual needs.
An Alternative Approach: Wardley Mapping
I recount these events not to deter people from using specific tech or concepts. Instead, my goal is to illustrate what can happen due to gut-driven development. Unfortunately, this story isn’t unique or even extreme. The webcomic below tells the all-too-common story.
Startups are vulnerable to this issue due to their intrinsic aspects. They are typically frugal, under immense time constraints, and uncertain of their needs. I have seen examples of this throughout my consulting career, and it doesn’t show any sign of stopping.
In IT, one idea is clear: we are too dependent on our fallible gut instinct. Unfortunately, this isn’t a simple problem, and I don’t have a one-size-fits-all solution. There is no replacement for well-developed gut instinct — but there is a better way.
While scouring the web, I stumbled upon Wardley Mapping. Wardley Mapping is a strategic intent tool that applies Sun Tzu’s Five Factors — Purpose, Landscape, Climate, Doctrine, and Leadership — to the business world.
Begin with figuring out the “why” and “what”. What is it that you are trying to do, and why are you doing it? Next, visualize the business landscape by placing the items on a Wardley map that displays each user, as well as their needs and capabilities. The item’s position is guided by two things:
1. The evolution characteristics. The evolution stages are Genesis, Custom, Product (+rental), and Commodity (+utility).
2. The relative visibility to the user.
This is how the map will look.
Look over the climatic patterns table to familiarize yourself with the external forces, and combine this with the doctrine to figure out the “why” of movement.
Although this method returns to an old conceptual idea, this approach is often necessary in the realm of IT development. Here are three ways you can use Wardley Mapping to flag common pitfalls.
1. Reduce Bias
Contrast your solution with the rest of the world. What is different about your solution, and why? For example, let’s think about data centers. Are you managing your own, or using a reputable provider? If your item use is the red dot below and the white dots are your competitors, ask yourself whether your use is delivering value or wasting effort.
2. Detect Liabilities
Money spent is a reliable indicator of liability. Ask finance for help in visualizing the flow of money. The example map below illustrates a tea shop that sells a cup of tea. The map shows how money flows with a blue arrow, a green arrow, and associated numbers. In the tea shop example, the custom-built kettle eats up roughly 30% of the revenue. Should the tea shop be custom-building a kettle at all? Would standardizing the kettle help reduce the cost?
3. Use Appropriate Methods
Here is another example; this time, it shows different approaches based on each item’s evolution stage. From this, we can learn two crucial things.
A) Whether to Build, Buy off the shelf, or Outsource
Building is not cheap. With this in mind, we ought to stick to building what is unique and superior about our solution; everything else is undifferentiated heavy lifting. Build items in the early stages, and let others deal with the rest by outsourcing or buying off the shelf.
B) Whether to Use Agile, Lean, or Six Sigma
There are different development methodologies, and each has its own merits. If you decide to build things yourself, use Agile to tackle the uncertainties of the early stages. Use Lean to reduce waste for items in Stage 3, and use Six Sigma to optimize well-known commodities and utilities.
Equipped with your Wardley map, you now have a common language that allows people from different aptitudes to collaborate effectively. Use the map to start a meaningful discussion and create a plan of action.
Conclusion
In the case of the startup, we had enough challenges to conquer. Instead of tackling these issues, we chose to sub-optimally divert our own resources, building a cloud provider with bleeding-edge tech that few understood. Our anticipation of eventually needing a different platform not only failed to come to fruition; it also caused us to tumble down a deep rabbit hole.
Our troubles were caused by our sole reliance on our guts, causing us to build the wrong thing at the wrong time. I’ve created this story to show the value of Wardley Mapping. Use it to guide you through the process of decision-making. Although Wardley Mapping isn’t a silver bullet, it is a good start.