Steamships

In the early 80s, Werner Herzog made a film about a man that demanded a steamship be dragged over a mountain in the jungle. To make this film, he demanded that a steamship be dragged over a mountain in the jungle. It was based on a true story: someone in the late 1800s demanded that a steamship be dragged over a mountain in the jungle.

There are some things that ought to be immediately obvious.

First, this isn’t a great way to do things. There had to have been other options. I’m not privy to the details of the original attempt to get the steamship over the mountain in the late 1800s, so maybe they had a great reason. But one of the great things about making a movie is that you get to figure out how to fake the really hard stuff. I’m not familiar with Mr. Herzog; maybe that’s just not the done thing. Who can say?

Second, there were, undoubtedly, a bunch of people that got hurt or killed during these undertakings. They were projects that demanded a lot from the people involved. I imagine that the benefits, such as they were, weren’t what they got to enjoy at the culmination of their efforts.

The Connection

I’ve been working on software for well over a decade. I’ve seen, worked on, and been responsible for a lot of projects in that time. Some of these projects have been outstanding successes. Those are rarer than I’d like them to be. Others have failed in some respect or another: they ran over time, they ran over budget, they hit some insurmountable obstacle that required retooling the approach. A positive way to characterize those is that they taught good lessons; a realistic way to characterize them is that they sucked. Sometimes you could abandon the latter category, sometimes you couldn’t.

There has been a third kind of project that rears its ugly head every so often. They fail in spectacular fashion, sometimes across multiple different axes of failure, and there is no way that the organization responsible can abandon them. There is no going back once you are committed to one of these projects. The mountain is in front of you, the steamship is in position, and you can only pull on the rope.

The Characterization

To expand a bit on the distinction, this third category of projects that turn into harmful disasters have some qualities about them to separate them from projects that just got a bit annoying. 

They involve a lot of people, more than just the team responsible for the work. Maybe it’s a few teams, maybe it’s some stakeholders getting involved, maybe it’s a bit of both.

There is a very good reason the organization can’t find a way to do anything other than drag the steamship over the mountain. Sometimes it’s because the platform they were using is going to cease to exist and they can either shut their doors or make a big changeover.

There is some decision that was made at a key point in the lifecycle of the project that turned it into this hulking beast. Sometimes that decision is right at the very beginning, sometimes it’s later. The precise timing doesn’t matter, just that the conditions turn poor at some point.

Making Mountains

Unfortunately, I’ve had personal experience with a handful of these projects. A common theme amongst them is that the organization was on Platform X and, for whatever reason, that just wasn’t going to be the state of the world in the future. We had to move to Platform Y. There’s no getting around it! The money got spent and the time got committed and the job is to get to Platform Y from here.

I’ve uncovered a couple of recipes for creating these mountains.

One

A salesperson wriggles out from underneath a rock long enough to rope someone with a company checkbook into buying some new service. They might use words like “best practices.” They may tell them that there will be vendor support for the organization as they make the transition from Platform X to Platform Y. They may suggest that they could tie a string on the moon and gift it to the executive as a token of goodwill. All of these are, at best, lies of omission. At worst, they’re just outright falsehoods.

I distinctly remember being asked how long I thought it would take to make this transition happen at one company. They asked me because I had worked on a bunch of useful internal applications and I had the insider information on where data got created, where it got used, and what we positively could not live without. This amounted to over thirty years of accumulated business knowledge locked up in software dating back to the early 80s, incidentally right around the time Werner Herzog was making his film. “They said we could be done with the change in six months,” an executive said to me, his eyes aflame with glee as he thought of all the best practices laying in wait in the not-too-distant future.

I laughed. “Five years,” was my considered response. “Five years of no new initiatives and everyone working around the clock to get this done.” My belief was that the truth as I saw it would help them go back to the drawing board and cook up a better plan, a gentler transition, a more considered approach to the required business analysis to make the move.

Instead, they decided that the real problem was that there weren’t enough hands to haul on the metaphorical ropes to drag the ship around. I helped coax this particular ship up the slope for a little over two years before departing for better conditions, but not before it had done some damage to me.

Two

At some point in the project’s life, maybe the beginning, an entity with crucial information made a bad choice or a bad recommendation. Since nobody else has the information required to evaluate the situation, this tiny inflection point was allowed to generate a problem that eventually would lead to a steamship and a mountain. As a deadline looms and stakeholders get nervous, investigations are conducted and reality peeks through whatever narrative had been constructed. Suddenly meetings are filled with people saying “best guess for an estimate” and “back on track” and other kinds of things that let them cling to a feverish hope that maybe it’s just a rowboat and a bunny hill.

This kind of project also tends to be of the variety where we must move from Platform X to Platform Y. The distinction is simply that the call comes from inside the house.

Warning Signs

There are a few ways to tell if a steamship and mountain will manifest in your future. These aren’t guarantees, but they’re definitely signs that you should maybe take a minute to evaluate the situation. Quickly, while there’s still time!

First, if anyone uses the word “simply” (or implies it, or coughs up any synonyms) at any point in describing how they will move from Platform X to Platform Y. Experience has taught me that there is never an easy problem. There is never a simple step to take. Every last ounce of the development effort involved will require managing some complexity. If you hear someone downplaying any step in this process and they don’t have an airtight case as to why they’re downplaying it? Get suspicious.

Second, if a key person in the process is just entirely checked out. You may not be able to tell right away, but if you get them into a conversation and they handwave away concerns about deadlines or potential troubles, they are actually hard at work constructing a steamship. You just didn’t know it before.

Third, if a sales representative from a different company was the creature that was responsible for setting Platform Y as a target. Their intention is not to help you, the development team. They’re responsible for extracting a bunch of money from the company. Implementation is your problem long after the check cleared.

Moral Implications

If you are in a position to materially affect the project in question, you should absolutely go out of your way to ensure that it doesn’t turn into a steamship and mountain situation. I’m only talking about building software here; the odds that someone gets crushed under the weight of heavy equipment are thankfully low. We’re a long way from the human rights abuses implicit in being forced to drag a steamship over a mountain. We’re also a long way from the run-of-the-mill awful working environment that would be undertaking this task willingly for the sake of art. But that doesn’t give you carte blanche to make someone’s working environment awful in other ways.

I’ve seen organizations lose a lot of talent (sometimes all in one afternoon) over this. I’ve seen people leave with sour tastes in their respective mouths. Others who contemplated quitting the field entirely. All of this was preventable! This is the manner by which they build a future and live!

Through a ruthlessly cynical lens, I’d also simply argue that this is bad for business. If your projects routinely turn into this kind of debacle, you’ll get a reputation. You’ll drive out people that have centuries of aggregate domain knowledge. These are the people that are responsible for building and maintaining the theoretical machinery that takes the raw material of information and turns it into things that put money directly into the coffers of the business. It’s best to keep them around. Especially because their reward for successfully getting the ship to the other side is, potentially, yet another steamship!

Parting Thoughts

I am fascinated by these kinds of projects. Each one of them is filled with useful lessons and deeply entertaining drama. Even when I have been a part of them, there has been some kind of deep absurdity that kept me engaged.

I’ve also seen these come to an end. Successfully! The end state of this is that eventually you do, indeed, clear the mountain. The ship comes to rest on the other side. Things have an opportunity to get better. The teams have a chance to figure out what went wrong and how to keep the next one from turning into a similar mess.

I don’t think you can avoid them all the time, either. Some projects are just destined to be this gnarly right out of the gate. If that is the case, it pays to know up front. Not because there are mitigation strategies, but because you can prepare yourself for the undertaking. Especially knowing that they will, in fact, end.