The Spaceship of Theseus

When building new is better than enhancing the old

As of this or some other moment, you and the rest of your team are probably in the process of needing to replace or enhance…something. You or someone else must decide if the team can bring your current product up to the times or if you all have to decide that your 2001 Ford Escort is not going to make it to 200,000 miles and must be traded in. Mine only made it to 191k. It is rarely an easy decision to make. On a rare occasion, you will happen upon a team (one that you might be part of) that has decided that bringing their current system up to the times is the correct answer. Unfortunately, their current technologies have all the power and prestige of a wooden boat and they want to be flying in a spaceship. The idea we want to explore in this circumstance is that building a new system is often better than spending exponentially more time and money on bringing your current technology to the 21st century.

First, The Ship of Theseus

The Ship of Theseus is an old thought experiment about the nature of identity. If I have an ancient (probably Greek) wooden ship, and I replace every piece of that ship one by one over time, is it still the same ship? At what point during the replacing of parts does the original cease to be if it is not the same ship? None of the parts at the end of the process are their original part, but it still has the same name, maybe the same people are sailing the ship, and by the time you replace the last part, the first part replaced likely looks broken in as if it was never replaced. If someone walked away at the beginning of the process and came back at the end, they might think you gave the ship a good wash.

We could go on and on about the Ship of Theseus and what identity really means or if our incessant personification of objects just reveals our inherent, malignant anthropocentrism, but that is neither here nor here. It might be there.

The Spaceship of Theseus

Instead of the end product being an ancient, wooden ship, imagine that your team has decided that they are going to replace each plank, beam, rope, and sail until the end product is a spaceship. Why a spaceship rather than a better wooden ship? Often when a team wants to do something like this, they don’t just want to modernize their product. The modernization of their product is typically accompanied by the need to make their software or product offering exponentially more robust than it is now to stay ahead of the competition. The competition I speak of spent the last few years innovating rather than demanding that their horse run as fast as a Ferrari. When this happens, your client or team will want to go from ship to spaceship, and they want to do it quickly. On top of this, there is an almost 102% chance that this new system needs to look and function significantly different than your exhausted horse/wooden ship.

Sounds difficult, yeah? For the sake of maintaining the metaphor, we can pretend that spaceships are still incomprehensibly complex compared to a wooden ship, but they only have about 50% more parts. The extra parts are due to all of the robustification that needs to accompany the modernization. Your company or client wants to slowly replace pieces of the ship until it becomes a spaceship, but it also needs to continue to act as a boat right up until the moment you can fly it into space. This way, the passengers and pilots/sailors never need to leave the ship, and it becomes better and greater while they continue to do their work that drives the company’s revenue.

The other option one might consider (Hint: It’s the option they likely need to do) is to keep sailing, and then get into the spaceship when it is done being built. The users go out in their boat as they always do, do work-related things, find out the spaceship is ready, and then they get into the spaceship for takeoff. The boat still works and maybe needs some basic repairs in the meantime, but your business needs are still being met.

Because we are still in metaphor land, it is hard to conceptualize why someone would ever think something like The Spaceship of Theseus could work. So let’s step away from the metaphor a little bit and ask why a team might think that they can do this or more importantly why they think they must do this.

Why a client thinks they NEED to do this

1. Data integrity and the continuation of business needs.

There is an overwhelming assumption when people are considering a new build in a theoretical sense, and it is the perspective that can be summarized by the image below.

A surprisingly common objection to building a new system is that data could be compromised if this new spaceship they are all piling into suffers the same fate as the Challenger. If every client/user piles into this ship that has a catastrophic bug not found during testing, then an entire day’s or week’s worth of work and information could go up in flames. This is typically coupled with the assumption that we plan to set the previous ship on fire as everyone exits the old system. That is a completely reasonable fear if we are committed to the worst transition plan ever devised. To ease the concerns of those who are worried about an imaginary, awful plan, you will need to have a high-level implementation/transition plan to go with the conversation about building an entirely new system.

The general implementation plan is to have a small set of users be the first to use your production-ready software with the expectation that things WILL go wrong. We would all love to write bugless code with the insane expectation that every developer in your organization already knows exactly how their piece will fit into the overarching puzzle, but that is ridiculous. We just need to prepare for the reality that things will definitely go wrong and be prepared to iron out the kinks before everyone migrates to the new system.

