|
Quote: You don't just rewrite 20 years of development.
More than 30, in my case. 
"In testa che avete, Signor di Ceprano?"
-- Rigoletto
|
|
|
|
|
ditto
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
I have no experience with those technologies but have gone through rewrites that succeeded and others that failed, so I wrote an article[^] on the topic.
|
|
|
|
|
Thanks, going to discuss some points with my client.
|
|
|
|
|
Oooohhh... you should put it in The Cloud! 
|
|
|
|
|
I know you're being sarcastic here, but that would absolutely have my preference.
|
|
|
|
|
Based on your experience to develop such a web app from scratch you need to come up with the scope of work, the technology going to be used , the team that will be involved, the skill needed......and the man hours and the project development phases...all that needs to be submitted to the client.Taking that 20 year code and working with that along with all that sql and vb.net ooff
Caveat Emptor.
"Progress doesn't come from early risers – progress is made by lazy men looking for easier ways to do things." Lazarus Long
|
|
|
|
|
How much money and time do you have?
Rewriting or porting an application is normally only 100% successful if it's built in a structured way. Hell know what's awaiting you in a bowl of spaghetti.
I would start with refactoring the existing app into proper logical layers. (Move all sql-queries to a datalayer and all logics to a business layer and clean it up while doing so)
If you feel that this is to hard or to much work, or get to much resistance from the existing developers, you probably already know it will fail.
Otherwise you will have a good starting point for a rewrite.
So as I see it, the choice isn't between refactor OR rewrite. You should do both.
|
|
|
|
|
Before touching anything, you should have done a current logical and physical design analysis ("diagrams"); allowing you to tackle any "rewrites" in an an intelligent manner (priorities); instead of heading off in all directions.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
Just ask the Witch to help you port it to the Teensy and she will rewrite it in a couple of days for you!
If you can't laugh at yourself - ask me and I will do it for you.
|
|
|
|
|
The best quote for deciding on Green-field or Maintenance on Brown-field...
"It is easier to give birth than raise the dead." ~unknown
Build the new one!!! 
|
|
|
|
|
It sounds like you should be able to rewrite it a page at a time.
Bonus:
Have both deployed side by side so you can compare them/use them.
Once they are happy with the new version, delete the old one.
|
|
|
|
|
> but it's beginning to show its age
That is a vague problem description.
What is the real problem?
- performance,
- concurrency,
- GUI (look & feel)
- quality of code,
- no people that know the technology?
- ....
|
|
|
|
|
All of the above.
People know the technology, they just don't want to work with it (including me, to be honest).
|
|
|
|
|
Avoid doing a hard rewrite/relaunch, do a gentle "sunsetting" over time
1 Keep the old application but keep track of how many hits it gets
2 Make a new competing application, also tracking its hits
Then launch them side-by-side, giving the user a choice about which one they want to use, maybe even having cross links to make them able to "jump to the other side". Keep a look at the statistics to see if the new one is gaining or losing. I think you get the basic idea.
Suggested reading: https://medium.com/@herbcaudill/lessons-from-6-software-rewrite-stories-635e4c8f7c22[^]
|
|
|
|
|
It's an internal business application.
No competing or statistics there, just the one or the other.
|
|
|
|
|
You haven't given us any idea how big the system is (in terms of lines of code or whatever). Although, arguably, the bigger it is the more it would make sense to rewrite it rather than having to keep some old, creaking codebase working.
I recently went through my entire C++ codebase replacing a lot of old-fashioned manual memory management with 'modern' C++ idioms. It was a daunting prospect initially but I am sooooooo glad I did it. 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. Just my $0.02
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.
|
|
|
|
|
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?
|
|
|
|
|
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.
|
|
|
|
|
Having been involved in a big ground-up rewrite (painful, everything takes longer than everybody thinks or is willing to stomach) I would tend to favour an incremental refactoring approach.
So (if possible) put the new code in the same site as the old, and start replacing features one by one.
I wouldn't envy the person who has to extract that SQL out of WebForms though!
|
|
|
|
|
others likly given similar response, my basic points
WHY, what does client or end user benefit. Developers are not the user
that said - if want to reduce COSTS (time or money) for adding features, that a good why for client. Changing underlying code to fix "mistakes" (things that have newer ways, or low quality patterns)
Platform compatibility. Main reason had to take a silverlight/lightswitch to HTML.
Security issues
maintenance vs feature add
feature add turn around time
and best for client - features that at the time of request could not, or costly to implement can be scoped in this work of redesign. Some of these features might replace existing features thus not need transfering.
|
|
|
|
|
I've awoken my old account just to chime in on this as I've had some recent, terrible experience here that might help. I'll try to keep my rants to a minimum.
Sadly my last position was working in this tech stack, with over 150 customers using various versions of the product.
- Business logic strewn throughout SQL procs, UI and a little bit of mis-informed backend abstractions coupled with embedded and sitewide javascript.
- No source control, at all
 . - Zero, or inadequate out of date documentation.
