A friend of mine manages the directory services for a large academic institution. He was telling me today about a lot of the bogus information his team has to sort out. Their directory aggregates information from payroll systems, student data systems, and a few other sources. Occasionally, but more frequently than they’d like, someone substitutes words like “NONE” or “NOTPRESENT” or even a single ‘.’ for missing information. This happens often with foreign students, and until they show up for class there is no good way to get the missing data.
When these people get assigned a username by my friend’s system they get none, notpresent2, rdnone, or something equally ridiculous (sometimes just a single number, like ‘4’). Eventually these people call support, someone asks for their last name, and things get sorted out. His team chuckles a bit but fixing the problem ends up being a lot of time wasted by a lot of different people.
Data systems are often built to reject blank data fields, thinking that it’s an error. Why would you ever not enter a last name, for example? Everybody has a last name, right? But when the data entry person doesn’t have the data, and has no way of getting it, it isn’t surprising that they just make something up and hope for the best.
Wrong data is worse than no data, though. Systems need a way to flag missing data, so that downstream systems catch on and do the right thing. In this case the username code could have avoided assigning a username until the person had a last name, for instance. These things need to be designed into systems from the beginning, which is a great reason to involve the people who actually do the work. So many systems are designed by managers and programmers, based on assumptions about ideal working conditions and perfect information. Reality doesn’t always work as perfectly as designers hope, and acknowledging that up front saves a lot of time and money in the long run.
Unfortunately, it also minimizes funny usernames. 🙂
