Mittwoch, 30. April 2008

The Super Hacker

As a junior network administrator at a small local ISP, Kiefer R.'s job is pretty mundane. Aside from the occasional bandwidth problem investigating, cable laying, and spline reticulating, there's not too much excitement.


One morning, Kiefer's boss said he was going to come down for a chat, so Kiefer loaded up a bandwidth monitoring utility and pretended to be busy. "Kiefer," Mike began, "I just wanted to give you a heads up. We're having a guy come down next week to run some security checks on our systems here. Particularly our main web server."


"So, you need me to show him the ropes, or..."


"Oh, ha!" Mike started laughing. "No, not at all. This guy is like some kind of Super Hacker!" he exclaimed while waving his hands dramatically. "More like he'll be showing you the ropes! Ha!" Kiefer rolled his eyes.


The Super Hacker arrived the following week. He was there only for two days while he worked on his mission — shutting down the main web server from outside the network. He'd be in the office from 9-5, where he could talk to the staff and review some of the code to find sections he might be able to exploit, but he'd only get paid if the server was shut down while he was not in the office. He didn't receive any usernames or passwords as the testing was meant to simulate an attack on the web site from an average hacker. Should he accomplish his goal, he'd earn $3,500.00. Working in the Super Hacker's favor was that the aging site was last updated in the late 90s, and almost certainly had pages that would be exploitable.


When Kiefer came in the following morning, his boss was stopped him on his way in.


"Well, our Super Hacker has done it! Turns out it must've been a pretty easy exploit," Mike said, "it hardly took him any time at all. Plus he's already patched it!"


Kiefer couldn't deny that he was impressed. "So how'd he do it?"


"I'm not sure — I haven't gotten his report yet. I should have it by the end of the day."


Kiefer's curiosity was palpable. He asked around for details on the exploit, but no one was talking. Clearly, some people knew what had happened and just weren't willing to tell. Finally, someone told Kiefer that the fix was in the form of a Python script, and that if he read the script, he'd see the exploit.


How the aptly-named Super Hacker had managed to shut down the system remotely and provide a fix so quickly intrigued Kiefer. After poking around the network, he finally found the Python file that contained the Super Hacker's fix:



#!usr/bin/python
# Paying someone $10 to pull a power cord for $3500
print "(C) <Name Removed> 2008."


Of course, the fix alone wouldn't prevent future attacks using that vector, but management's scolding of the night staff would.




Brought to you by the Non-WTF Job Board:






CodeSOD: Oh, XML

"Having worked in the Computer industry for about twenty years now," Matt writes, "I rarely get the chance to actually write code. But I do get the joy of other people's problems landing at my feet when things go wrong."


"Not too long ago, one of our newer techies emailed me, complaining that he couldn't get load image data from a WebService created by another developer. Given that all of the XML serialization and deserialization is handed through our enterprisey library, it was only when I visted the WebService address in my browser that I was able to see the 'raw' data:



<attachments xmlns = "http://webservices..." >
<bytes>37</bytes>
<bytes>80</bytes>
<bytes>68</bytes>
<bytes>70</bytes>
<bytes>45</bytes>
<bytes>49</bytes>
<bytes>46</bytes>
<bytes>52</bytes>
<bytes>10</bytes>
<bytes>37</bytes>
<bytes>-30</bytes>
<bytes>-29</bytes>
<bytes>-49</bytes>
<bytes>-45</bytes>
<bytes>10</bytes>
<bytes>52</bytes>
<bytes>32</bytes>
<bytes>48</bytes>
<bytes>32</bytes>
<bytes>111</bytes>
...


"The error, for those that care, was that our code expected values in the range 0 to 255, rather than -127 to 128.






Brought to you by the Non-WTF Job Board:






Dienstag, 29. April 2008

Alex's Soapbox: Up or Out: Solving the IT Turnover Crisis

If you’ve worked at enough companies in the IT industry, you’ve probably noticed that the most talented software developers tend to not stick around at one place for too long. The least talented folks, on the other hand, entrench themselves deep within the organization, often building beachheads of bad code that no sane developer would dare go near, all the while ensuring their own job security and screwing up just enough times not to get fired.


Earlier this month, Bruce F. Webster aptly named this phenomenon the Dead Sea Effect. Today, I’ll discuss a solution to overcoming it. In short: embrace turnover, encourage separation, and don’t even think about saying “careers, not jobs.” Oh yes, it’s Employment 2.0.


 


Revisiting the Cravath System


