Rewrite or...?
-
Well, what do you expect after 20 years of development? It's not small, it has a few dozen pages with features such as entering sales orders, purchase orders, importing data from various sources, exporting to various sources, product and client management, stock management... Basically everything a mid-sized organization needs to do business.
Paul Sanders (the other one) wrote:
So, I would say, if you can handle the issues that Sander (quite rightly) raises and have sufficient resources then I would go for it.
If I can handle the issues I raised myself? :laugh:
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
Oh, it was you that started the thread, lol. Sorry, need coffee.
Paul Sanders. If I had more time, I would have written a shorter letter - Blaise Pascal. Some of my best work is in the undo buffer.
-
Ahh, I remember those now. :) I'm curious if you have an approach you are leaning towards to address your question? The more I thought about, the more I think it goes to a client choice question. It's one I've presented to clients several times over the years and have gone the rewrite route many times, including two current ones. Also depends on your time/desire to do a rewrite. You can limit it some by using waterfall approach, but that depends on the client. I have one now that goes beyond agile to a "let's roll with it" mentality, resulting in about 60% of code written with about 25% released. Probably wouldn't be the case on a web app. Though I have a few curves on my current one, those are understood to be at the end of the project.
I think our problem now is that we simply don't have the capacity to rebuild while also keep developing what we have. Also, there are probably two people who know what does what and where to find it. One is a user that uses or used everything in the last twenty years, the other is a developer who built most of it or was somehow involved. It's in their heads though, so it should get out first. So I'm leaning towards a "let's refactor the hell out of this thing first when we touch something" approach.
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
So I have this customer who has this 20 year old web application. It works, it's still actively developed, but it's beginning to show its age (well, I guess it's been doing that for years). It's VB.NET Web Forms updated to the latest .NET Framework, 4.8. It's pretty much what you'd expect of something like that. SQL queries written directly into the HTML (or whatever you call the Web Forms HTML), a lot of roundtrips to the server, and XML web services. Most logic is written in SQL Server views, functions and stored procedures, which don't really have any sort of reliable source control. A lot of programmers wouldn't touch it with a stick. Now there have been discussions over whether or not we should do a rewrite, or in any other way update to something more modern. Maybe we can start by modernizing the generated HTML and CSS to make things more modern, like making the pages responsive. Replacing VB with C# would be a good move to attract developers in the future and to make use of newer language and VS features and we can hopefully do that page by page (for example, LINQ queries are a pain in VB!). Perhaps throw in some build and release pipelines (it's now copy/paste) and replace SVN with Git. I know rewrites are hard, expensive, and probably more often than not don't end well. Have you been in this situation? What did you do? Tips?
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
I've been there many times as it seems I am one of those (un)lucky ones that actually enjoys untangling legacy code messes mysteries. What I usually do, after getting the hang of how to do a release with the current process, is: 1) Automating CI/CD - some things will be broken by refactorings, better be able to build/test/release quickly. Moreover, nowadays Git is a must; 2) Encapsulating all data access queries. Start with the writes, there are less of them and most of the time they can easily be ported to a proper data layer. Bonus points if you can start using a framework like EF6 that still runs on .net Framework - this may mean porting the SPs to code, but as you already mentioned that doubles as "putting them in source control". 3) Try to find the "bundles" of DB reads/writes and pack them into meaningful methods. This will be your business layer. May need to use TransactionScope to build some simple "unit of work" pattern here. Unless you need to use multiple databases this won't require using DTC so no major architectural problems here. 4) When all previous steps are completed, you have a UI shell around a business layer. That will need to be rewritten using your favorite technology. That's going to be less boring :)
Luca The Price of Freedom is Eternal Vigilance. -- Wing Commander IV En Það Besta Sem Guð Hefur Skapað, Er Nýr Dagur. (But the best thing God has created, is a New Day.) -- Sigur Ròs - Viðrar vel til loftárása
-
So I have this customer who has this 20 year old web application. It works, it's still actively developed, but it's beginning to show its age (well, I guess it's been doing that for years). It's VB.NET Web Forms updated to the latest .NET Framework, 4.8. It's pretty much what you'd expect of something like that. SQL queries written directly into the HTML (or whatever you call the Web Forms HTML), a lot of roundtrips to the server, and XML web services. Most logic is written in SQL Server views, functions and stored procedures, which don't really have any sort of reliable source control. A lot of programmers wouldn't touch it with a stick. Now there have been discussions over whether or not we should do a rewrite, or in any other way update to something more modern. Maybe we can start by modernizing the generated HTML and CSS to make things more modern, like making the pages responsive. Replacing VB with C# would be a good move to attract developers in the future and to make use of newer language and VS features and we can hopefully do that page by page (for example, LINQ queries are a pain in VB!). Perhaps throw in some build and release pipelines (it's now copy/paste) and replace SVN with Git. I know rewrites are hard, expensive, and probably more often than not don't end well. Have you been in this situation? What did you do? Tips?
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
I don't think you will find a "silver-bullet-answer". It depends on the application, but mostly it depends on how well will the business that uses the app handle missed implementations. Old apps like that have the habit of getting small hidden gems that we gloss over during rewrite for one reason or another. Then we realize... "Ohhh so that is what that code was for!" If the application allows, i'm partial to the use of [^] If done right, both can coexist, and you can port an old piece into the new code bit by bit. The way it works is, you make a request for a url, if that URL is routed on the new app thats what gets served, if that url is not routed on the new one, YARP will fetch from the old and serve.
-
So I have this customer who has this 20 year old web application. It works, it's still actively developed, but it's beginning to show its age (well, I guess it's been doing that for years). It's VB.NET Web Forms updated to the latest .NET Framework, 4.8. It's pretty much what you'd expect of something like that. SQL queries written directly into the HTML (or whatever you call the Web Forms HTML), a lot of roundtrips to the server, and XML web services. Most logic is written in SQL Server views, functions and stored procedures, which don't really have any sort of reliable source control. A lot of programmers wouldn't touch it with a stick. Now there have been discussions over whether or not we should do a rewrite, or in any other way update to something more modern. Maybe we can start by modernizing the generated HTML and CSS to make things more modern, like making the pages responsive. Replacing VB with C# would be a good move to attract developers in the future and to make use of newer language and VS features and we can hopefully do that page by page (for example, LINQ queries are a pain in VB!). Perhaps throw in some build and release pipelines (it's now copy/paste) and replace SVN with Git. I know rewrites are hard, expensive, and probably more often than not don't end well. Have you been in this situation? What did you do? Tips?
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
I'm going to assume there is a stable user base using the existing application, and although it's tempting to redesign from scratch, it can impact existing users negatively. so keep the existing product in maintenance mode, start a sub team or at least one person to start mapping functionality and building it in a newer .NET 6 using something like server side blazer; it will be a close relative to Web forms to migrate logic over. next step would be to modernize the layouts, if not already there. it's a slow process. my reasoning for this is you can launch the new version and have (almost) no difference to the "feel" of the application. once you know that the new platform is stable and works identical or better than the original version now you can start implementing newer layouts, letting the users grow with your changes. worse case when testing out the new version would be slipping the old one back in place if something major needs fixed.
-
Yeah, but unless you have a very solid plan and strategy that's destined to fail. You don't just rewrite 20 years of development.
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
After clearing that up, we can investigate the query in more detail. To do that, I'll first briefly discuss a piece I penned that was moderately well-read. (and slightly controversial). That article was titled "The Myth of the Software Rewrite" by me.
I presented a fairly specific thesis in this article. I argued that businesses shouldn't rewrite their software because the developers amassed too much technical debt to do so successfully.
