Software development is a difficult task to meter.

It's not for lack of trying.

For decades consultants have been evangelizing methods which, they claim, would allow an unskilled, casual observer to easily measure and compare productivity in a contextually agnostic way.

Their ultimate goal: To allow a drop-in manager, with only a superficial knowledge of the activities, skills, and complexities of a task or project, to easily compute metrics by which to dole out the frequency and intensity of whippings and rewards.

[Aside: Before anyone incorrectly presumes any of this is critical of software development managers as a group or individually, realize that it is nothing of a sort: I start with a brief analysis of the goal of such simplistic measures -- most organizations would like positions, including management, to be lower-skill and easier (cheaper) to fill, and such a simplification of the role is definitely in their interest, just as many dream of the panacea of no-skill, factory-type software development -- and then actually question the fact that developers themselves are often guilty of quoting these metrics. 9 times out of 10, developers have only themselves to blame for a lot of the problems with the profession. This is not yet another boring us-versus-them war cry pandering piece, like those that top the meme charts frequently]

The same methods -- if they worked as promised -- could be used to chart project progress ("We're 7868.2 ConsultaMarks towards the 11273.9 estimated for the entire project!").

Instead of relying upon the from-the-trenches observations of Randal the development group manager -- a grizzled vet of software development who manages with a hands-on style by becoming intricately aware of the domain challenges and unique contributions of each team member -- Lynn, the parachuted in middle manager, wants some simple numbers that can be sorted like her mutual fund returns, giving her some available sacrificial lambs when the next diversion-from-massive-executive-fumbles headcount reduction comes due.

Many proposed solutions have come and gone, with the most persistent being the infamous SLOC (Source Lines of Code)/LOC measure.

Source Lines Of Code

SLOC, if you haven't been afflicted with it, is an easily computed count of the number of lines of code in a given project/component/object (although first you have to agree on the definition of a "line of code", and this is a point of debate among SLOC champions). It's often used to count the number of lines of tested, complete code added by a particular contributor (easily accomplished with many source code repositories), allowing for the easy creation of nice little charts like the one above.

SLOC does have some quasi-legitimate uses: Given a common programming language and domain complexity, SLOC magnitude differences have a moderate correlation with general project size, and at the method level it is a rough indicator of gross complexity (see the article FxCop & Cyclomatic Complexity for a discussion of a loosely related metric, which is the number of intermediate language instructions generated from a method).

Applied at the individual or group level, usually as a cheap substitute for good management and project awareness, SLOC measurements are likely to encourage very destructive behaviors: Copy/paste coding, limited reuse of existing code found elsewhere in the organization and the industry, little motivation to prune code where necessary, overly convoluted coding, motivation for employees to only take on trivial coding tasks, and so on.

The Lemon Slice Lemon Roast

Envision a system that ranked cooks by the number of lemons they use to provide a restaurant's service each night: You're going to end up with a lot of dishes featuring copious stacks of lemons, even if ultimately it compromises the quality and organizational health of the establishment. While in some situations you could conceivably roughly compare overall restaurant success by the number of lemons they go through in a period, the comparison only holds true if all else remains equal (e.g. if otherwise the restaurants are very comparable, such as two restaurants serving Thai food): A deli restaurant might use very few lemons despite a healthy customer turnover, where an equally successful Greek restaurant might go through hundreds.

