• 16:43 Downloading yet another IE 6 VHD. Bonus: IE 8 beta VHD.
• 16:52 Fyi - IE VHDs - tinyurl.com/y64upm

Automatically copied from http://www.twitter.com/jenk3 via LoudTwitter cause it's easy :)

Faulty character set for text messaging results in misunderstanding which results in assault and death.

Because of course if an insult is on a computer / cellphone screen, it must have been deliberately sent and cannot have been a bug or typo. And of course an insult cannot be mended with an apology.

There are days when I really do not understand humans.

...is that often the metrics aren't what you really wanted. In tech support, "shorter calls" were a big metric. Shorter calls meant more customers were served and problems were solved more efficiently, right? Right?

Some calls, yes. Perhaps even the 50% or 80% most common calls. But not the less common calls. Not the troublesome calls. Those took longer, and one 1/2 hour call would screw up your stats for the day.

"Of course you should take the time to do the job right, just not more time than necessary," management would chirp. And yet the rewards went to those who did the job quickly - and not necessarily well. Since people repeat the behavior that gets rewards, this led to less service.

In testing, focusing on bug counts can be a similar problem¹. My first test lead didn't look at how many bugs were reported by each individual on his team. Instead, he read every bug reported by his team. He found it was very clear who was breaking bugs into tiny little bits so's to inflate bug counts (often a habit acquired elsewhere), who was sloppy in figuring out repros, who was noticing that two different symptoms had a common cause and reporting it as such, who was mostly finding bugs in areas other than their own (which if a conversation determined their area just didn't have many bugs to find could be a good thing) and so on.

Of course, it was expected that a test lead would read and know all the bugs for the areas covered by his team. And my first test lead did so. Among other things, this made him aware of what was being reported by those not assigned to test the area. (Often these were bugs on areas that weren't officially released for testing yet and such. But sometimes it was a clue that tests needed revising.)

Sometimes the focus on bug count goes beyond using it as a measure of tester productivity. The Defect Black Market relates just one example. This Dilbert shows a slightly less, er, subtle approach.

¹The problems with using bug counts as a measure of tester productivity are discussed in-depth in Testing Computer Software by Kaner et al.

Oklahoma sex offender registry exposes and executes SQL statements in the URL, enabling downloads of social security numbers, birthdates, addresses, et cetera. Who knows, maybe their site executed INSERT statements too.

Nobody accessing sensitive government databases should assume that users don't know SQL. And yet.

...from The Wall Street Journal:

Talk to your information-technology department before you post naked pictures of Lindsay Lohan on your business’s Web site. The latest reminder of this ironclad rule comes from New York Magazine, which posted photographs of the 21-year-old actress recreating one of Marilyn Monroe’s more scandalous shoots on its site yesterday. (Sorry fellas, the link is to an article.) The site, which was promptly overwhelmed by art-photography fans, ground to a halt. It’s a classic Internet-age problem: The marketing department has some promotion that is bound to drive traffic to a site, but never bothers to tell IT. So the site crashes. In a testament to human nature, these incidents often involve scantily-clad women, such as the famous Victoria Secret online fashion show that nearly brought down the Internet in 1999.

I've been on both sides of that equation - both times involving that little low-traffic domain called microsoft.com. ;)

Microsoft wants to dilute its earnings by acquiring Yahoo and Sharper Image files for bankruptcy. Gee, guess it is a new millennium.

Giving this a try ;) I may be pleasantly surprised that I'm not the only one on my flist who's done some of these.

1. Been handed a bottle of nitroglycerin while student driving.
2. Changed from "drag king" to femme in a classroom without anyone noticing.
3. Read programming textbooks to a room full of smalls as a "naptime story".
4. Rebuilt DOS boot sectors and partition tables over the phone using debug.
5. Found and fixed a bug in CHKDSK.
6. Written a device driver to test another device driver's initialization routine.
7. Written code for the Windows 95 Plus! Setup program.
8. Purchased front-row Springsteen tickets in a charity auction.
9. Led documentation for a Windows Service pack.
10. Purchased original Dykes To Watch Out For art from Alison Bechdel.

I'm surprised there's that many msft memories on that, given all the current & former msfties on my flist (particularly stealthcello :)

I haven't run the Windows debugger (or the Windows debug kernel) since I quit being paid to do so in 1999. But when I did, I made use of crib notes created by Raymond Chen, a Windows dev who also opened a wide variety if interesting and useful bugs.

A few days ago, Raymond reviewed the book Advanced Windows Debugging, stating that "Even the section with the "Oh come on every moron knows this already" title Basic Debugger Tasks has stuff that I didn't know."

Eep.

So if you're doing Windows programming and stepping through the code in the IDE isn't enough to figure out what's going on ... if you're dealing with, say, a deadlock or heap corruption ... this might be the book for you. :)

