Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor
  • Default (No Skin)
  • No Skin
Collapse
Code Project
CODE PROJECT For Those Who Code
  • Home
  • Articles
  • FAQ
Community
  1. Home
  2. The Lounge
  3. Legacy System Rewrite - The shackles of bad design

Legacy System Rewrite - The shackles of bad design

Scheduled Pinned Locked Moved The Lounge
designworkspace
27 Posts 19 Posters 6 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • J JohaViss61

    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.

    H Offline
    H Offline
    Harrison Pratt
    wrote on last edited by
    #21

    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.

    1 Reply Last reply
    0
    • N Nagy Vilmos

      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

      D Offline
      D Offline
      Dave B 68
      wrote on last edited by
      #22

      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.

      1 Reply Last reply
      0
      • N Nagy Vilmos

        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

        S Offline
        S Offline
        Slow Eddie
        wrote on last edited by
        #23

        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.

        1 Reply Last reply
        0
        • B BryanFazekas

          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.

          K Offline
          K Offline
          Kirk 10389821
          wrote on last edited by
          #24

          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"

          H 1 Reply Last reply
          0
          • Sander RosselS Sander Rossel

            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

            K Offline
            K Offline
            Kirk 10389821
            wrote on last edited by
            #25

            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...

            1 Reply Last reply
            0
            • K Kirk 10389821

              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"

              H Offline
              H Offline
              harvyk0
              wrote on last edited by
              #26

              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.

              K 1 Reply Last reply
              0
              • H harvyk0

                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.

                K Offline
                K Offline
                Kirk 10389821
                wrote on last edited by
                #27

                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

                1 Reply Last reply
                0
                Reply
                • Reply as topic
                Log in to reply
                • Oldest to Newest
                • Newest to Oldest
                • Most Votes

                • Login
                • Don't have an account? Register
                • Login or register to search.
                • First post
                  Last post
                0
                • Categories
                • Recent
                • Tags
                • Popular
                • World
                • Users
                • Groups