|
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
|
|
|
|
|
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
|
|
|
|
|
There definitely will be. The legacy system has been in use for 10+ years and very customized for certain clients / cases.
|
|
|
|
|
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. 
|
|
|
|
|
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.
|
|
|
|
|
"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  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...
In any case, my client owns the IP (including source code) so could have just handed it over anyway.
|
|
|
|
|
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?
 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!
|
|
|
|
|
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...
|
|
|
|
|
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.
|
|
|
|
|
That sounds rough!
Someday the next couple of devs will probably have to rewrite this project I'm on and be scratching their heads
|
|
|
|
|
Come on be honest, you've only removed about every seventh line break 
modified 5-Apr-21 21:01pm.
|
|
|
|
|
OK, you caught us! 
- I would love to change the world, but they won’t give me the source code.
|
|
|
|
|
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
|
|
|
|
|
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 | [mastadon]](https://codeproject.freetls.fastly.net/script/Forums/Images/elephant.gif) ed.
Software Zen: delete this;
|
|
|
|
|
There is honor in recognizing that we need help. I am glad that your managers did the right thing.
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
Unstoppable flow through large bodies heard (12)
------------
Not solved by 13:15... answer is
unstoppable flow = INCONTINENCE
through large bodies = in continents
heard = homophone indicator
I'm up again tomorrow, then...
modified 11-Mar-21 8:18am.
|
|
|
|
|
And you called my clue annoying ! 
"I didn't mention the bats - he'd see them soon enough" - Hunter S Thompson - RIP
|
|
|
|
|
|
|
He's anal like that 
"I didn't mention the bats - he'd see them soon enough" - Hunter S Thompson - RIP
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