Like many 2.0-isms and “innovative” ways of doing business, the “Up or Out” solution to our personnel crisis is not new. Paul D. Cravath first implemented it at the turn of the century. Not this century, of course, but the last one.


Here’s how the “Cravath System” works. Bring lots of new employees in, team them up with mentors, provide real work to do, and give them a choice: either get lots of great experience and get out, or work hard for a higher-up position. Whenever you hear someone aspire to “make partner”, he’s undoubtedly working at a firm that’s adopted this model.


Since its inception in the early 1900’s, the Cravath System has spread to tens of thousands of different companies in different professions, ranging from accounting to urban planning. Robert T. Swaine, in his 1947 book The Cravath Firm And Its Predecessors, describes the result of its use:


Under the “Cravath system” of taking a substantial number of men annually and keeping a current constantly moving up in the office, and its philosophy of tenure, men are constantly leaving… it is often difficult to keep the best men long enough to determine whether they shall be made partners, for Cravath-trained men are always in demand, usually at premium salaries.

Sound familiar? If we “black box” our current process and the Cravath System, they’re practically the same thing: lots of new hires of varying skill come in, and mostly talented workers come out. Yet, somehow, our box gets mucked up with the “residue”, while theirs stays a well-oiled machine. There’s a good reason for this: instead of fighting to retain top talent, we need to make top talent.


 


A Reality Check


Let’s not ignore the elephant in the room: employees will quit. No matter what you say, no matter what cushiony benefits you give, no matter how hard you try, they will leave you. It’s just a matter of “when”.


In almost every job I’ve had, giving my two-week notice was like an awkward, uncomfortable break-up. “Really,” I’d say time and time again, “it’s not you, it’s me.” It seemed no one understood that it was “just that time”. Worse still, they’d often decline my offer of thoroughly training a replacement and would sometimes even terminate my employment on the spot. This was truly their loss: when I’d leave, I’d take all intuitional knowledge they paid me to learn on my own, and not distill it for my successor.


The reason that I (and many of you) have had these similar quitting experiences is because many employers – despite having been employees themselves – don’t want to accept the fact that employees quit. Some even desperately try to change the fact. I can’t count the times I’ve heard “we offer careers, not just jobs” and “we’re more like a family than a company.” Interestingly enough, those companies tend to have the most mature dead-sea cycles.


Employees – especially the most talented ones – are not “dating around” and moving from place to place in search of the Perfect Company at which they can grow old and retire at. They’ve already aced the first four rungs of Maslow’s hierarchy and are in search of self-actualization: the instinctual need of humans to make the most of their abilities and to strive to be the best they can.


This point bears repeating. Indefinite retention is impossible; employees always quit. The key part is understanding why, and how to leverage this inevitability towards everyone’s advantage.


 


Why the Skilled Quit First


Bruce did an excellent job of explaining why the unskilled don’t quit:


They tend to be grateful they have a job and make fewer demands on management; even if they find the workplace unpleasant, they are the least likely to be able to find a job elsewhere. They tend to entrench themselves, becoming maintenance experts on critical systems, assuming responsibilities that no one else wants so that the organization can’t afford to let them go.

The reason that skilled employees quit, however, is a bit more complicated. In virtually every job, there is a peak in the overall value (the ratio of productivity to cost) that an employee brings to his company. I call this the Value Apex.


On the first minute of the first day, an employee’s value is effectively zero. As that employee becomes acquainted with his new environment and begins to apply his skills and past experiences, his value quickly grows. This growth continues exponentially while the employee masters the business domain and shares his ideas with coworkers and management.



However, once an employee shares all of his external knowledge, learns all that there is to know about the business, and applies all of his past experiences, the growth stops. That employee, in that particular job, has become all that he can be. He has reached the value apex.


If that employee continues to work in the same job, his value will start to decline. What was once “fresh new ideas that we can’t implement today” become “the same old boring suggestions that we’re never going to do”. Prior solutions to similar problems are greeted with “yeah, we worked on that project, too” or simply dismissed as “that was five years ago, and we’ve all heard the story.” This leads towards a loss of self actualization which ends up chipping away at motivation.


Skilled developers understand this. Crossing the value apex often triggers an innate “probably time for me to move on” feeling and, after a while, leads towards inevitable resentment and an overall dislike of the job. Nothing – not even a team of on-site masseuses – can assuage this loss.


On the other hand, the unskilled tend to have a slightly different curve: Value Convergence. They eventually settle into a position of mediocrity and stay there indefinitely. The only reason their value does not decrease is because the vast amount of institutional knowledge they hoard and create.



Shaping the Value Apex


