Legacy Systems Rewrite - Forgotten Knowledge
-
Jacquers wrote:
The list goes on, but it may be the best / worst 1 April joke for the users of the new system.
Booked the whole of April as a holiday, yet?
5teveH wrote:
Booked the whole of April as a holiday, yet?
And here's some vacation suggestions: [5 Extreme Retreats When You Want to Unplug](https://www.entrepreneur.com/article/227020)
Keep Calm and Carry On
-
We will be giving them the minimum functionality they need to function and adding the other bells & whistles later on.
That's what you think... you've probably found the "easy" bits from the old system / source code and implemented them, 90% of which are never used anymore. A client of mine is looking for a replacement for a system I wrote for them 6 years ago (nothing wrong with it, they just want something that isn't dependent on a single freelancer). Rather than tell the new vendor what they need, they've simply directed me to tell the vendor what my system does. Which I've done (mainly via the original functional specs). A few follow-up questions from the new vendor to the client (after they've developed the bulk of the new system) reveals that there are chunks (some quite large ones) that they've written, but actually haven't been used for 3+ years. Replicating legacy systems tends to replicate their shortcomings, and often adds a few more too.
-
That's what you think... you've probably found the "easy" bits from the old system / source code and implemented them, 90% of which are never used anymore. A client of mine is looking for a replacement for a system I wrote for them 6 years ago (nothing wrong with it, they just want something that isn't dependent on a single freelancer). Rather than tell the new vendor what they need, they've simply directed me to tell the vendor what my system does. Which I've done (mainly via the original functional specs). A few follow-up questions from the new vendor to the client (after they've developed the bulk of the new system) reveals that there are chunks (some quite large ones) that they've written, but actually haven't been used for 3+ years. Replicating legacy systems tends to replicate their shortcomings, and often adds a few more too.
"Replicating legacy systems tends to replicate their shortcomings, and often adds a few more too." Very true. Due to time constraints and a lack of understanding the new database is pretty much the same as the old one and the strange company + branch management system as well :doh: It does make data migration a bit easier though :) For the system that you wrote - would that maybe have been an opportunity to sell them the source code?
-
I would be running away as fast as I could. I understand you are looking, but this is just a bomb waiting to go off. Management seriously is sometimes sooo out of touch to their own actual business it just scares the hell out of me. I had this at my last position. I feel for you.
To err is human to really elephant it up you need a computer
rnbergren wrote:
Management seriously is sometimes sooo out of touch to their own actual business it just scares the hell out of me
^but sadly so common to find... :sigh: :sigh: :sigh:
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.
-
"Replicating legacy systems tends to replicate their shortcomings, and often adds a few more too." Very true. Due to time constraints and a lack of understanding the new database is pretty much the same as the old one and the strange company + branch management system as well :doh: It does make data migration a bit easier though :) For the system that you wrote - would that maybe have been an opportunity to sell them the source code?
It might have been - except that the "new" system is actually an existing system being modified to meet the client's needs, because the new vendor is owned by a friend of a friend of the client's boss. So they're bolting on new functionality all over the place. In the meantime, since the "upgrade" is taking so long, I'm busier than ever adding new features to the old system faster than the entire large team is adding them to the new... :doh: In any case, my client owns the IP (including source code) so could have just handed it over anyway.
-
We're in the process of rewriting a legacy system and nobody on the current team knows the details of how a certain feature works. So the managers swallowed their pride and contacted the client who uses it. They are now explaining it to us using our own old system :laugh: We're going live in a few weeks and I suspect there may be some features that will be missing. And that's why documentation for business processes is important ;)
If the system's client is the government / crown, do their "regulations" suffice as documentation? I got to come back some 5 years later when there were new "retro-active" regulations. Nobody else wanted to touch it.
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it. ― Confucian Analects: Rules of Confucius about his food
-
We're in the process of rewriting a legacy system and nobody on the current team knows the details of how a certain feature works. So the managers swallowed their pride and contacted the client who uses it. They are now explaining it to us using our own old system :laugh: We're going live in a few weeks and I suspect there may be some features that will be missing. And that's why documentation for business processes is important ;)
You haven't lived until you've been tasked with replacing a feature where the original developer is no longer with the company, he's no longer alive. Good riddance to bad rubbish, BTW; the guy was an utter douchebag. We're not even certain we have the proper source code for the product we've been delivering for the last several years, and we don't really know how to build it. It's in C, uses makefiles, and an odd configuration of C runtime libraries. We are (or at least I am) totally :elephant:ed.
Software Zen:
delete this; -
We're in the process of rewriting a legacy system and nobody on the current team knows the details of how a certain feature works. So the managers swallowed their pride and contacted the client who uses it. They are now explaining it to us using our own old system :laugh: We're going live in a few weeks and I suspect there may be some features that will be missing. And that's why documentation for business processes is important ;)
There is honor in recognizing that we need help. I am glad that your managers did the right thing.
-
We (devs) have voiced our concerns, but management is going ahead regardless. I understand that it would cost money to keep the old system going for a bit longer, but the consequences if the new system doesn't work as intended are potentially worse. Support calls, lost clients, etc. The BA has resigned, so we'll be getting another fresh one again. And if I find suitable alternative employment I might be gone later in the year as well. I'm surprised the other dev on the project hasn't resigned yet. All that being said, if we manage to get it working then things should improve later in the year.
Regardless of who made the actual call, there will be plenty of blame distributed. Hate to sound so pessimistic, but if it has so many unknowns then it sounds like there are big problems ahead.
"Get it right" is taking a backseat to "Get it done.". Business decisions aren't always right, you can only hope that good enough is good enough. Keep calm.“The show doesn’t go on because it’s ready; it goes on because it’s 11:30.”
― Lorne Michaels
-
We're in the process of rewriting a legacy system and nobody on the current team knows the details of how a certain feature works. So the managers swallowed their pride and contacted the client who uses it. They are now explaining it to us using our own old system :laugh: We're going live in a few weeks and I suspect there may be some features that will be missing. And that's why documentation for business processes is important ;)
There's a difference between rewriting and translating. It sounds like a minor distinction but it is not. If the goal is simply to move from language A to B because A is not supported/secure/etc. anymore, then translate and run with it. From a business process POV however, that is the cheaper solution but also a waste of resources for the client. The PM/SA should have done the required analysis and reviewed the processes with the client. It is expensive but at the end of the day, the client could get an enormous value add rather than a translation. Rewrites need to look beyond the codebase behind the system and utilize current technology to create or improve the client's operation as well. I know there are valid reasons to go from "A" to "B", but personally I wouldn't take it on as I learned several years ago to listen to myself and that often the client/users don't know what's best.
-
We're in the process of rewriting a legacy system and nobody on the current team knows the details of how a certain feature works. So the managers swallowed their pride and contacted the client who uses it. They are now explaining it to us using our own old system :laugh: We're going live in a few weeks and I suspect there may be some features that will be missing. And that's why documentation for business processes is important ;)
Curious to know how you would document such things. Do you use a wiki for anything like that? I use html files with a home built index.
-
We're in the process of rewriting a legacy system and nobody on the current team knows the details of how a certain feature works. So the managers swallowed their pride and contacted the client who uses it. They are now explaining it to us using our own old system :laugh: We're going live in a few weeks and I suspect there may be some features that will be missing. And that's why documentation for business processes is important ;)
More than once in my career, I've had to reverse-engineer a product in order to re-implement it using modern technology. It's pretty embarrassing when it's your own company's product and you're wandering around to all the old-timer trying to collect fragments of documentation, and reverse-engineering your own hardware.
-
We're in the process of rewriting a legacy system and nobody on the current team knows the details of how a certain feature works. So the managers swallowed their pride and contacted the client who uses it. They are now explaining it to us using our own old system :laugh: We're going live in a few weeks and I suspect there may be some features that will be missing. And that's why documentation for business processes is important ;)
Can you write unit tests for the legacy code in the legacy language & framework? If so, translation is possibly the safest solution, not a rewrite. Then write matching unit tests in both languages to make sure you've got all the off by 1 errors, etc. I've been in this exact situation but even the customer didn't know how it worked, "Just make it the same!" Not pretty, not satisfying, but met the customer's schedule and expectations, so still a win? Added unit tests as we learned more from the users to ensure any future refactors/rewrites would have some level of confidence, too.