|
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.
|
|
|
|
|
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.
|
|
|
|
|
I've had a few days where I thought of just walking away... 
|
|
|
|
|
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 sh*t'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
|
|
|
|
|
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... 
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.
|
|
|
|
|
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
|
|
|
|
|
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?
|
|
|
|
|
|
Jacquers wrote: We're going live in a few weeks and I suspect there may be some features that will be missing.
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.
|
|
|
|
|
Probably too late for this[^] to be of value.
|
|
|
|
|
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
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