There’s an entire mini-industry out there that helps companies stretch the value apex. Just googling “employee retention” brings back myriad results and ads, ranging from books to seminars to consultants. The value proposition of these various products is simple: spend some money now to retain employees longer, thereby saving more money later in turnover costs.


However, the value apex can only be stretched so far. At some point, the cost of retaining – be it through salary increases, motivational programs, or creating a Neverland with free food, free toys, and exuberant goof-off time – exceeds the cost of turnover. Regardless of how much a company spends on this – too little, too much, or just enough – it does not change the fact that the value apex exists.


After stretching, there’s only two ways to further optimize the value apex: by accelerating the value-growth curve and terminating it as close to the as the apex as possible. Both of these are accomplished through the Cravath System.


 


A Culture of Quitting


We’ve all experienced how managers and higher-ups dance around the fact that we’ll quit someday. The justification given for why a process should be documented is almost always “because you might be hit by a bus tomorrow” (or the less macabre “win the lottery”). Since neither is within the realm of reasonable probability, this transitional documentation is often half-assed with the understandable “you’ll have more things to worry about if I get hit by a bus” attitude. But imagine if the justification for documentation was different:


I need you to document this process in detail so that any yahoo can understand it a year from now after you’ve left.

I’ve never had a manager or higher-up ever put it that way. In fact, many people feel that’s an even more stolid justification than “hit by a bus”. But it isn’t; it’s just reality. Why not accept it?


Of course, that justification would never even need to be given if a company embraced a culture of quitting. If they were upfront with their employees and said something to the effect of, “we know that you’re not going to retire here; in fact, after two to three years, we know you’ll be ready to move on to a different job. But before that happens, we want to make sure that you feel that you’ve done an excellent job here and are leaving with some solid experience under your belt. Of course, there are a handful of architect and management positions available, but you’ll really need to demonstrate commitment before even being considered for those. Obviously, that path isn’t for everyone.”


Imagine how much different things would be if you were told that on your first day. Just about every task you do would be in consideration of your successor. Not only would you take pride in solving problems – and, of course, getting strong ROR (Return on Resume) for those solutions– but you’d also take pride in knowing that the guy who comes after you will have an easy time picking up your work. Just as your predecessor did for you.


The benefits don’t stop there. A company with a culture of quitting does not have ex-employees; they have alumni. This is far more than a semantic distinction. An alumni relationship is positive; something that people can take pride in; and one that keeps the door open for further opportunities on both ends. Let’s face it; we’re already curious about our former workplaces and try to keep up through former coworkers. It’d be that much easier if the company facilitated this in some manner.


The alumni relationship also helps with the flow of new personnel. While ex-employees are be hesitant to recommend the company they “broke up” with, alumni will champion it to colleagues in need of similar experience. Furthermore, there’s no sense of defeat when an alumni returns – armed with experiences from other organizations – for another tenure.


For consulting companies or services firms, maintaining a solid relationship with alumni is an excellent avenue to find new business. Who better to recommend as a vendor than a company that one had first-hand experience working at?


But perhaps the most important benefit to a culture of quitting is that it effectively flushes out the residue of unskilled employees. When someone hasn’t moved up or out after a few cycles, it becomes painfully evident who the weakest link is. Everyone – even that certain someone – knows that they’ve long outstayed their welcome. If the sheer awkwardness of being “that guy” doesn’t cause him to leave on his own, and he still doesn’t get it after being asked to resign, then certainly no one will miss him when he’s inevitably let go.


 


Bringing Home Change


Obviously, this article has painted some incredibly broad strokes, the largest being the stark dichotomy between skilled and unskilled developers, and the lack of distinction between organizations. While this doesn’t change the fact that a value apex exists, it does change its shape. Generally speaking:



  • The higher-up the position, the longer the curve. Changes tend to occur much more slowly at the top. For example, a basic “refactoring” of a department’s teams could take well over a year to implement.

  • The greater the skill, the shorter the curve. Ambition and skill go hand-in-hand, and ambitious individuals tend to want swift changes, and quickly lose motivation when these don’t happen.

  • The larger the company, the shorter the curve. Large teams are generally not receptive to ideas from the new guy, leaving a large part of contribution (i.e. past experience) wasted. Furthermore, promotions are often based on tenure, not skill.

  • The smaller the company, the longer the curve. Smaller companies, on the other hand, are more receptive to change, allowing one to contribute past experiences for a long while.

  • The less skill-demanding the company, the significantly longer the curve. Not all companies need top talent. For example, the company who needs only maintainers of an ancient COBOL application might be best fit with curves that are closer to the value convergence.