Seattle Weekly article on the day labor side of testing, games testing in particular. Reading the article, it's not clear if the writer thought this was a "slice-of-life" article or an exposé.

As exposés go, well, maybe I'm jaded. Sure, it's not a job I would want. On the other hand, it sounds better than other jobs I've had. In the late 80s, I got $6/hr for kid wrangling at a non-profit. According to the BLS, low-level child care a median wage of $8.25/hr now, comparable with the low-level games testing discussed in the Weekly.

Duties? I would keep 10 preschoolers engaged and safe. I also tied 8 or 9 pairs of shoes at a time; cleaned kids (with wipes) and cots (with Lysol) after "napping accidents"; made lunch or snack for 100; cleaned tables, chairs, and the floor after 100 kids had lunch; held a screaming kid under the sink while washing sand out of his eyes (had bruises for a week after that one); carried upset or sick kids; read out loud a lot; organized; cleaned; turned jump ropes; et cetera.

And, of course, there's also the bit about how screwing up as a games tester means a support call, maybe a recall, or being fired. In a day care, negligence can cause a child's death.

Not that child care is the worst job in the world, either. Yes, you deal with bodily fluids (and yes, waste solids) fairly regularly, but they are pretty well contained. Working in a center meant I had other adults for comradarie and assistance. As jobs go, it was steady, had flexible scheduling, and included vacation, sick time, and health insurance.

But I can't help wondering if an article on how day care isn't all hugs around the knees and experiencing wonder through the eyes of children might be a nice companion piece to the one on how low-level games testing isn't the happiest job on earth.

On INTERCAL:

This ridiculous esoteric programming language was designed as an unpronounceable satire of FOTRAN and COBOL (yes, it's old). Everything about the language is absurd. From the form of the manual, which contains a "tonsil," as explained in this footnote:

"4) Since all other reference manuals have Appendices, it was decided that the INTERCAL manual should contain some other type of removable organ."

The language also uses modifiers such as "PLEASE," which if not used frequently enough is rejected by the compiler as insufficiently polite, and if used too much is rejected for being excessively polite. More frustrating still, was the fact that despite the existence of this feature, it was undocumented in the manual.

As a practical language, INTERCAL is Turing-complete, meaning it actually works. But if you're planning on actually trying to use INTERCAL you should first check your sanity, and you should be prepared to wait a long time. A Sieve of Eratosthenes benchmark, computing all prime numbers less than 65536, was tested on a Sun SPARCStation-1. In C, it took less than half a second; the same program in INTERCAL took more than 17 hours.

- from Ghosts in the Machine: 12 Coding Languages That Never Took Off

"A busy CPU is a happy CPU. Leave it running [pseudorandom tests] all weekend, it'll be happy to see you Monday." - Harry Robinson from Google, talking on "The Bionic Tester"

"I am certified to practice law. This means I can be sued for malpractice. I like this." - Cem Kaner

I start posts on this and then get busy and abandon them. A few folks who have posted are here.

... according to PC Magazine. Of these, I worked on:

Windows Update. #6 on the list. My involvement is more periphery: the IE 5 setup program was used as the initial "guts" of Windows Update; I was IE 5 setup test manager. (Which made integrating IE 5 into a Windows Update deliverable a bit weird at times. But easier than integrating IE 5 setup into Office 2000 and Windows 2000 ... )

Explorer. #11 on the list; I'd put it lower, but that's me. My involvement: IE 4 shell test lead, which included the HTML-ized version.

Active Desktop. #14 on the list; I'd put it higher. My involvement: IE 4 shell test lead, which included Active Desktop. (And what is Vista's Gadgets, if not AD under a new name?)

DriveSpace. #20 on the list; I'd put it lower. My involvement: Helped test DoubleSpace/DriveSpace in MS-DOS 6, 6.2, 6.21, 6.22, Windows 95, and Windows 95 Plus!, where "help" means "I don't own the area, but I keep getting dragged into it anyway."

From a co-worker comes this quote:

"Logic and reason are wonderful virtues,
but they are irrelevant in describing human behavior.

We have to design for the way people really behave,
no as we would prefer them to behave."

- Don Norman, author of The Design of Everyday Things

;)

