Forums
Years ago, Peter worked as a highlyly paid IT consultant. You know those guys who come into the office in Italian suits and take over the large conference room as their "office" for six weeks? Well, Peter was one of those guys. But unlike the stereotype, he actually earned his hourly rate while applying his expert experience to several projects. He also had the luxury of working with some very highly skilled (and also highly paid) professional colleagues.
However, times started to get tough and Peter was having a harder and harder time finding a position as a consultant. Soon, he had to face facts — he'd have to explore other employment options, including getting a job as... a regular developer.
Paradigm Shift
It's not so much that Peter disliked the prospect of working as a salaried employee, but his choice to become a consultant stemmed from experiencing years of corporate-type WTFs.
For several years now, he had become used to working on small teams of "Elite Strike Force Systems Analysts" that were designed to be lean and mean, and get the job done at all costs under tight deadlines. His was a world where the PHBs dare not tread, nor were they welcomed. However, despite having to repress previous memories, Peter remained confident that he could find his niche.
But alas, his first day at his new regular job brought back to mind his painful past. His cubicle was amidst a sea of eighty or so identical units, all with one or more developers huddled around a PC doing what appeared to be the same kind of development. When Peter would ask fellow workers what they were working on, all but one replied "Oh, I'm finishing up my web report for the new customer web portal," and each web report they were responsible for seemed to be almost the same as the last one. For example, there was the Major Customers by Geographic Location report and then the Geographic Locations of Major Customers report. As for the guy that wasn't working on reports, he was the roving security guard.
What was the group of eighty developers working on that couldn't be done in a team of twenty? he thought, but reminded himself that he was still a newbie and couldn't be expected to understand the subtle, yet deadly differences between to similarly named reports.
Logging Involves Trees, Right?
Being that Peter was working at a bank — namely a Swiss bank — security was tight. Peter was not allowed to do anything on his workstation except use MS Office, work with Visual Studio, and send/receive email. For security purposes, IIS was not installed, meaning that code had to be compiled and tested on another server.Oh well, Peter thought, it's just 'their way' of doing things. No big deal, I'll play along.
His first assignment was easy: develop the Key Customers by Geographic Locations report. After a couple hours of writing some code, he spent another hour compiling and deploying his changes to the dev server so that he could run the report. Drat, he said to himself, the grouping control isn't returning the correct selection.. He loaded up his remote debugger and ran into another roadblock: his account didn't have remote debugging privileges. Figuring that some network admin had forgotten to give him the right privileges, Peter asked a coworker for help.
"Remote debugging?" his coworker said quizzically, "what's that? Like putting Response-dot-Write statements in and stuff?"
Peter explained that, by remote debugging, he actually meant hooking up a debugger to the dev server and remotely debugging the code.
"Oh yah," he responded, "no, we don't do anything like that here."
Perplexed, Peter asked how exactly they manage to test and debug their code.
"Uhhh," his coworker said in a condescending tone, "we look at it!"
There must be some misunderstanding, Peter thought to himself, Sooner or later this situation will sort itself out! In the mean time, he added in a handful of Trace statements to help "remote debug" his code.
Debug F.U.D.
After a few flustering days of trace-style debugging, Peter approached his manager about the issue. "Obviously," his boss responded, "debugging is switched off for security reasons. We're a bank, after all, and the last thing we'd want is a malicious user being able to compromise the bank's security!"
Peter agreed that security was important, but pleaded that there was little risk in allowing debugging on the dev server by developers. And besides, writing trace statement after trace statement was tedious.
"Whoa, whoa, whoa," Peter's manager said while waving his arms, "you're using TRACE statements!? Oh no no, we don't allow any debugging code or trace statements. We're a bank, after all, and the last thing we'd want is an end user gleaming sensitive system information from a debug message!"
Peter admitted that yes, he had added a few trace statements. This only led into a half-hour tirade about how "maverick" developers like him were "the kind of problem people" who invited hackers in. After giving his security spiel, he concluded that he was glad that they had the chance to speak and requested that Peter rollback any changes that included the Trace statements. Because you never know, the auditors could drop in anytime for one of their random inspections.
Not much longer after the incident with his manager, Peter decided that his time working as a cog in a great corporate wheel wasn't for him, especially when being "coached" by an IT manager who for not following the company's best practices. As he packed his belongings, Peter felt a small twinge of guilt that his report task would be left incomplete, but the feeling passed as he realized that there were eighty other guys and gals in the room who "just knew" how the system worked and would be more than capable of implementing his report.
[Advertisement]
BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!