Tags


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 !

Advertisements