As a bright-eyed, bushy-tailed class of 2006 graduate, Andrew M. was excited to start his first job as a professional developer. He was fortunate to find a job so quickly after graduating and he was ready to make a difference.
The first day he showed up to work, he was ready to meet his coworkers, get his email set up, and have a look at the code he'd be maintaining. He was introduced to the IT guy that greeted him with a friendly "oh, you're the new developer," which was the extent of their conversation while they walked to Andrew's new desk.
Andrew was seated at a neglected desk with a neglected computer; an old system with 64MB of ram. "Don't install anything on it," said the IT guy. "Because the hard drive isn't big enough." He may've been in a bad mood since he had to add Andrew to Active Directory that day, and struggled figuring out how to do so.
He was right about the hard drive, though. In fact, the system didn't have the necessary resources even to run the Oracle training applications that Andrew was required to complete. There was hope, though; they ordered a new computer and monitor for Andrew, so if he just sat tight for a week or two, things would get better.
When the shipment came in, the VP told Andrew that they only got a computer; he'd just have to stick with the monitor he had. A formerly white, now yellowing 17" CRT with a flickering red gun.
Still, the new computer was a small victory, and he could finally complete his training exercises and get started on development. The development manager set him up with a CVS account, which prompted Andrew to ask where the repository was stored.
"It's on my home network," replied the development manager. Andrew didn't laugh because he wasn't sure if this was a joke. (It wasn't.)
This concerned Andrew, though he was assured that their clients knew about the location of the repository.
Once Andrew was up and running, he noticed that the network was slow. And this wasn't limited to internet access — file transfers over the network seemed to take ages. This is because the network ran on Cat 3 cabling at the breakneck (for 1990) speed of 10Mbps. There are no plans to upgrade any time soon, either.
Still, Andrew persevered. He was good at his job and still wanted to make a difference. He was doing some work in a production system when he noticed that the database calls seemed to be running slow. He asked one of the other developers if they were noticing any slowdown and learned that an old workstation had been recommissioned to be a database server; it was a PIII 800 with 1GB RAM. And it was running multiple instances of Oracle. The developer Andrew was talking to told him that the system just needed to be restarted, and complained that the suggestion to make the server reboot nightly was rejected. Another developer had tried to get the purchase of a new server approved, and failed.
When Andrew wanted to print up a task list for a project he was working on, he had to ask another developer for help printing. "What's your number," asked the developer.
"Uh... it's 555-12..."
"No," interrupted the developer, "the last number in your password."
"Oh... 'H.'"
"Look, if you want to print, your password has to be 'p2n' and then your user number."
Andrew isn't clear on the reasons for this, but it turns out his password's first three characters had to match the password for the server the printer was connected to. Then the last character in the password had to be a user-specific number. Once he had it set up correctly, he could print to the beige LaserJet printer from 1992. He opted to not set it up correctly, instead choosing to have a password that was more than four characters.
Andrew had heard complaints about Citrix around the office, but hadn't experienced it firsthand until he had to do some testing. Over a Cat 3 connection, he'd have to go through VPN, then Citrix to access shared files, and for testing he'd also have to go through VPN, Citrix, then IE. Citrix may've suffered some undue criticism from the users, though, as Andrew can only guess what kind of hardware was running the software. He did know that the Citrix server had a nightly reboot script, though.
Finally, before Andrew started, all bug tracking was done manually via email. A little after the time he started, the lead developer took it upon himself to install bug tracking software within the domain, and it was fantastic. It was easier to get work done and to see which bugs took priority over others, and the developers loved it. That is, until one of the clients caught wind of it. One of the clients that was OK with the fact that the source repository was stored on the lead developer's home network. They didn't like the idea of information about the company being stored off-site (maybe they don't know what the "source repository" was), so Andrew's company went back to manual bug tracking.
Andrew isn't at the company anymore; he's now working at a small consulting company where he's much happier.