Something tells me the jurors who convicted a technologically incompetent substitute teacher of showing porn to 7th graders haven't had to deal with adware. Julie Amaro now faces up to 40 years in prison; sentencing will be on March 2.

It's also rather stupid that the defense counsel didn't provide full disclosure of its forensics evidence, preventing it from being presented during the trial. Not to mention that the school's firewall software had expired. As had the antivirus program. And the computer had no anti-adware tools. Win98 and IE 5 don't need any of that - just ask Microsoft. (Pop-ups? What are those?)

So, of course, the only way for the adult-themed images and Web pages to come up would be for her to intentionally visit the sites by clicking on a link or typing the address into the browser address bar. 'Cause the prosecution's expert, a local police officer, said so.

Right.

Something tells me Julie Amaro isn't the only technical incompetent in the group. She's the just the only one who admits it.

-o-

And if you're wondering why I linked to Microsoft's info on security and spyware — the school is using Microsoft software. One would think the "experts" running the school computers and/or police forensics would be aware of the vendor's information on the subject.

From Microsoft TechNet:

Internet Explorer 7 will be delivered through Automatic Updates - customers should complete preparations by November 1

Published: July 26, 2006 | Updated: October 15, 2006

To help customers become more secure and up-to-date, Microsoft will distribute Internet Explorer 7 as a high-priority update via Automatic Updates and the Windows Update and Microsoft Update sites. Internet Explorer 7 will be available for users of genuine Windows XP SP2, Windows XP 64-bit Edition, and Windows Server 2003 SP1.

This announcement provides an overview of the delivery process and options available to IT Administrators to prevent delivery of Internet Explorer 7 to their organization through Automatic Updates. Customers wishing to block the delivery of Internet Explorer 7 into their organization should have blocking measures complete by November 1. Distribution of Internet Explore 7 by Automatic Updates will take several months to complete. Microsoft will revise this announcement with more information in the future. [...]

Also:
IE 7 home
TechNet's IE page
IE blog
and just cause I thought it was cute: http://www.ie7.com/ ;)

Seriously. I got it from the Microsoft Support Knowledgebase.

