Legacy System Rewrite - The shackles of bad design
-
A lot of the last year, I have been gutting legacy code from our app and rewriting from scratch a stupendous marvel! -- Except -- Due to [legal stuff redacted] we need to handle the legacy data structure. This means at the back all the bd data needed to be preserved and it restrained the new functionality. I have ticket to add back in some intentionally omitted elephantine functionality. You cannot believe the joy I had in closing it with a comment of "Not going to happen! We've removed it as it should never have been there, there is a better and EASIER way to do it now!" The ticket has been reopened as "the user doesn't want to change their workflow"... :^) :^)
veni bibi saltavi
Been there, done that. I have been working on modernizing a few legacy applications. It always ends up in battle with the users. I have heard every reason to want not to use the new system: . Not enough color. (Some users want the application to look like a clown on crack) . Too much color. . Not our company colors. (Yeah, green text on a pink background) . Too many entry fields. . Missing entry fields (Like anyone has a telex today....) . Things are in the wrong place/order. . Etc. Sometimes, the users don't want to upgrade and are staying on the old version. Sometimes, they go to another company that promises to build what they want. (not what they need) Quite often we have no choice because of governmental rules. But most of the time it comes down to poor communication. Users are like little children, you need to explain it in simple term, and repeat it over and over again. You NEED to get the users involved BEFORE you start coding the new system. Give them the idea that they are in control, but in the meantime, you are slowly and gently steering them in the right direction.
-
A lot of the last year, I have been gutting legacy code from our app and rewriting from scratch a stupendous marvel! -- Except -- Due to [legal stuff redacted] we need to handle the legacy data structure. This means at the back all the bd data needed to be preserved and it restrained the new functionality. I have ticket to add back in some intentionally omitted elephantine functionality. You cannot believe the joy I had in closing it with a comment of "Not going to happen! We've removed it as it should never have been there, there is a better and EASIER way to do it now!" The ticket has been reopened as "the user doesn't want to change their workflow"... :^) :^)
veni bibi saltavi
Terrible thing, but... I discovered this interwonenness (is that a word at all?) about 35 years ago. There is no way to tell users to change their habits from a programming chair and all sorts of less palatable motives might be involved (only at the userside, of course...). You need to (re)formalize a (set of) workflows before you can expect acceptance, because even if there is no spontaneous acceptance, you can now enforce it.
-
A lot of the last year, I have been gutting legacy code from our app and rewriting from scratch a stupendous marvel! -- Except -- Due to [legal stuff redacted] we need to handle the legacy data structure. This means at the back all the bd data needed to be preserved and it restrained the new functionality. I have ticket to add back in some intentionally omitted elephantine functionality. You cannot believe the joy I had in closing it with a comment of "Not going to happen! We've removed it as it should never have been there, there is a better and EASIER way to do it now!" The ticket has been reopened as "the user doesn't want to change their workflow"... :^) :^)
veni bibi saltavi
-
Quote:
rewriting from scratch a stupendous marvel!
Which is, often, quite satisfying …
Quote:
"the user doesn't want to change their workflow"
Which, often, translates into: someone makes his/her living maintaining that workflow …
Espen Harlinn Senior Architect - Ulriken Consulting AS The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility, and among other things he avoids clever tricks like the plague.Edsger W.Dijkstra
Espen Harlinn wrote:
Which, often, translates into: someone makes his/her living maintaining that workflow …
Agreed. I've experienced numerous situations where one or more people resist change as the old way of doing things means job security. One program we replaced featured a 2-digit code field with hundreds of potential values. One user had the codes memorized and could fly through data entry, while everyone else could remember the commonly used codes but was hampered by having to look up any of hundreds of uncommon codes. [The old application was written in Clipper, so the "GUI" was text based.] That one user was threatened by the idea that, using the new application (which had a lookup mechanism for the codes), anyone could be trained quickly to do that job. I was told this resulted in a number of ugly shouting matches between that one user and various managers.
-
Been there, done that. I have been working on modernizing a few legacy applications. It always ends up in battle with the users. I have heard every reason to want not to use the new system: . Not enough color. (Some users want the application to look like a clown on crack) . Too much color. . Not our company colors. (Yeah, green text on a pink background) . Too many entry fields. . Missing entry fields (Like anyone has a telex today....) . Things are in the wrong place/order. . Etc. Sometimes, the users don't want to upgrade and are staying on the old version. Sometimes, they go to another company that promises to build what they want. (not what they need) Quite often we have no choice because of governmental rules. But most of the time it comes down to poor communication. Users are like little children, you need to explain it in simple term, and repeat it over and over again. You NEED to get the users involved BEFORE you start coding the new system. Give them the idea that they are in control, but in the meantime, you are slowly and gently steering them in the right direction.
Quote:
You NEED to get the users involved BEFORE you start coding the new system. Give them the idea that they are in control,
They just might have ideas on improving the system -- frequently the decision-makers (a.k.a. their bosses) have no clue about any of the current work flow impediments, or the work-arounds that are just part of what the users "have to do" to get their old system to support their work.
-
A lot of the last year, I have been gutting legacy code from our app and rewriting from scratch a stupendous marvel! -- Except -- Due to [legal stuff redacted] we need to handle the legacy data structure. This means at the back all the bd data needed to be preserved and it restrained the new functionality. I have ticket to add back in some intentionally omitted elephantine functionality. You cannot believe the joy I had in closing it with a comment of "Not going to happen! We've removed it as it should never have been there, there is a better and EASIER way to do it now!" The ticket has been reopened as "the user doesn't want to change their workflow"... :^) :^)
veni bibi saltavi
Nagy Vilmos wrote:
The ticket has been reopened as "the user doesn't want to change their workflow"...
In my experience, you should always question the "game of telephone" between yourself and 'the user'". In an organization of even a meager size, especially if there are multiple "support groups" in "multiple organizations" between the end user and the "developer/product designer", then both ends have a good chance of getting bad information. The end user and the developer/designer typically understand the nitty gritty details of the job, issues, and potential solutions and everyone else has a skin deep understanding. That lack of in depth knowledge causes the links in the telephone chain to miscommunication information and insert their own ignorant perspective to "help" the situation along having no idea the damage they are causing. Then again, your project is just one of 10 those "helpers" with skin deep knowledge are probably handling and can't justify the time to get the in depth knowledge you can.
-
A lot of the last year, I have been gutting legacy code from our app and rewriting from scratch a stupendous marvel! -- Except -- Due to [legal stuff redacted] we need to handle the legacy data structure. This means at the back all the bd data needed to be preserved and it restrained the new functionality. I have ticket to add back in some intentionally omitted elephantine functionality. You cannot believe the joy I had in closing it with a comment of "Not going to happen! We've removed it as it should never have been there, there is a better and EASIER way to do it now!" The ticket has been reopened as "the user doesn't want to change their workflow"... :^) :^)
veni bibi saltavi
Today's brilliant code/design is tomorrow's bad design. They don't pay you because it's fun, they pay you to get it done their way. :rolleyes: Get over it. :((
Wear a mask. the life you save may be your own.
-
Espen Harlinn wrote:
Which, often, translates into: someone makes his/her living maintaining that workflow …
Agreed. I've experienced numerous situations where one or more people resist change as the old way of doing things means job security. One program we replaced featured a 2-digit code field with hundreds of potential values. One user had the codes memorized and could fly through data entry, while everyone else could remember the commonly used codes but was hampered by having to look up any of hundreds of uncommon codes. [The old application was written in Clipper, so the "GUI" was text based.] That one user was threatened by the idea that, using the new application (which had a lookup mechanism for the codes), anyone could be trained quickly to do that job. I was told this resulted in a number of ugly shouting matches between that one user and various managers.
I think we've all seen this pattern. Now, I love keypunch fields like that, and in the past, I've only made one modification. I allow the user to hit a key (? or F3, etc), while on that field, to open up a lookup dialog, and search by name, or scroll... And select. The best of both worlds. The old user cannot complain, because it does not affect them! The new users get trained faster/better. For the record, this should have been designed INTO the product in the first place, in general. Nobody should have to remember "codes"
-
You're just selling it wrong :laugh: I hear what you're saying though and it can be a real issue. I always try to make myself redundant. If I'm redundant I've done a good job and made or saved (my employer) lots of money. Any employer should see value in such an employee. The issue here, of course, is the people are not making themselves redundant, they're made obsolete :sigh:
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
agree 100% The cream of the employees are often given opportunities to move UP in the company. We had a young man who did just that with these kinds of improvements, and since it was an improvement like these, that allowed him to replace a much more experienced user, he was the one bringing suggestions to us. Like: guys, I love having 2 monitors, but if I had a third monitor, I could be stationed at the Front Desk, and answer the phone, and sign for the packages. The next day, I put a third monitor on his machine, and moved it to the front desk. [we were a small startup, couldn't afford a receptionist, but needed one] Yes, some employees will be let go, and HOPEFULLY they learn to step it up at their next position...
-
I think we've all seen this pattern. Now, I love keypunch fields like that, and in the past, I've only made one modification. I allow the user to hit a key (? or F3, etc), while on that field, to open up a lookup dialog, and search by name, or scroll... And select. The best of both worlds. The old user cannot complain, because it does not affect them! The new users get trained faster/better. For the record, this should have been designed INTO the product in the first place, in general. Nobody should have to remember "codes"
Kirk 10389821 wrote:
For the record, this should have been designed INTO the product in the first place, in general. Nobody should have to remember "codes"
You've obviously never worked on some of the old mainframe systems. When your paying big dollars per KB, you're not going to waste it by putting in "helper" type messages when a piece of printed paper with values for lookup codes will do. Many of the "codes" we see in modern systems are often a legacy from the time when every bit was precious.
-
Kirk 10389821 wrote:
For the record, this should have been designed INTO the product in the first place, in general. Nobody should have to remember "codes"
You've obviously never worked on some of the old mainframe systems. When your paying big dollars per KB, you're not going to waste it by putting in "helper" type messages when a piece of printed paper with values for lookup codes will do. Many of the "codes" we see in modern systems are often a legacy from the time when every bit was precious.
Actually, I did work on legacy systems. And whenever we moved them to Clipper (oh, the days), or some other technology, we implemented the lookups. Not much I could do with the COBOL, other MANY of the 3270 terminals had extended function keys, and second terminals to assist in the lookups. Sometimes on another screen/window. And then back. It wasn't the best, but it beat memory and the often TAPED OVER PAPER all around the keyboard. In fact, if you look HARD enough at an HTML FORM, and a mainframe screen. You wig out because it's so similar. Fields defined, the form is defined, the update is pushed back with the field values encoded, but the rest of the screen not sent. It's crazy. Everything OLD is new again. LOL
