I used to work for a university trying to modernize how people got student and financial data. Over half my work was playing politics rooting out people who refused to change and going above their head. We had one guy who didn’t want to update a script on his end to include the bare minimum amount of ‘security’: a hard coded plain text password. It took me months and I had to go to his office to update his script and he complained about it the entire four minutes it took
“Due to budget constraints, resources will shift from $oldThingy to $newThingy. As a result, $oldThingy’s availability can no longer be maintained at the previous level.”
Then randomly kill oldThingy for more and more hours each day.
I had this one user who kept using an old report. It used a terribly provisioned db account and had to be changed.
We created a v2 that was at feature parity to v1 and told users to move off of v1. Slowly but surely it happened.
Except one user.
We put up nag screens. Delays on data return, everything we could go “carrot” them to the new version but they stuck with it.
Eventually I called the guy and just asked him, “Why are you still using the old version?”
His answer, “no one ever told me about the new version.”
I asked him if he got our email. He said no. I forwarded it to him.
“Oh.”
I asked him didn’t you read the nag screens? He said no.
I asked him, “The page doesn’t allow you to move on until you wait 90 seconds. Why didn’t you read it?”
“I didn’t think it was important.”
I learned an important lesson that day: never wait for all users to move. Once you have enough, start doing scream tests.
Bastard user from hell
Every IT/software group needs to have one, otherwise you get complacent.
If some guy just minding his own business is your “user from hell” I am truly envious of your job
I used to work for a university trying to modernize how people got student and financial data. Over half my work was playing politics rooting out people who refused to change and going above their head. We had one guy who didn’t want to update a script on his end to include the bare minimum amount of ‘security’: a hard coded plain text password. It took me months and I had to go to his office to update his script and he complained about it the entire four minutes it took
Email to all:
“Due to budget constraints, resources will shift from $oldThingy to $newThingy. As a result, $oldThingy’s availability can no longer be maintained at the previous level.”
Then randomly kill oldThingy for more and more hours each day.
(can’t be bothered to check the syntax).
If you have a major version change, it means that old API calls will break against the new API, assuming they are accurately following semver.
You’re absolutely right. In my mind “feature parity” got garbled into “backwards compatibility”.
A translation layer could be used, no? Check api version, translate any v1 specific calls into their v2 counterparts, then submit the v2 request?
This isn’t really efficient because when v2 gets updated now you have to update the translation layer as well.
Any improvements you made in v2 would likely not translate.
Essentially the best way is to provide users with an incentive to switch. Perhaps a new feature or more requests.