Legacy Systems Rewrite - Forgotten Knowledge
-
Jacquers wrote:
So the managers swallowed their pride and contacted the client who uses it.
Then it really has to be a huge topic... that doesn't happen every day. What surprises me, is that they didn't delegate it in some of you that can later be blamed.
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.
Yes, it's a very important feature / process for that client. We have the source code, but trying to make sense of it would be another mission on it's own and time is running out. Due to internal bureaucracy, policies and mostly costing a lot of money to host, the old system is being switched off at the end of the month and we have no choice but to have the new system ready. This whole project has been difficult to say the least. A new Business Analyst who is very inexperienced and doesn't know the old system 'specced' the new system. The list goes on, but it may be the best / worst 1 April joke for the users of the new system.
-
Yes, it's a very important feature / process for that client. We have the source code, but trying to make sense of it would be another mission on it's own and time is running out. Due to internal bureaucracy, policies and mostly costing a lot of money to host, the old system is being switched off at the end of the month and we have no choice but to have the new system ready. This whole project has been difficult to say the least. A new Business Analyst who is very inexperienced and doesn't know the old system 'specced' the new system. The list goes on, but it may be the best / worst 1 April joke for the users of the new system.
:omg: I can't see this ending well for anyone involved in the project, including the client.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
-
:omg: I can't see this ending well for anyone involved in the project, including the client.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
-
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 ;)
Jacquers wrote:
We're going live in a few weeks and I suspect there may be some features that will be missing.
:laugh: You have to love these kinds of scenarios (no you don't). We went live this week on one of our sites with the understanding that a lot of it has not been finished, and some of it may be a tad buggy. Client of course understands, as they demanded the early go live.
-
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 ;)
Probably too late for this[^] to be of value.
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing. -
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 ;)
At least having documentation that generally describes a process, along with some visio flow charts. Very important. And then there's in-code comments that describe what the code does - and why.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013 -
:omg: I can't see this ending well for anyone involved in the project, including the client.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
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.
-
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 ;)
Hopefully there are no hidden gems, that only activates under certain circumstances - otherwise the joke will be on you...
"The only place where Success comes before Work is in the dictionary." Vidal Sassoon, 1928 - 2012
-
Hopefully there are no hidden gems, that only activates under certain circumstances - otherwise the joke will be on you...
"The only place where Success comes before Work is in the dictionary." Vidal Sassoon, 1928 - 2012
I started a joke Which started the whole world crying
-
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 ;)
Jacquers wrote:
We're going live in a few weeks and I suspect there may be some features that will be missing.
So, you're agile. :sigh:
Wrong is evil and must be defeated. - Jeff Ello
-
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 ;)
I've been at 2 sites where we had executables but no source code. At least you have source code which might be traced. I recently dealt with more-or-less the opposite. Too much code. The former developer was fond of backing things up, and backing up the backups. This is a REALLY good practice, right? :laugh: I found 156 (this is not an exaggeration) copies of the project in a folder hierarchy many levels deep. There was a lot of parallel copies, so I couldn't assume that projects higher in the folder structure were more current. The process appeared to be: make folder in project, copy backup there. Repeat several times. Make backup of entire folder hierarchy, including nested backup folders. Repeat this many times. The project was in revision control ... but it wasn't a current version. This mess was 15 GB on a network drive. I have no idea why operations did not flag the space usage for questioning. It took 3 weeks, but I narrowed it down to what I believe was the most current code, based upon the files that changed the most often. I have 5 distinct copies of the project, in case we later determine that one or more of the files is more current in one of the other projects. To make this more entertaining, the project I had to parse is one of nearly 2 dozen ... so eventually this mess will need to be cleaned another 2 dozen times ... but not by me!
-
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.
We've been "transitioning" to the cloud since the end of October of last year, and shit's still broken. And for the very same reasons.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013 -
Yes, it's a very important feature / process for that client. We have the source code, but trying to make sense of it would be another mission on it's own and time is running out. Due to internal bureaucracy, policies and mostly costing a lot of money to host, the old system is being switched off at the end of the month and we have no choice but to have the new system ready. This whole project has been difficult to say the least. A new Business Analyst who is very inexperienced and doesn't know the old system 'specced' the new system. The list goes on, but it may be the best / worst 1 April joke for the users of the new system.
-
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.
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
-
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 ;)
Oh Been there done that! Got the bl*** T shirt, the worst thing is trying to figure out how it works (why is there a define called fudgeFactor that is 1, when its changed the system dies!) So tempting to repackage the exe as a DLL that is called from the new code...
-
Hopefully there are no hidden gems, that only activates under certain circumstances - otherwise the joke will be on you...
"The only place where Success comes before Work is in the dictionary." Vidal Sassoon, 1928 - 2012
-
Jacquers wrote:
We're going live in a few weeks and I suspect there may be some features that will be missing.
So, you're agile. :sigh:
Wrong is evil and must be defeated. - Jeff Ello
-
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 ;)
I came into a project where the last remaining programmer had quit. We had the source code - just one copy on his old machine, no backups. There were some occasional errors which at first appeared to be multi-threading issues, overwriting shared data without locks, that sort of thing. It was a network DLL, just part of the whole product - but essential. I and another developer went through this code trying to find the error(s). After a while we coined a phrase which we both had uttered several times, "How did this ever work?" After a longer while we realized it couldn't. The source code had been updated several times after the last release - presumably trying to fix these errors. Massive amount of cut and paste (this was effectively before the internet) meant multiple copies of code in multiple methods all for slightly different functions - some of which were never even called. There was no copy of code that had actually been released in the last version - he had just ploughed on, editing the one and only copy of the code! We ended up rewriting the whole thing from functional needs (no documentation, I had been brought in because I had used the product extensively at my previous job and had been "poached" to work for the product vendor). I spent a few days writing the specifications based on my memory of what worked and what didn't and how I thought it should have worked. When we finished it all worked and was about 9,000 lines of carefully constructed code. the code we started with was over 60,000 lines of code, mostly repeated. Phew!
- I would love to change the world, but they won’t give me the source code.
-
I came into a project where the last remaining programmer had quit. We had the source code - just one copy on his old machine, no backups. There were some occasional errors which at first appeared to be multi-threading issues, overwriting shared data without locks, that sort of thing. It was a network DLL, just part of the whole product - but essential. I and another developer went through this code trying to find the error(s). After a while we coined a phrase which we both had uttered several times, "How did this ever work?" After a longer while we realized it couldn't. The source code had been updated several times after the last release - presumably trying to fix these errors. Massive amount of cut and paste (this was effectively before the internet) meant multiple copies of code in multiple methods all for slightly different functions - some of which were never even called. There was no copy of code that had actually been released in the last version - he had just ploughed on, editing the one and only copy of the code! We ended up rewriting the whole thing from functional needs (no documentation, I had been brought in because I had used the product extensively at my previous job and had been "poached" to work for the product vendor). I spent a few days writing the specifications based on my memory of what worked and what didn't and how I thought it should have worked. When we finished it all worked and was about 9,000 lines of carefully constructed code. the code we started with was over 60,000 lines of code, mostly repeated. Phew!
- I would love to change the world, but they won’t give me the source code.
-
I came into a project where the last remaining programmer had quit. We had the source code - just one copy on his old machine, no backups. There were some occasional errors which at first appeared to be multi-threading issues, overwriting shared data without locks, that sort of thing. It was a network DLL, just part of the whole product - but essential. I and another developer went through this code trying to find the error(s). After a while we coined a phrase which we both had uttered several times, "How did this ever work?" After a longer while we realized it couldn't. The source code had been updated several times after the last release - presumably trying to fix these errors. Massive amount of cut and paste (this was effectively before the internet) meant multiple copies of code in multiple methods all for slightly different functions - some of which were never even called. There was no copy of code that had actually been released in the last version - he had just ploughed on, editing the one and only copy of the code! We ended up rewriting the whole thing from functional needs (no documentation, I had been brought in because I had used the product extensively at my previous job and had been "poached" to work for the product vendor). I spent a few days writing the specifications based on my memory of what worked and what didn't and how I thought it should have worked. When we finished it all worked and was about 9,000 lines of carefully constructed code. the code we started with was over 60,000 lines of code, mostly repeated. Phew!
- I would love to change the world, but they won’t give me the source code.