Far more logical would be to measure the number of dishes served -- while still imperfect, it would be much more useful than the LemonMetric. There is no comparable measure, with a similar level of granularity, as "dishes served" in software development (don't even think of mentioning the highly ambiguous "function point" metric as a simile).

Preaching To The Absentee Choir

"Geez...we all know that there are significant problems with the SLOC metric!" many will inevitably retort. "This is old news. You're preaching to the choir!"

"...but having said that, I saw a recent article that claimed that the average developer does {X} lines of vetted code a year. Are they really that slow? Me and my team must generate at least 20{X} a month! I hear that some superstars are responsible for 200,000 SLOC a year. They must be awesome!"

Comments just like that are probably being typed into a TEXTAREA at this very moment.

Why do so many comments about productivity -- even in the comfort of secret No-PHB hideouts -- inevitably elicit gloating commentary about personal SLOC accomplishments? Why do we hear gushing superlatives about the "superstars who push out 100s of thousands of SLOC a year"?

Why do so many in this industry perpetuate this destructive myth?

~SLOC

Let me flip this metric on its head, and state that, if anything, for a certain domain of project, and a certain class of developer, a high rate of SLOC can actually indicate poor programming practices.

In the nascent days of software development, many teams had a compiler or an interpret and that was pretty much it. They were responsible for building the majority of functionality from scratch. The pace of SLOC creation was tremendous (especially given that much of that implementation was trivial, allowing them to code as fast as they typed. Little time needed to be spent problem solving or planning: It doesn't require a superstar to code yet another string copy function).

As time went on, organizations compiled volumes of reusable internal code for all of their domain specific problems.

From an individual developer perspective, no longer was it acceptable to simply "run and start coding". Now you had to spend some of your time learning, assessing, and implementing shared internal code in your projects.

And it wasn't just inhouse: The frameworks and libraries provided with our tools have been growing by leaps and bounds, immediately solving a huge range of traditional problems and tasks with well tested, robust, feature rich solutions.

In the industry as a whole, code sharing has become widespread, with excellent code being available for virtually all common (and even uncommon) tasks.

So many solutions are available in the industry and supplied within our libraries/frameworks, that even organizational code reuse can be indicative of a problem.

Yet somewhere out there someone is hand-writing an FTP client implementation. Somewhere developers are wasting a tremendous number of man-hours by poorly, and unintentionally, duplicating code that exists in the frameworks and libraries that they're already using, or which can be easily found in license compatible open source projects.

Not Invented Here

A part of the reason for this is laziness -- it's a real bother having to look through the documentation and amongst search engine results, and that's hardly as much fun as just coding. Another part of the reason is a classic perception flaw that virtually all developers suffer from: Endless optimism about the capabilities and quality of the code we produce -- which we always think we'll finish much quicker than we really will -- coupled with an unreasonable pessimism about the applicability or worth of code we could source from another group in the organization, or from an external source.

I'm often guilty of these failures of perception, as are the overwhelming majority of developers.

Conclusion

Rarely does a developer actually tread across new ground (and I'm certainly not just talking about business back-end "CRUD" developers -- even in signal processing, embedded development, game development, and other less common branches of software development, most of the "solution" is the integration of existing work in novel ways, adding an envelope and façade of customization).

For the rest of us, our job is partly to generate the generally small amount of niche-specific code, usually aiming to build it with the most concise -- aka minimal -- code necessary, with the bulk of our time being in the analysis and integration of the extraordinary volumes of available solutions.

Where niche, custom code is necessary, generally it will be for a non-trivial task, and the SLOC pace will be unavoidably glacial.

For the overwhelming majority of developers in the industry, the only value of SLOC measures is as a warning sign, not an indication of progress.

My toddler son is a rambunctious little button pusher.

Where there's an On button to be pressed, he's there pressing it.

Again and again and again. On. Off. On. Off. On. Off...

He's an equal opportunity button pusher, so it isn't just power buttons that receive his attention (although he does show a definite preference for power buttons, having figured out the international icon most are adorned with). He also patronizes volume controls (thankfully the speakers have automatic cutoff circuits above a certain power level), input selections, DVD tray eject/return buttons, reset buttons, and every other interface element that affords pushing.

There's a limited ability to reason or debate with a toddler, and my warnings about the peril such activities presents to the vulnerable little ICs seems to have limited effect.

Enclosing every device in protective cages just doesn't seem reasonable.

So I end up with toonies ($2 coins here in Canada) taped over the power button of televisions (it buys a bit of time), computers with the power buttons disabled and the reset buttons disconnected, and for other devices (e.g. stereos, DVD players, radios) it's just a constant state of vigilance, with us ready to physically intercede when he prepares for a button mashing attack.

Oh, for want of a simple control to disable the front panel on these devices. Ultimately most of them are software controlled now, so a simple boolean IsIgnoreFrontPanel would suffice, perhaps with a complex 7-simultaneous-pressed-buttons override to re-enable the front panel.

It would save a lot of these devices the electronic stress of being constantly cycled.

On the same vein, I'd love for a "Microsoft Bob" style simplified interface for my preschooler daughter's PC. Even with the limited potential damage possible with the limited account she uses, context menus and unintended shortcuts are never intentional, and are always just a nuisance.

Various hypotheses have come forth to explain why we have a disproportionate number of ideas and epiphanies in the shower. Explanations as varied as guessing that it's due to the aromatherapy of shampoos, or the brain soothing effect of warm water on our scalp.

I have a simpler explanation: It's one of the very few times when we actually disengage from the world and think. Lathering and rinsing tends to be a very automatic activity, and given that we don't have the option of reading the paper or browsing websites, we're forced to converse with, and be entertained by, our own mind.

A similar result can be experience on your daily commute (this only really works if you drive by yourself, presuming that the traffic isn't infuriating and distracting. I've found commuter trains, buses and carpooling to have no such meditative effect, and instead to be highly detrimental to thought): Turn off the radio and just relax on the drive.

It is astounding how many decisions and ideas are resolved on a 30 minute commute in this island of tranquility. It is the activity closest to meditation in my daily schedule.

The Much Maligned Interview Process

The software development industry is known for its notoriously bad interviewing practices.

The reputation is well deserved.

Few industries put prospective candidates through the arduous, multi-part interview process that even entry-level software positions often require. Few professions demand that experienced practitioners, with a CV stuffed with academic and professional accomplishments, complete humiliating skill tests (usually scatter-shot testing whether the applicant happened to recently bone up on an esoteric area of a barely related niche), often under absurdly unrealistic conditions: It's sadly common for a candidate to be forced to write pages of code with nothing but a pen and paper -- despite the fact that most developer's hands cramp up after the first sentence -- supplying them with none of the normal development resources that they rely upon in the real world (forcing them to unrealistically recall the specific call patterns of seldom-used API functions, which is something that no real developer does in the era of online documentation, rewarding rote memorization while punishing problem solving and intelligence).

Many interviews feature smug "How To Move Mount Fuji" interviewers who are desperately trying to impress the candidate -- or their peers in the room -- by grilling the nervous applicant on whatever niche the interviewer happened to focus on that morning.

This is unfortunate.

While most shops are trying to hire intelligent, adaptable computer scientists, the interview process is often more suitable for the hiring of software technicians, which is perhaps why copy/paste, everything-looks-like-a-nail developers manage to hang on.

Yet for all of the well-founded complaints about industry interview practices, one oft-repeated complaint derives from a misunderstanding of the conversational nature of interviews.

[I'm spurred to write this entry after seeing a number of "idiot interviewer asked me about more than the limitations of a JavaScript closure!" atop the meme sites over the past few days]

What Would You Say Is Your Biggest Weakness?

Unless you were recruited right out of university, you've probably been asked that question, and you probably complained about it to peers in the real world and online. You have probably read others complain about the same. You've probably heard it and its ilk declared obsolete (and it is true that the backlash has generally sidelined this particular question, though it has been replaced by equally subjective personal questions) .

"I just BSd and said that my weakness was that I work too hard!" is a frequently heard comment about this reviled question.

So why do people hate this question so much?

Usually it comes down to a misunderstanding of the real purpose of the interview.

An Interview Is A Conversation

An interview isn't an objective fact gathering exercise: If the interviewer just wanted to ask what year you went to school and what your GPA was, or whether you'd used the masterpage functionality of ASP.NET 2.0, they'd give you an application or put it on the requirements list -- just like McDonald's would if you wanted to man the fryer -- and be done with it. Many job submission sites, industry wide and organization specific, do exactly that, getting applicants to concisely complete some structured data entry screens, describing exactly which skills they've used and to what level and for how many years, allowing technican style presorting based upon skills.

Instead an interview is a conversation. It's to determine how you think, how you converse, and how you interact, and to have a conversation about technology, prior positions and projects to gain information that can't be learned from a CV.

An interview is often a test to see if you're compatible with the firm. To see how honest and forthright you are on your feet. To test how humble or arrogant you are. To gauge if you have a sense of humor. To learn detailed facts about your prior experiences and exploits.

It's a bit like a first date.

So what is your biggest weakness?

Answering that you work too hard will often get you rejected as a liar, or as someone who is entirely unaware of personal weakness. Answering that you're a perfectionist -- another favored "I'm so clever that I game the system" answer -- again either implies that you're a liar, or worse that you really are a perfectionist (which in this industry means "someone who'll never, ever actually finish anything, always deflecting criticism by proclaiming that they're in the pursuit of perfection").

Giving an arrogant, can't-be-bothered-with-such-inanity response -- or a PC answer that alludes to the same -- could be considered useful in that it'll help the interviewer save themselves the time and trouble of dealing with a prima donna: If you don't have the time or patience to answer such a simple, obvious question, too sure of your pompous self-importance, then it's good that you set the rules for a very short game right away.

How then to answer? Honestly might be a good start.

"But if I answer honestly, the interviewer will pass over me in favor of the smooth-talking guy who claims that his biggest weakness is that he's too loyal!" you might retort.

While it is definitely true that sometimes interviewers are morons who happened into a position by luck, good looks or nepotism, your best bet is to assume that they're reasonable, intelligent, understanding people. Assume that they aren't fooled by applicants who pretend that they're perfection personified, and that they can understand that everyone has weaknesses, unique personalities and unique strengths.

They know that you aren't going to be a perfect worker that knows everything, can do anything, and is infallible.

And if the interviewer is a moron, it's probably in your best interest that they nix you as a candidate anyways (presuming you aren't really desperate): Do you really want to work at a place like that? (On a similar theme, if you really desire a certain percentage of telecommuting time, or you want a private office, or you demand triple-screens, ask for it! You'll either get it, or you'll avoid getting a job or environment that would make you unhappy: Both sides will walk away probably muttering "the nerve!", but in reality it's a Win/win).

Just be honest. Relax, and engage in conversation. If you think that an interview is going to be a walkthrough of your CV or questions about how many gas stations are necessary to serve a population 175,000 city, the vast majority of interviews are going to disappoint you.

I've been interested in two-factor authentication on the cheap as a technique to improve systems security for some time. My interest is primarily in making this technology available for marginal cost, with limited scale-out fees. This is a task that should be easy given the widespread availability of powerful mobile computation devices -- namely cellphones with J2ME -- and the ease of adding secondary authentication to most platforms (e.g. GINA authentication in pre-Vista, and Credential Providers in Vista and similar options on other environments. Adding two-factor authentication to a web application is a breeze).

Two-factor authentication, for those who haven't come across it before, is the addition of a secondary identity "proof" above and beyond the normal one-factor password. The purpose being to limit risk when user passwords are surreptitiously gained by nefarious agents, which could happen due to keyboard sniffers (a simple USB interceptor at the back of the target's PC could log weeks worth of keystrokes), trojans, use of public or compromised computers, password reuse or selection weakness, and so on.

Passwords alone are a really weak technique for system security.

The most well-known implementation of two-factor authentication are RSA SecurID hardware tokens -- or similes --  usually built as little keychain units that display a frequently changing, time-based access number (unique per token, so the central system needs to know which key went to which user). To log onto secured systems, such as banks and corporate VPNs, the user needs to enter not only their normal password, but also the code displayed at that moment on their token. So user sally logs on with her password 5gromet4u and her authenticator token is displaying the value 10492838, so she enters that in the pertinent login box. On the server the authentication service validates her password, and that the token that she was assigned should be what was provided (on the server side it's usually generous, allowing the authenticator token for a few minutes in the past and future to accommodate minor time skews, or Sally being slow entering the values).

The cost of these simple devices is usually absurdly high, however. Worse, the service software is usually pompous, overbearing, overpriced systems that take an absurdly simple need and make it a colossal pain to deploy and manage. This is irritating because the core technology behind such systems is absurdly simple -- hash the current date (truncated to a certain level of precision -- say every minute) together with a private value on the hardware token and convert to a BASE10 value to a certain number of digits (e.g. the first 8 digits of the BASE10 encoded hash). On the server end it knows the private value associated with each hardware token, and can perform the same process, so if the time is synchronized on both ends the hash values match.

e.g. here's my 3 minute C# version of a minute-granularity token generating method.

private string GetTokenValue(string userSpecificPrivateKey, int tokenLength)
{
    System.Security.Cryptography.SHA1Managed hash = new System.Security.Cryptography.SHA1Managed();
    byte[] hashValue = hash.ComputeHash((new UTF8Encoding()).GetBytes(System.DateTime.UtcNow.ToString("yyyyMMddHHmm") + userSpecificPrivateKey));
    string hashString = String.Empty;
    for (int counter = 0; counter < (tokenLength>>1) && counter < hashValue.Length; counter++)
    {
        hashString += ((hashValue[counter] / 256.0) * 100.0).ToString("00");
    }
    return hashString.Substring(0,tokenLength);
}

So if I've been assigned the secret, user-specific value of AF8CAD55JK9 (a value that was securely communicated and configured, or burned directly, into the token device and of course configured on the server, but then never spoken aloud or communicated again), then at 1:00 pm UTC on December 28th, 2006, the method will return the token 5864947577 for a token length of 10 digits.

So here we're all walking around with incredibly powerful cellphones featuring massive amounts of memory and computation power -- I still marvel to think that my cell phone has double the memory of my pimped-out 4MB Atari ST circa 1998 (which itself was 8x the stock memory), and features many, many magnitudes more computational power. At the time that Atari ST seemed infinitely capable -- and most cell phones promise tremendous flexibility and ease of expansion with the universal runtime of J2ME.

Surely to make such a token application for our cell phones should be enormously trivial. I've built GINA modules before, so that element is relatively trivial as well, and is only getting easier with Vista/Longhorn (Dear Microsoft - Where's my free Ferrari 5000 laptop for this Vista mention?)

So over the holidays I wanted a bit of a change from the norm, so I grabbed the NetBeans IDE and the mobility pack and then the pertinent Motorola SDK (all while deciphering a ridiculous array of often conflicting acronyms, and the version soup that is the Java world). All in all it was a remarkably simple and easy route to developing mobile applications, though I was a bit perplexed that I even needed a device specific SDK (I thought J2ME was sort of universal, beyond the basics like screen size/color support), meaning that widespread deployment would probably be far more difficult, with hundreds of possible builds being necessary.

Implementing the above into a J2ME application, displaying the current token value (changing every minute), along with some simple configuration options, was absurdly easy, despite Java not being a skill of mine. The slick little emulator worked wonderfully and displayed what the application would actually look like if it were running on my class of phone.

All in all the free J2ME development ecosystem has improved significantly since my last (abandoned) effort in this space, with some very slick tools and technologies.

Considering the enormous size of the market, it isn't surprizing.

Then I tried to deploy it to my cell phone. What a nightmare: Despite bluetooth and USB connectivity -- theoretically -- it was a complete no go.

The cell phone industry is a travesty. I went through this exact same exercise years ago, again giving up in disgust at all of the barriers that the cell phone industry in cahoots with the wireless providers put in one's way -- basically they do their damndest to limit the flexibility of the devices they provide (even though I bought this phone, and it is legally mine...not really sure how a provider has any right to put any constraints or locks on it. Of course I have the same thing with the Motorola PVR that I bought from my cable provider, again with various features and functions disabled by the cable company), trying to ensure that you're forced to do everything through their cost bloated network, buying from their grossly overpriced online stores, and application deployment has to happen through a system that ensures that they get a tremendous take even if their participation is entirely unnecessary.

To get this application on my phone I'd have to resort to a stack of basically warez-like software (from shady sources, spoken of in hushed voices) to circumvent all of the ridiculous constraints.

Once again I'm giving up at making the phone I carry around more useful. Maybe I'll look at one of those Windows Mobile phones (come on Microsoft! Where's my Acer Ferrari 5000!), which presumably offer more user control and flexibility.

Did you know that your PC can be immediately available while consuming less than 1/25th the power? Read on!

(If your PC already is configured to go to the proper S3 sleep, look below for some power consumption numbers for the various levels)

Coinciding with the recent, widely-linked WSJ article on power usage around the home, I happened to be anxiously awaiting my own power meter's arrival in the mail. In my case I wanted it for a different purpose (a complete article on that topic will be published shortly. For now I just wanted to author this post -- on the topic of S1-S4 power modes -- so I could reference it from the other post, avoiding long parenthetical sidetracks like this), however in doing research for the other article, some rather surprizing analysis was completed that I thought worthwhile to share.

My primary development desktop PC is rather obsolete: Athlon XP 3200+ on an nforce2 motherboard, 1GB, two hard drive (totaling 200GB), network card, nvidia 6600GT 256MB AGP video card affair. From an energy usage perspective, it's very comparable to most current PCs.

I've been meaning to replace it with a shiny new Core 2 Duo for some time, but the hassle of setting up all of my software again, configuring everything the way I like it, and so on, is a huge disincentive. Add the fact that my current PC never leaves me really begging for more power, so there's not enough drive to upgrade.

On the bright side, while I've procrastinated about upgrading, the state of mainstream computing has continued to march forward, so what I'm upgrading improves with every passing quarter.

I use my laptop quite a bit, but the machine described above is really the workhorse, and I generally leave it on throughout the day. I leave it on partly because I sometimes need to remotely access it, but more so because I tend to have the need to jump onto it to do short tasks throughout the day. Booting up on a need basis isn't acceptable as even the fast boots of today are still too slow, not to mention having to start all of the various tools that I use.

I used to rely upon S4 (hibernation), but even there the time to restore is too time consuming for these quick-hit usages. Add to that the occasional failure of hibernation to actual recover from a hibernation, locking up when the load is complete, forcing me to dump the state and reboot from scratch -- makes me very wary of the feature as a whole, though I realize it's more than likely an issue with a specific driver or piece of hardware that I'm using.

So instead lately I've been resorting to standby -- auto initiated at a preset interval of non-usage, and manually triggered when I know I'm leaving the PC for a bit. I presumed this was a substantial power savings.

With delivered power meter in hand, I finally had a chance to prove it one way or other. First I measured the "base load", when the PC is sitting on and ready for use (note that actually doing something causes this number of spike, sometimes substantially, so I'm intentionally indicating the idle power usage). This measurement is only the mid-tower consumption, and does not include monitors, speakers, etc.

Idle Power Usage: 129 Watts.

Wow. 129W just sitting there idling. That's about $10 of electricity a month. An ignorable cost, but when you've had conservation beaten into you it really makes me feel quite guilty thinking that my PC was consuming upwards of 100kWh a month largely doing nothing. What a waste.

Next I measured standby mode. In this mode the machine takes just a second or two to recover, ready for use (which I do by either sending it a Wake-On-Lan packet from remote, or by clicking the mouse/keyboard).

Standby (S1) Power Usage: 112 Watts.

Still 112W? Admittedly I was quite shocked that a non-functioning, non-computing PC, with hard drives powered down, could consume this much power. Sure this was a fluke; I did the same test on several of PCs and found the same marginal power savings in standby (S1) mode. This finding was entirely contrary to many sources that claim much greater efficiency of S1 mode.

All of the above was in Windows 2003 (and is the same behaviour on several XP machines I tested). I rebooted the same machine into Vista, and was shocked to find the standby mode consuming far less power (not to mention that it was audibly different -- it actually shut down the fans and such).

Back in Windows 2003, I started investigating why the disparity exists, and why I'm not seeing the power savings I should.

It turns out that XP, and thus 2003, identifies the power support on first installation -- determining which of the S# modes your machine supports -- S1 is the weakest power mode, S3 is a "suspend to RAM" mode (where power is cut to basically everything but the RAM modules, retaining system state with very little power), and S4 is hibernation, where the state is saved to the hard drive. Not only will it not automatically accommodate later changes (for instance BIOS changes), but apparently it very frequently defaults to only configuring standby to S1, even where the machine fully supports more. Furthermore, some configurations of USB devices will cause it to revert to the hoggish S1 standby mode.

My search brought me to a little Microsoft utility called dumppo.exe. With this, I could imperatively force the operating system to start using S3 sleep (given that my PC already supported suspend to RAM. Every new motherboard supports it, although some default to it being disabled in the BIOS). After running dumppo admin minsleep=S3 and rebooted, I put the machine into sleep and checked my power meter.

Sleep (S3) Power Usage: 5 Watts.

(I've scaled all of the power consumption values relatively, and the above says "5 Watts")

Not only is the machine using the same power in S3 sleep as it uses when it's completely off -- yes it does use 5W powering the network card and other motherboard systems even when it's "off" -- but the availability is impressive, with it coming completely to life instantly, and thus far reliably.

Again I use Wake-On-LAN to tell the machine to come alive remotely, making it immediately accessible from afar, and it's far more available than hibernation. Win/Win/Win!

A little utility and suddenly this PC is using 1/20th the power than the prior standby mode. Given the average usage cycle, this will drop monthly energy consumption for this PC from 100kWh to approximately 35kWh a month. Imagine the conservation an entire office building would achieve (consider that many IT departments unnecessarily mandate that all PCs are on 24 hours a day to allow for automated off-hours patch deployments).

Not everyone will have this particular problem (with S3 not being recognized by the operating system), but some quick checks of PCs under my control and among friends and family has demonstrated this to be a ridiculously common scenario, so I thought it worth an entry.

1. [INDEX OUT OF BOUNDS EXCEPTION]
2. [INDEX OUT OF BOUNDS EXCEPTION]
3. [INDEX OUT OF BOUNDS EXCEPTION]
4. [INDEX OUT OF BOUNDS EXCEPTION]
5. [INDEX OUT OF BOUNDS EXCEPTION]
6. [INDEX OUT OF BOUNDS EXCEPTION]
7. [INDEX OUT OF BOUNDS EXCEPTION]
8. [INDEX OUT OF BOUNDS EXCEPTION]
9. [INDEX OUT OF BOUNDS EXCEPTION]
10. [INDEX OUT OF BOUNDS EXCEPTION]