( If you're running a console app in full-screen mode and hit print screen, the bitmap is made - but not printed, and not released. AKA, memory leak. And if you, say, hold down the key.... )

Really, you have to wonder if someone's cat was involved in finding this one...

I ran across this quote in a software testing article at Jonathan Kohl's blog.

Weinberg's "Rule of Three", which goes something like this: if you can't think of three ways a potential solution can fail, you don't completely understand the problem space.

Google found a couple other variations.

Jerry Weinberg says, “If you haven’t thought of three possibilities, you haven’t thought enough.”
- quoted at stickyminds

and

Whenever I'm aware that I'm making an interpretation, I have another choice: I can allow myself to know that more than one interpretation is possible. A good check on premature interpretation is the Rule of Three Interpretations:

If I can't think of at least three different interpretations of what I received, I haven't thought enough about what it might mean.

This rule slows down the Interpretation step and gives me, the receiver, a chance to engage my brain before using my mouth. Even after I have thought of three possible interpretations, however, I should always be aware of one more possibility: that my list still may not include your intending meaning.
-- Jerry Weinberg, Quality Software Management Vol 2, Chapter 6, quoted here

So, here are three varations on the Rule of Three...appropriate, no?

David Gilbert discussed applying hurricane forecasting methods to software. One thing that caught my eye, that he says he has "NEVER seen [in] any model of software planning", is "The Cone of Uncertainty".

Starting at the point where the storm is now, following roughly along the predicted path of the storm, is an ever expanding cone. This cone represents where, given all the information currently available, the storm MAY go if something in the model changes. [...T]his is the part of the model that forecasters talk about the most, and encourage everyone to pay the most attention to. This is the part of that model that takes into account Risk and Ambiguity.

Shipping software is ambiguous, and taking that into account is a good thing. But (to continue the metaphor), project management is all about getting to a particular destination at a particular time; tracking a hurricane is trying to see where & when it will arrive.

But perhaps there's room for both. Yes, aim for the goal. But also track the "cone", and forecast how far off track the project may currently get...

This week joelonsoftware is tackling management strategies for software companies. Today's is "Command and Control", based on military management.

[T]he military uses Command and Control because it’s the only way to get 18 year olds to charge through a minefield, not because they think it’s the best management method for every situation.

In particular, in software development teams where good developers can work anywhere they want, playing soldier is going to get pretty tedious and you’re not really going to keep anyone on your team.
- full article

One of the prereqs for making C&C work is that the underlings can't leave. The military, in general, has that prereq. Most other jobs don't. I've seen C&C used in software. Some of my coworkers, especially the ex-military, seemed to find it reassuring. I didn't. Fortunately for my ex-military boss, he did know when to shut up and listen to the technical expert, which in that case was usually me. Eventually he even grasped that he couldn't micromanage us all effectively....

As a side note, I find it interesting that someone whose military experience was in the Israeli army used a photo of white crosses to illustrate this article....

For the softies & ex-softies out there who've read Dan Brown: The Microsoft Code ;)

Dunno if anyone else would get it, but, um...so?

There's a lot of testing buzzwords that just make me sigh. But I like "Context-Driven". The link has good info, but the example was the "aha" moment for me:

Consider two projects:

1. One is developing the control software for an airplane. What "correct behavior" means is a highly technical and mathematical subject. FAA regulations must be followed. Anything you do -- or don't do -- would be evidence in a lawsuit 20 years from now. The development staff share an engineering culture that values caution, precision, repeatability, and double-checking everyone's work.


2. Another project is developing a word processor that is to be used over the web. "Correct behavior" is whatever woos a vast and inarticulate audience of Microsoft Word users over to your software. There are no regulatory requirements that matter (other than those governing public stock offerings). Time to market matters -- 20 months from now, it will all be over, for good or ill. The development staff decidedly do not come from an engineering culture, and attempts to talk in a way normal for the first culture will cause them to refer to you as "damage to be routed around".

Testing practices appropriate to the first project will fail in the second.
Practices appropriate to the second project would be criminally negligent in the first.

The testing is designed for the project, not the project for testing.

I ran across this at Testing Reflections:

Lesson 1: Know your enemy

• Lack of Quality is not your enemy, it’s [the] developers enemy. Your enemy is absence of evidence of it.

Lesson 2: Know your equipment and how to use it

• Armour: standards, guidelines (universal defence against any attacks)
• Shield: test [plans], test cases (when used properly may block some attacks by “the enemy” – do you remember who is an enemy?)
• Sword: testing - test execution (use to attack the enemy)

Lesson 3: Choose appropriate equipment

• Good armour reduces movement.
• Shield decreases offence.
• A single soldier may use long sword (knight) or two swords (samurai)…
• An army [can] use good armour, big shields, normal swords

A lot of this makes sense. Lesson 1: We are looking for facts. Lesson 3 is about tradeoffs...and how test plans are like battle plans - they don't survive initial contact unscathed!

Other thoughts?

Myth: Passwords Must Be Complex to Be Strong.
[...] Of course passwords need to be complex to be strong. No, they do not! They need to be looooonnnngggg. In fact, really, really, long passwords, by their very nature, are often much stronger than a short but complex password. ( complex example )

Now consider this password: SeandialVickyandhorusbloomkendallWyoming. It is not complex by any measure. It contains only two character types and all of the components are words. They are, in fact, words picked from the Microsoft password strength checker’s dictionary, which includes 2,254 words. ( ... ) Let’s say you even know that it is picked from the password checker dictionary and that you know there are eight words in the password. That improves your ability to crack it significantly. It will now only take 1,948,790,798,336 years to crack. If we remember correctly from physics class, the universe is about 5,000,000,000 years old, so that means it will take you 390 times longer than the existence of the universe to crack this password, assuming you don’t have to restart your computer to apply a service pack before then. Since our policy forces us to change passwords every 90 days, there is a pretty good chance we will have changed passwords by the time you are finished cracking it.

Of course, the fact that I find this funny might just show I'm not normal.

Source: Microsoft TechNet, emphasis added.

Raymond talks about some locale-specific notes on number formatting, including that China & Japan group in fours. So the US number 12,304,567.89 would be

1230 4567.89

in China or Japan.

I thought this was interesting. But then I have been told I have weird values for "interesting".

I also liked this comment:

Travel broadens the parochial mind you never knew you had, and makes you a better programmer/designer/techie.

As a bonus it also exposes you to better beer.

from joelonsoftware, talking about software company management:

( Companies need infrastructure ) and if your programmers even spend one minute thinking about this that's one minute too many. ( ... ) That's why you have management.

It's for the kind of stuff that no company can avoid, but if you have your programmers worrying about it, well, management has failed, the same way as a 100 foot yacht has failed if the millionaire owner has to go down into the engine room and, um, build the engine.

( Some companies are too sales-focused, others are too code-focused )

Both of these companies can easily be wiped out by a company that's driven by programmers and organized to put programmers in the driver's seat, but which have an excellent abstraction that does all the hard work to convert code into products below the decks.

A programmer is most productive with a quiet private office, a great computer, unlimited beverages, an ambient temperature between 68 and 72 degrees (F), no glare on the screen, a chair that's so comfortable you don't feel it, an administrator that brings them their mail and orders manuals and books, a system administrator who makes the Internet as available as oxygen, a tester to find the bugs they just can't see, a graphic designer to make their screens beautiful, a team of marketing people to make the masses want their products, a team of sales people to make sure the masses can get these products, some patient tech support saints who help customers get the product working and help the programmers understand what problems are generating the tech support calls, and about a dozen other support and administrative functions which, in a typical company, add up to about 80% of the payroll. It is not a coincidence that the Roman army had a ratio of four servants for every soldier. This was not decadence. ( ... )

Management's primary responsibility to create the illusion that a software company can be run by writing code, because that's what programmers do. And while it would be great to have programmers who are also great at sales, graphic design, system administration, and cooking, it's unrealistic. Like teaching a pig to sing, it wastes your time and it annoys the pig.

I added the bolding in that last paragraph because I think it does a great job of explaining what needs to be done in the software business besides making great software - in fact, what needs to be done in most businesses. It's stuff that most people don't think about because, usually, no one individual does it all. But it's the stuff that can make-or-break useability, sales, operations, and employee satisfaction. As Joel goes on to say,

Microsoft does such a good job at creating this abstraction that Microsoft alumni have a notoriously hard time starting companies. They simply can't believe how much went on below decks and they have no idea how to reproduce it.

I would amend that to be most people who have worked at successful companies have no idea how much is done outside their own area...and have no idea how to reproduce it.

Full article: here.

This is really for me, but I won't stop anyone else from reading it ;)

( Two ideas dominated his work. ) The first had to do with “empowering” workers. Mr Drucker believed in treating workers as resources rather than just as costs. He was a harsh