|
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.
|
|
|
|
|
I have a similar situation. Code is in classic ASP.
Best approach is to get the rules as they SHOULD BE from the business owners if you can.
If not, at least document the screen level functionality.
When you feel comfortable, create a road map . Take one piece at a time. I would start by identifying what could be converted to a service prioritizing what is re-usable first. (Authentication/Authorization would be a good start)
For ease of maintenance alone, I think a rewrite is in order. The longer the client waits, the larger the risk of something being deprecated in a future release.
|
|
|
|
|
Our company has an enormous monolith that shares a lot of similarities with this situation. While we are currently road mapping a full migration/rewrite, in the mean time we were able to get all our Sql stuff into source control by generating "create/alter" scripts for every procedure, function, view, and table. So while we still have tons of logic in Sql, it is at least source controlled. This might be a helpful first step, regardless of what happens next, since doing so gives you all the logic for those parts in text files.
|
|
|
|
|
Sander,
I think we have agreed on a few things in the past...
First, the "Lack of source control for the DB can be fixed with some extraction tools".
I do this today, and commit them (In production systems this has saved my clients). I automate it to push the changes up nightly from production. And I use the technique in dev, and simply DIFF the the Branches.
Anyways, I would SLOWLY rewrite the code to C# using modern approaches. In the end, I am not sure I would want all the business logic ripped out of the DB (unless they have a goal of replacing that)...
And I would implement things in C# that the VB.NET could call like an API, until you get the chance to replace it with C#...
This way, it is slowly migrating away from stagnant... And I would certainly push to train all the developers to use C# for new features.
There is still a Big Cost here... But it should be easier to absorb.
In the end... It's just code!
|
|
|
|
|
Am in a similar position, but with an app written only about 8 years ago; VB.Net, ASP.Net webforms - but well-structured, multi-layer code, all D/B access via SPs, minimal logic in the SPs. Just trying to find WebForms developers to support going forward is the hard bit. Plenty of people with Webforms experience, but none who want to use it!
I have "cloned" the application for another customer, converting to C# along the way (using online tools to automate). A certain amount of manual review needed but on the whole that was the easy bit. Doing it page-by-page (depending on how your site is configured) may not be possible - mine's setup as a WebSite (not a web application) and I don't think you can mix languages in that environment. Probably best to start with a language swap before then tackling any changes / updates; otherwise you've just got more - and less "mature" code - to convert.
Depending on current structure it might be worth rebuilding one layer at a time - i.e. building a "modern" DAL and moving the SQL well away from the presentation layer. Update the production system at each major milestone rather than leaving it to a big-bang replacement.
As others have said, the biggest hurdle is probably convincing the business of the benefits of all this work. Might be worth identifying any known bug-bears for the users and ensuring those are addressed early on so they are invested in getting the new version implemented. Similarly not bothering with "improvements" that don't deliver value to the users - e.g. no point in responsive pages if all the users are in the office on 24" screens.
Sure you've considered all this and more anyway! Good luck...
|
|
|
|
|
DerekT-P wrote: As others have said, the biggest hurdle is probably convincing the business of the benefits of all this work.
The biggest hurdle by far is doing the actual work 
There are already talks about a rewrite, but I'm not so sure if that's the way to go.
Rebuilding a layer at a time... That's actually good advice.
We need to get that SQL out of the HTML code and create a clear separation.
That would make any future efforts a lot easier!
|
|
|
|
|
In June I retired a desktop/web app originally written in the late 90s, looks like VS97 from the style, but the vendor re-vamped it in every version of VS up through 2010. The last few years have been support hell, both on my side (customer) and for the vendor.
Continued development in a 20+ yo technology that is no longer supported is expensive, and it gets harder and harder to find people capable and willing to work in that technology. Having people retire (or die) and being unable to replace them in a real problem.
Replacing the application is going to hurt at some point, and the longer the customer waits, the more painful it is.
I analyzed what the old system did. Listed all the functions, process flows, etc. This was a 9 month effort of a system with LOTS of intertwined business rules.
Next I reviewed the functionality with the customer, including walking through the existing application, and updated the requirements to reflect fixes and some enhancements.
Finally, I produced a detailed design, then we started building. It was not a smooth process, but we made it happen.
The old application required Internet Explorer (I said it was built in the 90's!), and we got the new application in just before MS officially sunsetted IE. It really helps expedite decision making when there is a hard, immovable deadline.
|
|
|
|
|
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
modified 11-Sep-22 8:50am.
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
So they thought they can write a better story, so payed hundred of millions of dollars to butcher Tolkien's work...
The series is actually a sale of the characters - all of them on the self at the same time...
"Everybody is a genius. But if you judge a fish by its ability to climb a tree, it will live its whole life believing that it is stupid." ― Albert Einstein
|
|
|
|
|
The only surprise about this is that people expected it to be as good as the original.
|
|
|
|
|
I haven't heard a single good comments about Rings of Power, yet it still has a 6.7 on IMDb.
Now 6.7 is not a lot, especially for a series that cost a billion, but from the comments I'd expected something less than 6.
I'd still watch an action movie with a 6.7.
Rotten Tomatoes is on point, as always... A 85% score by critics and 39% score by audience
|
|
|
|
|
There is a huge diversion between critics and fans... 85% vs 39% on rotten tomatoes for example...
It seems that what critics find refreshing (introducing new character, more feminine and so), fans find insulting the the original story...
For one I find it wrong that they re-write the story instead of telling it using their tools...
(I told the same of Peter Jackson's Hobbit, when Jackson find it necessary to introduce mini-stories never was there)
"Everybody is a genius. But if you judge a fish by its ability to climb a tree, it will live its whole life believing that it is stupid." ― Albert Einstein
|
|
|
|
|
Reviews have been disabled at IMDb, likely because Amazon owns it. They first went through and deleted a whole bunch of very low ratings. Curiously, there were no reviews on-line at Amazon the last time I looked. I am getting the impression that public response to this has been largely abysmal.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
|
|
|
|
|
lol.
it's a fun TV show/series adaptation.
nothing more, nothing less.
CI/CD = Continuous Impediment/Continuous Despair
|
|
|
|
|
I would agree with that, if it wasn't a story I grew up with and admired...
It is hard to me to enjoy it this way, but probably for others it is what it is...
"Everybody is a genius. But if you judge a fish by its ability to climb a tree, it will live its whole life believing that it is stupid." ― Albert Einstein
|
|
|
|
|
Most people who watch the Peter Jackson or the Amazon versions will not have read the books, let alone the appendices. Watching gives them the illusion of erudition - they think they know what Tolkien was getting at in his books.
I am one of those who claim that an artist cannot be fully understood in translation, or in a different medium (e.g. film as opposed to print).
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
More than anything, what Tolkien was getting at was Lord Acton's belief that power corrupts, and absolute power corrupts absolutely. In our age of World Improvers and sycophants who believe that everything would be great if they, or their guy, were in charge, this is a theme that will be downplayed as much as possible.
|
|
|
|
|
The press don't appear to have liked it much, either: Amazon's The Rings of Power is a betrayal of Tolkien’s vision | The Spectator[^]
And I have to reluctantly agree: I was looking forward to this, but it's just not worth the time to watch it.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
From what I understand they don't have the rights to the Silmarillion, so they have to make up some different backstories.
Just take it as non-canonical entertainment 
|
|
|
|
|
Rings of power could have been a great title for a Sonic the hedgehog movie
|
|
|
|
|
I've never read the Silmarillion all the way through so I don't know if they are creating new stories using Tolkein's characters or if they are adding their own spin to the book's tales. Whichever, I'm enjoying it so far for what it is. I didn't go into it with high expectations anyway.
I am slightly disappointed that they didn't do some brief intro that covered the book's creation story and how Melkor went bad, some history behind the current story.
If you think 'goto' is evil, try writing an Assembly program without JMP.
|
|
|
|
|
Second.
I twice tried reading it, and never made it to page 200.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
