Password Unification

Word Count:
600

Summary:
First let me point out I’m one of those life-long students. Not because if love college, but because I can never make up my mind on what I want to do. After making some big life changes I decided to take a full year away from school. Yesterday I attempted to register for this coming spring semester to get back on track. Interestingly enough my account has been disabled… sort of... This is where the fun starts.


Keywords:
large network problems, complicated networks, login problems, access network problems, university computers, network management


Article Body:
<strong>Premise</strong>
<code>“Just because you’re big doesn’t mean you have to be dumb.”</code><p>First let me point out I’m one of those life-long students. Not because if love college, but because I can never make up my mind on what I want to do. After making some big life changes I decided to take a full year away from school. Yesterday I attempted to register for this coming spring semester to get back on track. Interestingly enough my account has been disabled… sort of... This is where the fun starts.</p><p>I expected my account to be disabled, that isn’t the issue here. The problem is how it was disabled, and the messages which I received back from the University. First my account still worked to access class registration, and the University portal but my E-Mail had been completely locked out. This is the main point of my concern. If the university had a unified technology structure the login / password information would be centralized. An account disabled one place should be disabled across campus. Instead some departments disabled my account, and other left it running while I was gone. Worst some parts of the university left it partially running, but unusable.<p>Strange isn’t it? Why not completely disable my account rather then just PRETEND it works only to give me a nasty permissions error when I attempt to USE the portal which I am already logged into.</p><p><strong>Rule #1</strong></p><p><code>“Never let the user see the nasty error.”</code></p><p>Building an application or networked system on any level requires more then just getting the job done. A developer should take the additional time to build functionality for the unexpected. In my case there should have been two things.</p><p>A friendly message explaining why my account was disabled and directions on how to re-enable my account. </p><p><strong>Rule #2</strong></p><p><code>“Avoid the circle of death; take personal responsibility for the problem.”</code></p><p>First I talked to my counselor who said I should talk to computer services. Computer services told me to talk to the registration office. The registration office told me to talk to my counselor. <strong>FAIL</strong>, never ending loops are bad, not just in programming but in the real world.</p><p>This could have been avoided at each step, but instead the problem was passed onto someone else. All someone had to do was research the problem, and they would have known the problem has come up in the past. The eventually solution was to force someone to register my classes over the phone rather then using my account on the Internet.</p><p><strong>Rule #3</strong></p><p><code>“Record problems and make proactive steps to resolve known issues.”</code></p><p>I work in IT and I know how incredibility complicated things can get. But it’s important to always take steps to prevent the situation from coming up again. I am sure that I am not the first person to have their account disabled, and because no one is following rule three; I will likely not be the last. A few simple changes to the application would easily fix the problem, but no one cares enough to do anything about it. This means me, THE CUSTOMER, THE STUDENT, THE IDOIT, to run around trying to convenience people to do their job.</p><p>Thanks for the warm welcome back <a href="http://turkiyespot.com/www.uakron.edu</a>">akron</a>,</p>