Even when the team is ready to move everyone over to the new system after our first client has helped us iron out issues, new folks will still probably move over in a slow transition. Ensuring that our work has scaled properly before throwing a Molotov cocktail at the legacy system will ease any worries that the rush of users onto a new system will not trigger the apocalypse and bring the four horsemen to your client’s doorstep.

2. Maybe your client or team prefers the illusion of progress over progress.

If you asked your client if they prefer the illusion of progress over progress, they would think such a question insane, but the slow march of turning an ancient, wooden ship into a spaceship is a commitment. It is a commitment to a significantly longer timeline, a lot more money, and a very risky assumption.

That risky assumption is that nobody will beat them to the market with better technology. The illusion of progress is that by X month, you may be slightly closer to the spaceship in your iterative enhancement, but you are significantly further behind than if you started the spaceship from scratch. Your stakeholders may have those tangible results in a production environment that they wanted, but by the time you attach the rocket booster to your wooden ship (as seen above), you could have been halfway done with your entire ship.

So while your client/company is sailing around the Frankenstein ship, someone with a complete spaceship could be going around gobbling up all of your potential and/or current clients. By the time the team has completed the transition it could be too little, too late, and way too expensive. So why would they still be committed to this illusion of progress? Because it is the illusion of a commitment to Agile.

2.1 The Illusion of a commitment to Agile

When we talk about Agile we are typically talking about iterative development. A bunch of executives would want to see iterative progress, and a team might view that requirement as needing to do something like the Spaceship of Theseus where they see the current systems receiving iterative improvements and slowly becoming better. Agile does not mean that we are constantly pushing new features to production for the world to see. When someone starts a major piece of software, they don’t then invite the public to see how someone can choose a username and set a password. There is typically a large build process before anything sees the light of day outside the internal testers and stakeholders. Agile is the way we manage work, but it does not necessitate the pushing of code into production. What it does necessitate is a constant feedback loop. Your team writes code, reviews the end product of that code, and makes course corrections along the way. You may be defining what the end product is ahead of time, but you are also in a constant state of being able to show the results of your work. If you don’t release software to the public, it does not mean you are failing at agile. It just means that what you are building cannot necessarily be released to end-users in bits and pieces, especially if the plan is to replace a behemoth, and super especially if iterative production pushes are going to slow you way down in the long run.

On the other hand, building an entirely new system for people to eventually transition to feels very waterfall. It doesn’t need to be. Just because you are building an entirely new thing before it goes to the end-users does not mean you are committing to a non-agile methodology that ends with you handing someone a CD for installation. It just means your code isn’t immediately available. So how do you show progress on a major project that they won’t be able to use for a long while? Show them what you’ve built so that you can get into that constant feedback loop!

Members of Leadership need to get some “oooohs” and “aahhhs” at a pretty regular interval to be sure that the money they’re throwing at you is actually being spent well. It is difficult to wait N years for new software when they could see a marginal improvement to their current, ancient ship in a few months, but forcing iterative improvement right now is just short-sighted. Making the executives and other stakeholders feel like they are part of the journey is as important as the journey itself to ensure that it does not get canceled from under you leaving you with a half-finished spaceship that you are expected to glue to your ancient, wooden ship.

Conclusion

There is a good chance that your client or team will have more objections to a new build that would take them down the route of the Spaceship of Theseus, and your goal will be to cut to the core of the objection to refute what is likely a weak objection. In their efforts to make the Spaceship of Theseus many scrappier folks have eclipsed major companies or made them entirely irrelevant, and you must be their lighthouse in the dark to prevent such an occurrence. Also, the Spaceship of Theseus is not a common occurrence, but you are all but guaranteed to see it more than once in your career. When companies want to update a few modules or make a major update to their infrastructure, it does not necessarily mean that they are creating the Spaceship of Theseus. It may just mean that they are keeping up with the times and taking their Spaceship from 1.0 to 2.0. The last thing to consider is that not everyone needs a spaceship. Maybe they really just need to go from an ancient, wooden ship to a less ancient, wooden ship. Good luck navigating. Onward and Upward!