|
OK, I'm suitably impressed...
|
|
|
|
|
Checking your link to see what it does. In things like "Gimp II" it's called an unsharp mask - sharpens only edges. What will they invent next? RGB Pixels ?
Ravings en masse^ |
---|
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein | "If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
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
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: 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!
|
|
|
|