But, this obviously carries risk, that the new thing you develop won't be worth as much as you spent. Bending Spoons doesn't want risk, hence their decision.
Software may never be finished (in your opinion) but the budget of any customer is finite. If you keep reinvesting your revenue forever into "engineering" the product there's going to be a time where a competitor comes in with a finished product matching your customers' requirements and snatches him from you by both charging less and making a profit.
Just look at Google. They could have stopped writing new software at any point and been just fine. But in the long run they'd have missed out on trillions of dollars.
As with everything in business, it comes down to risk/reward. Not every risk pays off, but some do.
The key is knowing when to stop. Unfortunately permanent employment does not provide an incentive for anyone involved to speak up when they think it's that time.
Okay. Most businesses also fail. Is that a reason for existing ones to stop growing?
Software doesn’t win by being “finished” it wins by out competing other software
And yes, I am making a good case for mature software with those lovely examples. But clearly they wanted more widgets and they kept engineers who can deliver those widgets. This wasn't some unsustainable thing for Youtube as the top comment argues. And that's how most software businesses work as of now. If you remain complacent, you're slowly dying to competition. Because the demand for more still exists.
I'm going on a limb here and saying that the scale that YouTube was running on back in 2010-2015 is not the same scale as now, and if they had left their whole infrastructure unchanged, a "finished product", so to speak, the site would have been feeling dated and would have eventually been killed off.
Adding extra nodes to an existing horizontally-scalable system (that has already been operating and has its bugs ironed out) is much easier.
Bending Spoons buys stalled or failed products and keeps them alive with a central engineering team in Italy which is far cheaper than anything in the US.
That's their business model. If the company you work for is acquired by them you should start looking for a new place.
The reason why software companies grow, is because businesses demands growth.
I suppose you could build a simple, small app and leave it on "maintenance" (even then, it's going to be difficult due to crumbling infra) but real world products don't work that way.
Companies want to scale, add features and expand to various verticals. They also have to compete with other companies , there is regulations, compliance and never ending list of incoming features from sales, marketing and customers.
Elon Musk famously attempted to run Twitter "lean", and look how that ended.
Unless you are able to curb the corporate greed, you will need to grow your engineering team.
There's only so much growth you can achieve in any vertical - the key is to realize when you've hit that limit and cut your losses. Unfortunately as a company employee you have no incentive to do that.
I doubt Vimeo would've sold if there was still lots of growth potential on the table. They've exhausted it, and for various factors were unable to cut costs internally.
Bending Spoons evaluated the situation and determined they can still extract a certain amount of profit by massively cutting costs - they gave chunk of said expected profit to the current owners, and are now implementing said strategy.
> Elon Musk famously attempted to run Twitter "lean", and look how that ended.
The decline of Twitter has all to do with Musk's politics and lack of any kind of strategy of the product (makes sense if you see it as his personal mouthpiece rather than a business). Tech-wise it seems to be working well enough. Cutting 80% of expensive engineering staff for a 1% drop in uptime of a non-critical service with no SLAs is a no-brainer.
This seemed to end pretty well. He overpaid for it, but the website kept functioning without issues.
Not if you find new ways to appeal to them once you have them as users.
The search engine markets is finite, so Alphabet expanded elsewhere
Doch, even then.
Back at university, we had practice sessions about our CVs and job interviews. Mine had a cliché in it, "committed to quality"*. The businessperson who was helping us figure out how to be any good at the jobs market, picked up on it with an example:
Which is higher quality? A Porsche, or a go-kart?
Except no; you didn't consider who the customer was. If this is for a kid who just wants to have some fun, they can't afford a Porsche, they've got no insurance, they don't know how to drive. A go-kart solves their problem, they get to have fun, a Porsche doesn't.
* I was 19 or 20 when I wrote that, it was about as true as when ChatGPT writes the same: I didn't know any better.
You could make this statement about anything. "Building a new hospital wing just because is not a useful way to spend anyone's time", "Adding an extra drive-thru lane just because is not a useful way to spend anyone's time". The point is that it's not "just because", it's because you believe it can grow your revenue.
On the other hand, if you don't believe that, then don't invest. Nobody's saying you have to. If you think my comment is saying that, you've misread it.
You can, but do you really need the same sized team to add an extra lane to a drive-through as you needed to build the entire restaurant's building, kitchens, etc?
Do you need the same sized team to add a new wing to a building as the team that built the existing building(s)?
Any profit bending spoons earns they can run off and invest in another business if they like. They don't bother investing in the businesses they purchase because they believe, like the previous owner believed, that there is no more juice to squeeze from that particular lemon.
And the ones who helped make Vimeo what it is? left out in the cold to fend for themselves.
This is why loyalty is dead. Maybe if this billion dollar aquisition benefitted the workers there'd be less hard feelings, but that's not how capitalism works.
This is such a bizarre mentality to me. When you sell your car, do you send a cut of the money to your mechanic?
Just like with your building analogy and with other car analogies presented here, software does need some maintanence every now and again to keep it up to date - with security fixes, compiling to a newer platform, integrating fixes from dependencies, etc. And yes while buildings may be finished they stil require regular maintance if they are used.
That's not even true with a car. I'm about to spend 3000 dollars on a big repair for a car I bought 9 years ago used @ 3500. Even if you adjust for inflation we're still talking about 70% of the car's worth just to keep it running. As for a refund, the blue book value tops at 850 dollars.
That's one way to run that ROI, sure, but is it correct?
1. The original $3.5k you spent is a sunk cost; you should ignore it, so your total cost of getting a running car is only $3k.
2. Even if you don't ignore it, your total bill to get a running car is $7.5k
In either of the above situations, you should be comparing the cost to get a running car by fixing your existing car (either $3k or $7.5k) to the cost of getting a running car by selling it as-is (so, perhaps +$500 as a parts donor -$X for a replacement running car).
Regardless of which calculus you are using, it's still going to come cheaper to fix the running car.
What the car is "worth" (however you define it) is irrelevant to the calculus.
From the sounds of it I assume you're talking about developing and maintaing a SaaS application, where there is no real maintanence of it, and instead what you end up doing is developing it further to support larger data sets and more people. That is of course assuming that the software is successful and the usage is growing.
For traditional desktop software you can declare it finished and then maintanence is minimal and limited to only critical bugs, so you'd have a team of 5 develop it and then 1 person or less maintain it.
I agree. I never claimed anyone needs to do this.
On the contrary, it absolutely can be, in both directions.
Software can absolutely be "feature complete", and in the case of many products it would have been an improvement to say "we're done now" and switch from developing new features to maintenance-only mode, dealing only with API changes and new laws.
Some examples of where it should be "done" by some point include smart TVs and smart lightbulbs. I'm also old enough to remember the era of games where patches were rare and small, unlike the current experience of having to wait for Steam to install updates almost every day, and only then will allow me to see if the game I want to play and which worked yesterday now has a mandatory update that I also have to wait for (which is less often but still often enough to be annoying).
Even with MacOS, while I absolutely do appreciate all the behind the scenes stuff regarding security and so on, the last time I appreciated what they did with the UI in an update, the version branding scheme was still to name releases after cats.
Even as an iOS developer, although I can see what they're trying to do with SwiftUI, I find it worse than UIKit in basically every regard because the "magic" keeps not working and the "problem" it tried to solve was never (for me) a problem; with concurrency, they went from GCD to Combine which IMO was a step back, before going to async/await.
"Too many features" is also a problem for the developers, as it leads to them duplicating work. For example, the background sounds feature on my phone and the one on my HomePod each has its own list of sounds, they're not just two interfaces to the same underlying app even though the HomePod's OS is a fork of tvOS which is a fork of iOS.
(The other way around, the home I grew up in is now about twice the size it was when my parents bought it around 1970, judging from the Google areal view).
then for live games etc -- release servers maybe after 7 years so people can run their own servers for games
I think we can all agree 7 years is a good enough timeline for games to have milked all the revenue they need.
37Signals still have early versions of Basecamp running
Jetbrains does the same thing with perpetual licenses etc
SAAS does not mean software can't be finished
Unfortunately when the software is done, the product lifetime comes to a close soon after. Everything around the product changes and the software needs to change to keep up. Smart lightbulbs need apps to keep working and you get kicked out of app stores if you don't keep up with never-ending churn Apple and Google imposes on you.
The only way to run older games is to use emulators and other 3rd party effort, that also needs to be continually updated. When you claim that any piece of software is done and completed, you've only externalized the effort required to keep it useful.
I absolutely agree with your pushback against feature creep. That is unfortunately a reflection of internal corporation value system, while the successful open source projects often know where to draw the line.
How does that make it different? More features could always be added to most buildings. You could keep adding rooms onto the side, update the floors/ceilings/walls every year to stay trendy, add a water feature, expand the basement with a tunnel network, etc.