We have made the tough decision to sunset the City Guide app on December 15, 2024, with the web version following suit in early 2025.

I loved the OG Foursquare app. Back in the early 2010s, it was simply the best way to discover great new places, and the gamification was fun and innovative.

Its demise arguably began in 2014 with “the great unbundling”, aka the split in two separate apps: Foursquare (City Guide) and Swarm.
At the time, unbundling services into multiple app properties was all the rage, and for a company hellbent on taking on Yelp at all costs, it seemed the most natural way forward.

In order to appeal to a broader audience, all the gamified aspects were scrubbed off the main app, and the “check-in” functionality moved to Swarm. At the same time though, they removed most of the gamification (global mayorships, friends leaderboard, etc.) from Swarm too, further alienating their existing user base. Swarm was then supposed to be just another location sharing app for friends (to help us making plans together), a concept that has failed so many times I lost count.

Eventually, Swarm reintroduced global mayorships and the friends leaderboard a few years later, but it was too little too late, as most users already moved on at that point. What about Foursquare City Guide? Well, it has been in a zombie state for a while, with most of the user generated content being nearly a decade old now.

Swarm will still be there for the fools like me that still use it to check-in and keep track of new places, partly due to inertia and partly for lack of a (much) better alternative. As teased in the announcement, it might even be updated with some functionality from City Guide (a mini-rebundling?), but honestly I would not expect much more than maintenance and small quality of life updates.

Foursquare (the company) now only exists to monetize location data and analytics largely coming from usage of their API/SDKs.
Ironically, if they fully pivoted to the current business model sooner and left the core Foursquare UX untouched, instead of chasing the Yelp windmills (how are they doing now, btw?), Foursquare might still have a thriving social network, and with it, much more/better data to mine.

Modern cars work, let’s say for the sake of argument, at 98% of what’s physically possible with the current engine design. Modern buildings use just enough material to fulfill their function and stay safe under the given conditions. All planes converged to the optimal size/form/load and basically look the same. Only in software, it’s fine if a program runs at 1% or even 0.01% of the possible performance. Everybody just seems to be ok with it. People are often even proud about how much inefficient it is, as in “why should we worry, computers are fast enough”:

Software engineering shifted from craftsmanship to being an industrial process without learning any lesson from other… industries.

Now it’s easy to hate on Electron’s inefficiency or blame overengineering becoming standard practice in “modern” software development, but if we really want to tackle the issue, we should focus on changing the perception of the underlying economics that push businesses to accept the tradeoffs between performances and the ability to ship products faster. Nothing comes for free, and today’s competitive advantage is tomorrow’s technical debt.

It’s totally acceptable to build products that are “good enough”, but we should never stop challenging how good is good enough.

My recommendation is to go for replaceability instead of re-use. Replaceability leads in the right direction: you think about how to separate responsibilities in order to make them replaceable, which gives you loose coupling. You think about separating clients from the implementation in order to keep it replaceable, which gives you client-driven APIs.

And, if you might realize after a while, that a component tends to be used several times, you go the extra mile to make it really re-usable in terms of additional testing, documentation and hardening. Therefore I would like to add one more line to the learnings: strive for replaceability, not re-use. It will lead you the right way.

Premature abstraction really is the worst type of evil in engineering, as well as in any other design discipline.