- Team works on network shares.
- Manual deployment.
- No IDE or any other tooling (except for SQL Management studio).
- Building was done using cmd scripts split into arbitrary "modules" due to the limitations of the command buffer string length.
- Versioning on live system was mandated - rename the old file with a date, and leave it there.
- Sometime in the past they switched from VB to C# which was the dominant language when I started. The mix led to some awful days where I realised I had to touch the VB, and those days were long, unproductive, usually doomed to fail.
Staff turnover (all senior devs) was 100% for new hires, lasting from 4 months to 1.5 yrs (me, the fool).
10 years of constant losses, mostly negative customer relations with some "entrenched" customers buying out the parent company on more than 2 occasions to keep their critical systems from vaporising led to my current attitude to this type of product.. return to the ship and nuke it from orbit.
Seriously though, I would park it in a vm(s), charge a fortune for anything that needs change management. "Try" to fix any security holes that are essential, but first try to mitigate those within your new virtual infrastructure if you can first. Product is not cost effective, and the customer needs to understand that through passing on that aspect of the business. If cost is not an issue, maybe think about selling it on to an outfit that doesn't mind/understand financial loss, the technical debt or the talent attrition it will cause  .
You mentioned updating the html/css and providing a more modern approach to responsivness. The product I worked with had all that already and still had the above issues. My opinion is that it will not improve your developers lives, nor maintenance timescales, but might reduce the front end developers attrition in the long run. It might also increase the appeal of the application to the customer, making it seem "better". Do you really want that?
Moving to C# might seem like a good plan, but the application and its users would not benefit from a straight conversion. I would plan a rewrite, and maybe a targetted plan for specific use cases only in a new application written on a more modern, and versatile framework. Due to the cost of re-writes (coming from a change management line of business in my old days) I would go to the business and start discussions around re-assessing their requirements in leiu of modernisation.
SVN/git.. meh whatever your team prefers.
|
|
|
|
|
Ouch, sounds painful.
Seriously though, how old was that product, no IDE or tooling, how did they write it in the first place!? 
No source control!? Were these even developers? Did they have any sort of training at all? 
The more I read this thread the more convinced I am doing a straight up rewrite is not the way to go.
|
|
|
|
|
Painful was an understatement. Initially I was under pressure to find a job quickly and this paid ok.
Then I tried too hard to fix things, I should have quit an hour in...
Reasons for where they got to imo .. Misled non technical management, a priority on marketing, political division along dev/design lines and an old guard with speed, but no control or experience on their side from the start leading to a protective attitude.
Speed to deliver was the ONLY consideration when I was there. As a result there was no time to fix anything even when experienced devs like me tried to put pressure on. Of course every project was underestimated with the lack of documentation leading to scope creep, overruns and customer disatisfaction from project inception.
Product would have been brand new around 2009, ASP web forms was old even then. Only 1 original dev left, and a contractor that seemed to get work intermittently but never actually work/talk with anyone in the team. The original founder was kept around as a consultant, lol... This guy interviewed me, with the other original dev, and one question they posed was a simple relational data model question. Then when I hit the actual code I found they had no foreign keys defined, only indexes. I raised this in a formal review down the line, and was given a 5/10 grade for my work lol
I'm currently on the bench as a carer, not employed since Covid redundancy so I have too much time to mull over this stuff.
The organisational problems are interesting, and help understand the "how the F..." but from your response I am sure you don't have to worry about this junk. The tech stack is old and knackered and, imo, not really the platform I would have used even back in the 90's.
One note of caution - watch out for use of the "viewstate". Check any page in your browser with form controls (or not sometimes) and look for a massive utf8 encoded field(s). Depending on if this is a public website or not, and your customers level of security paranoia, you might want to look into getting an upgrade to a later version of the .net framework at a minimum (4.8) and ensure you turn on the relevant secure features (machine id and encryption I believe are the keywords there).
|
|
|
|
|
One very good and not-going-to-flip-the-canoe improvement might be Flyway.
The learning curve to some very basic "make sure my database state is what I think it should be" is not at all steep, but there are also some nice to haves if you dig deeper.
You essentially version control your DDL/DML into numbered scripts which it then facilitates applying to a given database by checking to see what was the most recent one applied and applying anything newer. A nifty option (that you have to also create if you want) are undo scripts correlated to the "do" scripts that allow you to rollback the change made by the "do".
This marries into build/release pipelines in easy and good ways.
For an Azure DevOps build pipe, you might first have a commandline step "clean my database and start over so nothing is funky from a previous mistake or someone mucking around because it is the build box".
In both build and release ADO pipes it is another commandline step added to flyway migrate the db. You could deploy and run the flyway scripts and flyway infrastructure required to run them (a bunch of java) from the artifact project folders being deployed if you wanted to.
Typically, we don't do that, opting instead to deploy and run the migrations from a totally different environment. We do this partially because there would be multiple service hosts in a deployment group and you only need migrations to run once. While it's not a huge bunch of more binaries/data to throw out there, on all but one machine it would generally exist for very little reason.
"LINQ queries are a pain in VB!"
I'd forgotten that particular horror, thanks.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
