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.
back
What's keeping businesses from rebuilding & fixing their apps?
1 comments
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