One important point to keep in mind, too, is that skill is not measure of overall worth. At some point in our lives, many of us no longer look towards our career for self actualization. For example, many feel that having a family provides much more self actualization than a career, and choose not to work those sixty hour weeks to meet those tight deadlines. And there’s nothing wrong with that.


That said, we still need to bring these changes to our industry. Obviously, we can’t all implement the Cravath System overnight. For many companies – especially those who really don’t need skilled developers –a full-fledged Cravath system will never be a good fit.


But there is one thing that we all can do. In fact, let’s all do it together, right now, right this moment. Employees, go ahead and say to yourself:


I know that I will quit my job, and there’s nothing wrong with that.

Now it’s your turn, employers/managers:


I know that my employees will quit, and there’s nothing wrong with that.

Once we’ve all accepted this, things will start to work better. Eventually, we’ll join the legal industry, the accounting industry, and so many others, and we too will have our well-oiled machine. But first things first: we need to embrace quitting, not fear it.




Brought to you by the Non-WTF Job Board:






Error'd: Know your Audience

Whereas most ads for search engines list something boring like "hotels" or "pet grooming" as an example, Live Search knows what the average internet user actually searches for.





(submitted by Rob G.)



 


"Apparently these files flew back in time from the year 41221, where they have a July -2147483642nd," Bretto writes. "At least the files were done before the 5:00 PM deadline."






Ryan kept getting this error while the software paced back and forth in the kitchen, wringing its hands.






Tom M. prefers that software failures happen for a good reason.





(submitted by Rob G.)



 


Thanks a lot, Ed L., I've been staring at this for like 10 minutes trying to figure out if it's an actual database error or if it's intentionally ironic.





(submitted by Rob G.)





Brought to you by the Non-WTF Job Board:






Montag, 28. April 2008

Best of the Sidebar: Best f**king censorship ever

Originally posted by "rc_pinchey"...



A friend of mine recently started a new job, and we were having a conversation via email. Unexpectedly, she tells me that my latest email has been blocked by their automated filtering system — instead of receiving my email, she was sent this:


Please reply with history to uspostmaster@[removed].com if you would
like this message released.

MailMarshal (an automated content monitoring gateway) has
stopped the following email for the following reason:

It believes it may contain unacceptable language, or inappropriate material.

Message: B47d568a10002.000000000001.0002.mml
From: [removed]
To: [removed]
Subject: Re: [removed]

MailMarshal Rule: Content Security (Inbound) : Block Unacceptable Language
Script Offensive Language (Basic) Triggered in Body
Expression: f-ck* Triggered 2 times weighting 10
Expression: sh-t Triggered 2 times weighting 6
Script Offensive Language (Extensive) Triggered in Body
Expression: bugger* Triggered 1 times weighting 35
Expression: f-ck* Triggered 1 times weighting 60

Please remove any inappropriate language and send it again.

If you do not recognize the address listed in the From: field
above or the Subject: line does not relate to an expected email,
then the blocked message is probably spam and no further action
is required on your part.

Additionally, addresses listed above could possibly be spoofed.
Please see the following for more information on email spoofing:

http://www.cert.org/tech_tips/email_spoofing.html

The blocked email will be automatically deleted after 5 days.

Email Content Security provided by NetIQ MailMarshal.


Note that I added the hyphens for censorship (you're welcome, those of you at work). So, ironically, rc_pinchey's friend still got a list of all the swears he used. Clbuttic!




Brought to you by the Non-WTF Job Board:






Representative Line: The Nightly Session Drop

“Shortly after joining my new company,” writes Rajesh Subramanian, “they introduced me to The Monster: a massive, incomplete framework written in C++. Its documentation consisted of a few sparse, often contradictory comments. It was designed to be multithreaded, but always crashed with more than one thread. It was expected to run on different operating systems, but never quite made it past Windows 2000 SP3. And naturally, it’s filled with friendly variable names like s, t, pp1, pp2, and so on.”


“One of my first tasks – an ‘easy one’ – was to fix The Nightly Session Drop. For as long as anyone could remember, The Monster would disconnect at exactly midnight and reconnect a moment later. This would occasionally lead to ‘really bad things’ that could take all day to fix. So, after a half day of diving head first into The Monster, I found this line of code complete with comment…”



//A day has passed by... this must be definitely an invalid session
if (m_thisDay != date.T_day) Disconnect(SESSION_PREV, FORCE);


Rajesh added, “and to think… this is just the beginning.”




Brought to you by the Non-WTF Job Board: