A Vine mess: The choice between rebooting and reviving old software

In October 2022, after completing the acquisition of Twitter, Elon Musk asked his team to work toward bringing Vine back to market. The team is likely now asking themselves if they should try to revive the old codebase or start from scratch.

Are the problems Vine is facing even technical in nature, or does it have to do with the core business model?

I have no actual knowledge of the Vine tech stack, but these questions (as we’ll see) have been a constant in the industry for well over 20 years. This article uses my own experience working on high-throughput B2B and B2C stacks during a similar time period that Vine was around, and I’m making some assumptions.

Whether I’m correct or not, the broader considerations will apply to anyone facing such a decision right now.

The trouble with Vine

The trouble facing Vine has nothing to do with its tech. It’s likely that the team at Twitter could define and ship a perfectly designed app and not even make a dent in TikTok’s market share.

The conversation they should be having is more about business than technology. When Vine launched in 2012, TikTok was still five years away, and Vine never figured out how to monetize its platform successfully in a way that took care of the top creators and influencers. It might be ambitious to think that you can go from zero to a world-class social media site in a matter of months.

Whether the team chooses to reboot or revive Vine, they must answer questions about sustaining a business in the world the app abandoned in 2016.

For Vine, this is a business decision, but it’s being treated like it’s a technical decision. By choosing to reboot from scratch, you’re letting software developers decide your business strategy, and that approach risks losing the market.

With that in mind, let’s simplify this a bit: Companies face such questions pretty frequently, so what are the non-business considerations that should be factored in?

Revive or reboot?

Let’s pretend that Musk and his team have solved the business problems or at least become comfortable enough with their ideas that they’ve tasked you with the choice: Revive or reboot? How do you proceed?

I’m indebted to Joel Spolsky for his April 2000 article on the subject. A lot has changed since the time that blog was written: The world was pre-agile, pre-cloud, and pre-continuous-integration. Vine itself is probably showing its age as well. It launched in 2012, which means it was likely using REST APIs, which means it was pre-container, pre-gRPC and pre-Kafka. If they did data streaming at all, it was likely built in-house. Some former Vine engineers have already said it needs to be rewritten.

But Spolsky’s points remain as salient today as when Bill Clinton was president:

• The market will not pause and wait for you to get it right.
• It’s bold to think you’ll do everything perfectly (or even better) this time around.
• The architectural problems with any codebase can be fixed slowly, over time, in a careful and mindful way.
• Migrating a product from monolith to microservices is a great way to modernize a tech stack.
• Microservices are well suited to iterative improvements while minimizing disruption.

A common analogy

Reviving parts of a codebase is like changing a plane’s engine while it’s mid-flight. But the key is that the plane is in flight — it’s moving forward along its path. If you start from scratch, the plane is in the hangar while your competitors continue sailing across the ocean, picking up market share in the space you vacated.

Vine has already spent six years in the hangar. Rebooting will only guarantee that it stays there longer.

When you reboot, you either have a separate team keeping your old product alive and supported — doubling (or tripling) the cost of development — or you put everyone on the reboot, only fixing critical bugs in the old product as needed.

In both cases, you’re wasting time and resources. Musk doesn’t have to worry about keeping the old stack “in flight,” but that’s a rare exception, and he is still losing market share every day.

My own experience with rebooting

I’ve been involved in two “reboot” projects and three “revive” projects.

The reboots were both B2B, at boutique software firms that took an infusion of cash to rewrite the products. The “revive” projects were both B2B and B2C, and kept their cash flow high throughout.

Reboots

The reboot projects were great for learning the fundamentals of programming: how to build scalable software, how to incorporate testing practices and how to manage teams for growth.

They also tanked both companies I worked for. One was acquired for the approximate value of their patent portfolio (pennies on the dollar), and the other continues to languish in a purgatorial game of table tennis between rival private equity firms.

In both cases, the engineering team wasn’t stuck with the consequences of a dying customer base or of being lapped by all competitors. Soon after the product shipped, we all went on to get shiny new jobs based on the sterling work we’d just done.

Revivals

The “revive” projects I’ve been on have been far more difficult, but I wouldn’t say I learned any less. What you learn and how you learn it will be radically different from a reboot project, but it will help you better understand how to troubleshoot, do root-cause analysis and make a system robust. If you’re keen, you’ll also learn a lot about internal politics, consensus building and diplomacy.

Refactoring a critical system to use microservices and cloud architecture while minimizing downtime and keeping customers happy will look dynamite on any résumé. It will show your future employers that you’re versatile, resourceful and patient. I’d argue that those are more important traits for a long-term career than the ability to create a new project from a blank slate.

The inevitable difficulties of reviving

Of course, it will be difficult to take out the old code, dust it off and make it scalable for 2023. It’s going to be easier to write new code than to understand and fix old code.

But the stuff you hate about that old code is exactly what makes it work. The parts that are ugly represent bug fixes not incompetencies. If there’s something in the codebase you don’t like, write a few unit tests, make sure they pass, then make the code look how you want it to before you run the unit tests again. Then add some comments.

This preserves the functionality of the feature and gives you confidence and understanding that it’ll be easier to deal with in the future. It also gives you a feeling of ownership.

However, people like to assume that if there’s something they don’t understand, it’s useless. In reality, it may indicate a fix for an esoteric edge case that was important enough to address (even if it could have been documented better).

Here’s how to face these challenges:

• Write some unit tests, making sure you turn the questionable lines green.
• Write some comments indicating your questions about the code.
• Leave all that there until you (or someone else) need to revisit it.
• If that day never comes, then the code is doing its job superbly.

But what if you just can’t see a way to revive in any reasonable timeline?

Not invented here

There are some advantages to rebooting if you decide that all the previous considerations don’t apply:

• It’s cloud native, scalable and purpose-built for fleet management.
• A reboot utilizes all the best modern software development practices from the beginning: unit testing, accessibility, security and performance can all be locked up.
• There’s a brand new SDLC pipeline, where developers can deploy to production per-commit, using feature flagging and canary builds to limit the blast radius of any issues.
• A/B experimentation and new-user analytics can be utilized from day one, giving you guaranteed signals for conversion lift, engagement and more.

Surely you won’t make any mistakes this time, right?

Everything listed here is months’ worth of work, and nothing listed here has anything to do with your core business. Like it or not, the challenges of the core business will continue to be the hardest piece of the puzzle.

In Vine’s case, its core business code has already been written once. Even if you have to abandon everything else, at least keep those bits of operable code that represent the real engine behind the platform.

Conclusion

Of course, I could be wrong. I’m sure rebooting has been viable in some cases (though none come to mind). I can imagine it working if they take the finest architects from their social, content and infrastructure management divisions and let them draw up the plans, which would then be implemented by a new team.

If it were that easy, though, nothing would stop another company from doing the same thing. That’s how dependent they are on the brand memory of Vine — they assume that throwing together something brand new with the right logo will fix their problems.

I’d wager that the tech is the least of their problems.