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
-
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
-
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
this stresses the importance of having a user requirement document/functional design documents signed off by the user/department of the business before the system is designed or changed.. i had a case where the user just had a user manual with screen shots of the old program and said they new program needs to have all this...it did'nt end well...
Caveat Emptor. "Progress doesn't come from early risers – progress is made by lazy men looking for easier ways to do things." Lazarus Long
-
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
I never understood these rewrites that should basically produce the exact same application :~ It would probably be best to sit down with the user and show them how it's done now. In fact, this request might not even come from a user, but from a manager who thinks their employees should not lose time/make mistakes learning a new system because it would look bad on them. Or maybe a manager with no imagination who thinks the current system is the best and/or only system that works for their department. Or it may come from users who are afraid they'll not understand the new system and it could cost them their job. In my experience, this kind of behavior is usually not bad intent, but lack of knowledge or fear of the unknown. That's why it's so important to involve users early on. And sometimes, just sometimes, the users really have some very specific functionality or workflow that we developers and/or business analysts missed and the new system would make their job harder or take longer. Nah, who am I kidding? We're perfect :)
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
-
I never understood these rewrites that should basically produce the exact same application :~ It would probably be best to sit down with the user and show them how it's done now. In fact, this request might not even come from a user, but from a manager who thinks their employees should not lose time/make mistakes learning a new system because it would look bad on them. Or maybe a manager with no imagination who thinks the current system is the best and/or only system that works for their department. Or it may come from users who are afraid they'll not understand the new system and it could cost them their job. In my experience, this kind of behavior is usually not bad intent, but lack of knowledge or fear of the unknown. That's why it's so important to involve users early on. And sometimes, just sometimes, the users really have some very specific functionality or workflow that we developers and/or business analysts missed and the new system would make their job harder or take longer. Nah, who am I kidding? We're perfect :)
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
In our case one of the main reasons for the rewrite is to move to newer technology in order to move to different more cost effective hosting - Windows Server to Linux. Also for easier maintainability going forward. The new system isn't an exact copy of the old, but familiar enough for users to find their way.
-
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
Now you have two systems to maintain.
-
Now you have two systems to maintain.
Luckily no. We've switched off the old systems now, it's clients moaning about us [me] changing things.
veni bibi saltavi
-
I never understood these rewrites that should basically produce the exact same application :~ It would probably be best to sit down with the user and show them how it's done now. In fact, this request might not even come from a user, but from a manager who thinks their employees should not lose time/make mistakes learning a new system because it would look bad on them. Or maybe a manager with no imagination who thinks the current system is the best and/or only system that works for their department. Or it may come from users who are afraid they'll not understand the new system and it could cost them their job. In my experience, this kind of behavior is usually not bad intent, but lack of knowledge or fear of the unknown. That's why it's so important to involve users early on. And sometimes, just sometimes, the users really have some very specific functionality or workflow that we developers and/or business analysts missed and the new system would make their job harder or take longer. Nah, who am I kidding? We're perfect :)
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
Sander Rossel wrote:
It would probably be best to sit down with the user and show them how it's done now. In fact, this request might not even come from a user, but from a manager who thinks their employees should not lose time/make mistakes learning a new system because it would look bad on them. Or maybe a manager with no imagination who thinks the current system is the best and/or only system that works for their department. Or it may come from users who are afraid they'll not understand the new system and it could cost them their job.
There is another (but related) scenario that I have seen myself: Both users and managers may well recognise that there are other/better ways to do things but that some of these ways might actually improve efficiency. That can be a problem. An improvement in efficiency sounds great for the business but: (a) For many employees "greater efficiency" quite literally means "no job". (b) Managers at certain levels may be rewarded for improving efficiency by losing out on power/empire or even losing their team entirely as it is redistributed to other managers. They can improve themselves right out of their own job. Rightly or wrongly, a lot of businesses will in effect punish both management and employees for improving things for the shareholders. As I mentioned above, I've seen this myself: I was collecting user requirements for an order-taking/processing system and I could see exactly what needed to be done. I was enthusiastically describing how the system could eliminate certain manual steps. Then I noticed I was getting some unpleasant looks. Whoops... I was describing classic "efficiency improvements" which directly translated into lower head count. Some of the staff would be literally redundant. And their manager would have reduced responsibility. As the PHB once said (or something like this): "It's going to take a strong team to succeed. Specifically a much smaller team."
-
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"...
The solution to this problem is to provide some new functionality that can only be accomplished by following the new workflow.
If pigs could fly, just imagine how good their wings would taste! - Harvey
-
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
wouldn't an easier, cheaper solution be to (perhaps threaten) to fire the user?
Real programmers use butterflies
-
I never understood these rewrites that should basically produce the exact same application :~ It would probably be best to sit down with the user and show them how it's done now. In fact, this request might not even come from a user, but from a manager who thinks their employees should not lose time/make mistakes learning a new system because it would look bad on them. Or maybe a manager with no imagination who thinks the current system is the best and/or only system that works for their department. Or it may come from users who are afraid they'll not understand the new system and it could cost them their job. In my experience, this kind of behavior is usually not bad intent, but lack of knowledge or fear of the unknown. That's why it's so important to involve users early on. And sometimes, just sometimes, the users really have some very specific functionality or workflow that we developers and/or business analysts missed and the new system would make their job harder or take longer. Nah, who am I kidding? We're perfect :)
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
Sander Rossel wrote:
I never understood these rewrites that should basically produce the exact same application
It usually comes down to "training issues". If you do a rewrite that maintains the same general look and feel, the user base is more accepting. We're trying to get permission to do a rewrite, and the only thing that changes for the user is a minimal appearance changes, including better layout practices, fluid design, color changes, and small menu changes). The REAL changes involve the code that makes it happen. We're suffering from bad architectural decisions in the front end, and terrible schema decisions in the database. Our code base is over 10 years old and base on ASP.Net Web Forms, and the last time we updated jquery was 2013.
".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 -
In our case one of the main reasons for the rewrite is to move to newer technology in order to move to different more cost effective hosting - Windows Server to Linux. Also for easier maintainability going forward. The new system isn't an exact copy of the old, but familiar enough for users to find their way.
Jacquers wrote:
more cost effective hosting
Must be some cheap hosting if it outweighs the costs of a rewrite :wtf:
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
-
Sander Rossel wrote:
It would probably be best to sit down with the user and show them how it's done now. In fact, this request might not even come from a user, but from a manager who thinks their employees should not lose time/make mistakes learning a new system because it would look bad on them. Or maybe a manager with no imagination who thinks the current system is the best and/or only system that works for their department. Or it may come from users who are afraid they'll not understand the new system and it could cost them their job.
There is another (but related) scenario that I have seen myself: Both users and managers may well recognise that there are other/better ways to do things but that some of these ways might actually improve efficiency. That can be a problem. An improvement in efficiency sounds great for the business but: (a) For many employees "greater efficiency" quite literally means "no job". (b) Managers at certain levels may be rewarded for improving efficiency by losing out on power/empire or even losing their team entirely as it is redistributed to other managers. They can improve themselves right out of their own job. Rightly or wrongly, a lot of businesses will in effect punish both management and employees for improving things for the shareholders. As I mentioned above, I've seen this myself: I was collecting user requirements for an order-taking/processing system and I could see exactly what needed to be done. I was enthusiastically describing how the system could eliminate certain manual steps. Then I noticed I was getting some unpleasant looks. Whoops... I was describing classic "efficiency improvements" which directly translated into lower head count. Some of the staff would be literally redundant. And their manager would have reduced responsibility. As the PHB once said (or something like this): "It's going to take a strong team to succeed. Specifically a much smaller team."
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
-
Sander Rossel wrote:
I never understood these rewrites that should basically produce the exact same application
It usually comes down to "training issues". If you do a rewrite that maintains the same general look and feel, the user base is more accepting. We're trying to get permission to do a rewrite, and the only thing that changes for the user is a minimal appearance changes, including better layout practices, fluid design, color changes, and small menu changes). The REAL changes involve the code that makes it happen. We're suffering from bad architectural decisions in the front end, and terrible schema decisions in the database. Our code base is over 10 years old and base on ASP.Net Web Forms, and the last time we updated jquery was 2013.
".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, 2013That's a hard sale, we're going to spend $$$, but you won't notice a thing. And your employer should hope you won't make the same mistakes you made over 10 years ago ;) I totally understand that development can get very expensive and even come to a grinding halt if your code base is a mess and that it may be cheaper to do a rewrite. It's a very difficult situation to be in :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
-
That's a hard sale, we're going to spend $$$, but you won't notice a thing. And your employer should hope you won't make the same mistakes you made over 10 years ago ;) I totally understand that development can get very expensive and even come to a grinding halt if your code base is a mess and that it may be cheaper to do a rewrite. It's a very difficult situation to be in :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
The tangible difference is theoretical - significantly less effort in terms of maintenance (which is ironically where most devs spend their time in existing apps). "Yes, we're going to spend time rewriting it, but if we do it right, nobody will notice a difference in the app itself." Everybody on the team agrees that it needs to be done (the code base started in 2008/2009), and the code has have more than two dozen contractors work on it since then.
".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 -
Jacquers wrote:
more cost effective hosting
Must be some cheap hosting if it outweighs the costs of a rewrite :wtf:
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
There are a couple of factors involved. Windows vs Linux. Our 'parent' company overcharging us imo and I think a developer's standby / salary is included in the hosting costs we pay, which drives it up further. So while the rewrite is expensive and a pain atm it will probably be recouped within 2 years. Financially it makes sense, it just sucks for us devs who are being pushed / forced to complete it and deploy it before it's really ready for production.
-
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.
