|
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.
|
|
|
|
|
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.
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
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 
|
|
|
|
|
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 
|
|
|
|
|
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.
|
|
|
|
|
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 
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 
|
|
|
|
|
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...
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
wouldn't an easier, cheaper solution be to (perhaps threaten) to fire the user?
Real programmers use butterflies
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
I once had a manger put a 6 inch thick binder of my desk.
It was the code and documentation for a system I was supposed to replace.
I went straight to the users and asked them what they needed.
The program was a success.
I never did open that binder.
|
|
|
|
|
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.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
