When I worked at arXiv we had a math professor on the advisory board who couldn't believe it took us months to roll out upgrades, like he thought he could code up a site like arXiv in a weekend. And he could, except it wouldn't do all the invisible things that the legacy system does.
Remember the goal here is not "make a demo for a site that looks like Fandango" but would be "make something that's truly better in terms of fit and finish and details and that can be proven better in terms of customer success and engagement metrics". AI might help with that, but it's not going to be something an intern can do in two weeks.
Now I wanted to say "it makes it hard that they have to integrate with external systems such as the partner theaters" but actually I think the API economy has offered a way out of enterprise software complexity, see
but I think most people don't see it that way. Like my belief is that the main difficulty in the API economy is that 20% of API vendors just don't care how hard the client auth experience is, in fact they have an ideology that the best possible life is
yes strangler fig is more or less what I'm alluding to . Log all of the business behavior, reimplement it, canary the new version, sunset the old.
I agree that Fandango is much more complicated than the customer experience, but an entire rewrite is definitely doable within a $2m scope (I would forecast closer to $500k).
Wouldn't you spend $2m today to make $10m more in 6-12 months, and spend $5m less on operations (fewer devs, fewer servers)?
> The rebuild cost would recoup in a couple months.
This is pretty optimistic. In reality, when money or critical systems are involved they'd want to thoroughly vet the new work and that'll take a lot more than two months.
Can you explain your $1-2 million figure and your handful of developers finishing it in 1-2 months? What's the timeline for this Fandango rewrite look like in your mind in more specific terms than just 1-2 months. What do you think can be done and how do the costs break down on a week-by-week basis over, say, 10 weeks (high side of 2 months)? We can handwave and assume a few things about the system since none of us are involved in Fandango, but many of us have worked on large scale systems. Use a system you're more familiar with if you prefer but that's of comparable scale.
You're the one making the claim, demonstrate that it's not overly optimistic like the rest of us seem to think.
that doesn't help the conversation. It's easily less than 10% of their revenue, and there's likely more than 10-15% of revenue on the table. Nearly every business will consider that formula.
What's your opinion? do you think it would be significantly more expensive?
What's keeping businesses from rebuilding & fixing their apps?
I can only speak from my past experiences with B2B. We had many B2B customers running ancient applications that would connect to us and transfer incredibly sensitive data. Getting them to update even a single application was not an option. The application may have been running for decades. The people that wrote it may be deceased or retired. Nobody knows what to do if it breaks so they dare not touch it, stare at it, taunt it or talk about it. It just works and nobody wants to create the crap-storm of creating something new that does not cover all the edge cases as a day of down-time could be millions or billions of dollars lost. Nobody want to be the one that caused that history making moment. Adding to this the application may be reaching out to dozens or hundreds of companies, government agencies, etc... and each organization expects it to work a specific way, yet there is no detailed architectural documents that would allow someone to flawlessly make a new application. Flawless is the key word. If a new thing is not flawless it will be immediately backed out and never spoken of again.
I can see this , but we do have migration strategies to reduce this risk. During development the business requirements (embodied by the logs and running state) can get the app close to perfect. and during migration canary'ing the traffic to the new stack until things are perfect.
I know the migration cost isn't zero, but neither are the operations costs of the legacy software, or the losses from bugs and lossy software. and now the migration costs are very low
Everything you are saying makes perfect sense, but that just isn't how big businesses work. Nobody wants their head on that chopping block so the only way that happens is if all the external parties are demanding it because of some regulatory changes that require the application be replaced and even then there will be meetings upon meetings upon meetings and even then they will stall to see if someone can find a clever work around that meets the new requirements. If all the external parties agree to the risks (they won't) and agree to the potential downtime(s) then the new code may move forward. These are incredibly rare events. I've seen a few of these in my lifetime and I am currently retired. Just to get SSLv2 deprecated in most of the customers took a very long time and very delicate hand holding every step of the way. Some customers just couldn't upgrade so they were assigned a special load balancer IP and strict firewall rules just for their companies. Most old crusty applications die with the company assuming it is not taken over in bankruptcy in which case some new people get to deal with it.
I do not really have anything more to add. It sounds like this topic is something you are passionate about and maybe you will find a company that is looking to update or replace some old crusty code. I wish you the best of luck in this endeavor.
I was inadvertently logged out many times, my CC needed re-inserted many times, there are way too many screens to complete the purchase. I only frequent a couple theaters and they show me irrelevant theaters. I could go on. they were begging me to abandon my cart.
Every click is a lost customer. I could find them $10m in added revenue in 30 minutes.
Rebuilding and fixing their apps costs money and may not have a positive ROI. They will not "recoup the build cost" if it doesn't meaningfully change downstream user behavior.
but the cost is pretty low. the entire fandango stack with a few guys and a month or two so we are talking $500k-$1m on ~$100m of annual revenue (< 1% ) .
I could find $1m of lost revenue on their site in 30 minutes
Because they are not software businesses, so they treat it like furniture. If it looks like a furniture and it's right there, then what are you even asking, it's right there I can even see it
It's not taking a side, it's based in direct experience and observation. Has anyone actually used any of these "reimplementations" besides the people who created them (typically agi pilled)
Why is it even valuable to fix that which is not broken? If you observe, those doing so are generating slop with Ai that is broken. Note, I'm not anti-ai, I'm for reasonable Ai, which includes understanding limitations instead of signing onto the hype bus
So it sounds like your position is that AI is not yet generating high fidelity solutions at a cost that would make reimplementation compelling. That's an okay position to have. That's what I would call, your side. I prefer hearing that to just a criticism of my side. thanks
When I worked at arXiv we had a math professor on the advisory board who couldn't believe it took us months to roll out upgrades, like he thought he could code up a site like arXiv in a weekend. And he could, except it wouldn't do all the invisible things that the legacy system does.
Remember the goal here is not "make a demo for a site that looks like Fandango" but would be "make something that's truly better in terms of fit and finish and details and that can be proven better in terms of customer success and engagement metrics". AI might help with that, but it's not going to be something an intern can do in two weeks.
Now I wanted to say "it makes it hard that they have to integrate with external systems such as the partner theaters" but actually I think the API economy has offered a way out of enterprise software complexity, see
https://en.wikipedia.org/wiki/Strangler_fig_pattern
but I think most people don't see it that way. Like my belief is that the main difficulty in the API economy is that 20% of API vendors just don't care how hard the client auth experience is, in fact they have an ideology that the best possible life is
https://www.youtube.com/watch?v=o2ObCoCm61s
but boy have vendors like Zapier really intimidated management into giving up 20 lines of simple Python for a "can't get here from there" nightmare.
yes strangler fig is more or less what I'm alluding to . Log all of the business behavior, reimplement it, canary the new version, sunset the old.
I agree that Fandango is much more complicated than the customer experience, but an entire rewrite is definitely doable within a $2m scope (I would forecast closer to $500k).
Wouldn't you spend $2m today to make $10m more in 6-12 months, and spend $5m less on operations (fewer devs, fewer servers)?
> The rebuild cost would recoup in a couple months.
This is pretty optimistic. In reality, when money or critical systems are involved they'd want to thoroughly vet the new work and that'll take a lot more than two months.
I mean at $100m in revenue, the $1-$2m in migration cost to the new system would be recouped very quickly (1-2% of revenue)
Can you explain your $1-2 million figure and your handful of developers finishing it in 1-2 months? What's the timeline for this Fandango rewrite look like in your mind in more specific terms than just 1-2 months. What do you think can be done and how do the costs break down on a week-by-week basis over, say, 10 weeks (high side of 2 months)? We can handwave and assume a few things about the system since none of us are involved in Fandango, but many of us have worked on large scale systems. Use a system you're more familiar with if you prefer but that's of comparable scale.
You're the one making the claim, demonstrate that it's not overly optimistic like the rest of us seem to think.
that doesn't help the conversation. It's easily less than 10% of their revenue, and there's likely more than 10-15% of revenue on the table. Nearly every business will consider that formula.
What's your opinion? do you think it would be significantly more expensive?
What's keeping businesses from rebuilding & fixing their apps?
I can only speak from my past experiences with B2B. We had many B2B customers running ancient applications that would connect to us and transfer incredibly sensitive data. Getting them to update even a single application was not an option. The application may have been running for decades. The people that wrote it may be deceased or retired. Nobody knows what to do if it breaks so they dare not touch it, stare at it, taunt it or talk about it. It just works and nobody wants to create the crap-storm of creating something new that does not cover all the edge cases as a day of down-time could be millions or billions of dollars lost. Nobody want to be the one that caused that history making moment. Adding to this the application may be reaching out to dozens or hundreds of companies, government agencies, etc... and each organization expects it to work a specific way, yet there is no detailed architectural documents that would allow someone to flawlessly make a new application. Flawless is the key word. If a new thing is not flawless it will be immediately backed out and never spoken of again.
I can see this , but we do have migration strategies to reduce this risk. During development the business requirements (embodied by the logs and running state) can get the app close to perfect. and during migration canary'ing the traffic to the new stack until things are perfect.
I know the migration cost isn't zero, but neither are the operations costs of the legacy software, or the losses from bugs and lossy software. and now the migration costs are very low
Everything you are saying makes perfect sense, but that just isn't how big businesses work. Nobody wants their head on that chopping block so the only way that happens is if all the external parties are demanding it because of some regulatory changes that require the application be replaced and even then there will be meetings upon meetings upon meetings and even then they will stall to see if someone can find a clever work around that meets the new requirements. If all the external parties agree to the risks (they won't) and agree to the potential downtime(s) then the new code may move forward. These are incredibly rare events. I've seen a few of these in my lifetime and I am currently retired. Just to get SSLv2 deprecated in most of the customers took a very long time and very delicate hand holding every step of the way. Some customers just couldn't upgrade so they were assigned a special load balancer IP and strict firewall rules just for their companies. Most old crusty applications die with the company assuming it is not taken over in bankruptcy in which case some new people get to deal with it.
i agree this is a barrier, especially with charity projects -- those that don't have a clear short term revenue opportunity.
But many of these apps have loads of money on the table. Reduced operations & labor costs, increased revenue opportunity.
I'm more curious about the latter.
I do not really have anything more to add. It sounds like this topic is something you are passionate about and maybe you will find a company that is looking to update or replace some old crusty code. I wish you the best of luck in this endeavor.
Sounds good thanks for contributing. I agree with your points on where the reluctance is coming from, and that it’s an opportunity
"ticketing and checkout experience is buggy & leaking tons of money"
Care to elaborate? How much money? I'm intrigued.
I was inadvertently logged out many times, my CC needed re-inserted many times, there are way too many screens to complete the purchase. I only frequent a couple theaters and they show me irrelevant theaters. I could go on. they were begging me to abandon my cart.
Every click is a lost customer. I could find them $10m in added revenue in 30 minutes.
Rebuilding and fixing their apps costs money and may not have a positive ROI. They will not "recoup the build cost" if it doesn't meaningfully change downstream user behavior.
but the cost is pretty low. the entire fandango stack with a few guys and a month or two so we are talking $500k-$1m on ~$100m of annual revenue (< 1% ) .
I could find $1m of lost revenue on their site in 30 minutes
> businesses
Because they are not software businesses, so they treat it like furniture. If it looks like a furniture and it's right there, then what are you even asking, it's right there I can even see it
You had me in the first half I’m not going to lie.
> Now that apps can easily be re-implemented
Is this actually true? I don't believe it to be generally true
maybe not universally, but broadly . could you state your position?
The "noteable" cases you think as evidence that it is easy are misleading. It is not easy or broadly true
I appreciate you taking a side
It's not taking a side, it's based in direct experience and observation. Has anyone actually used any of these "reimplementations" besides the people who created them (typically agi pilled)
Why is it even valuable to fix that which is not broken? If you observe, those doing so are generating slop with Ai that is broken. Note, I'm not anti-ai, I'm for reasonable Ai, which includes understanding limitations instead of signing onto the hype bus
So it sounds like your position is that AI is not yet generating high fidelity solutions at a cost that would make reimplementation compelling. That's an okay position to have. That's what I would call, your side. I prefer hearing that to just a criticism of my side. thanks
> AI is not yet generating high fidelity solutions
full stop, Ai is not as good as you believe it to be, look beyond the curtain
It's not a side, it's reality, unless you believe there are multiple realities, which is plausible given today's media environment
There are hundreds of models and thousands of tools so this is about the most naive and disingenuous assessment imaginable
[flagged]
[flagged]