The team got a request to change login ID of an existing user. This was indeed very strange. The login ID percolates through all the database tables and change in the ID means to move all the data from the old ID to the new login ID. This was indeed an uphill (read boring, time consuming and mundane) task.
But one wonders what could be the need or what could’ve given rise to such a requirement. More than being downbeat about doing the data migration, we were curious to know the reason behind. It isn’t a standard practice anywhere to change loginID AND move all the data along. So I spoke to the person on field, who passed on this “want” of a customer to us, to get more clarity on what triggered this requirement.
The discussion went like this
us : got your mail regarding login ID change. i have some questions.
he : shoot ‘em.
us : what is wrong with the current login ID
he : login IDs are like employee numbers of teachers. it is confidential.
they feel students could misuse it.
us : but we don’t display the login ID anywhere. Leave alone the fact that loginID is not a confidential
information.
he : err … its like this … teacher starts the projector and the login screen comes up. now teacher
logs in by typing the login ID. All the students can now see the login ID, as the teacher types it.
This what the teacher fears. Instead they would like to use a login ID that is not in any way linked to
anything else.
us : but this should be a problem for all teachers. all of them have their employment number as loginID.
Has anyone else complained ?
he : No. But we cant say NO to this customer.
us : how do the others manage ? I mean, they should login and then start the projector isn’t it ? Or
henceforth let us not encourage creation of login IDs that can represent sensitive information like
employment number or bank account number etc.
he : may be you are right.
us : ok. bye.
The learning for us has been
0. We often tend to seek solutions by expecting the application to be extremely resilient. Whereas this is the power of software, sometimes it could turn out to be detrimental. Solutions can be implemented at various points and through various channels (like pre-sales, sales, registration, non-technical support). A good co-operation between all these teams is crucial.
1. Let IDs not represent sensitive information. In other words, inform the user that the login ID is for use by others as well. Just like a person’s name.
2. Distinguish between users ‘needs’ and ‘wants’. In this case user ‘wants’ a change in login ID. This isn’t actually ‘needed’ if they know how to use the projector OR if they had chosen a harmless login ID.
3. developer frustrations tend to get reduced when the root cause is known and a proposal to prevent such occurrences in future is made.
4. Be alert. Interesting problems disguise themselves as seemingly boring maintenance activities. Ask the right questions and explore. It cant get any more interesting !
August 19, 2008 at 10:38 pm |
Just a suggestion..mostly the opinion of a devil’s advocate….You might want to stop percolating the “login id” in your tables…if this does seem symptomatic of a request type you foresee getting all too often.
Instead use auto generated ids (for each login records in the User table) in all the other tables which need to reference the User record. Then, if anyone wants to change their “login id” – which essentially is their “screen name”; it wont be such a hassle. Since you don’t even show the “login id” on screen, it shouldn’t be a big deal.
Of course, there’s no doubting the fact that this is a painful refactoring for an existing system
.
Anyway, users do come up with all the darndest requests you can imagine.