QA Hates You

Everybody has focused on the fact that the new CEO of Yahoo! has ended telecommuting in the company, another soul-crusher occurred at Harley-Davidson: they banned rock and roll music:

Hundreds of Harley-Davidson employees learned through a memo last week that their radios and music being piped onto the factory floor would be kaput by Wednesday — part of a continuous effort to improve safety.

No headphones. No headbanging. No rock ‘;n’ roll.

Just the sound of motorcycles being made. It’s the sweet sound of productivity for a Fortune 500 firm whose earnings have made a comeback since an organization-wide restructuring began in 2009.

But it wasn’t one incident in particular that made them “stop the music,” as singer Rihanna says.

“It’s a distraction,” said Maripat Blankenheim, director of external communications for Harley. “It’s really important for people – no matter what they do – to be focused on what they do.”

The memo, authored by John Dansby II, vice president for manufacturing, reflects that mantra.

“As you are aware, it is imperative that we improve our safety and first-time quality performance,” he writes. “Too many distractions and potential hazards still exist in the workplace that impact our performance every day.”

Jeez, Louise, what will people at Yahoo! do if they cannot blare AC/DC while they test?

You know, when I worked in a plant, we didn’t get radios, and I had to compensate by tacking up a poem to memorize while the Didde-Glaser ran. That experience pacing and talking to myself provided me with valuable experience I apply to QA every day.

(Part I, Part II, Part III, Part IV)

Brad, the Middle Manager
I eventually moved on from the blue collar world (and, if we’re counting, the pink collar world, since that’s the color sometimes assigned to retail work) into the white collar world, although by the time I got there, business casual was the norm and the collars were not often white. Now, in many places, the collars at all are optional. I made a couple of moves from technical writing into software quality assurance, back into technical writing, and then onto Brad’s team as a Quality Assurance Analyst I.

Brad managed a team of Quality Assurance Analysts working on a chemical modeling and lab benchtop software suite for a large pharmaceutical firm. By the time I got into my cubicle, the project was late and on the verge of losing money, but that was beyond my purview. That was in Brad’s world, as it were.

I don’t know Brad’s background, but I do know that it was not anywhere in the technical realm of software. He did have an MBA, though, and when the company was hoping to move from a product-based business model (you build it, you sell it, people buy it) to a project-based business model (you promise to build it if someone promises to pay for it), it staffed up its ranks, including its management team. The org chart featured a vice president in charge of projects, a director in charge of projects, a bunch of managers in charge of teams on the projects (at this time, the plural form of project was still only anticipated, and the only actual project, as I mentioned, was in trouble), a set of leads on each team, and then team members. That’s three tiers of management where technical skill was optional, and in Brad’s case was sorely lacking (although his hiring of me proved his keen insight into the matters of personnel).

As far as I could tell, Brad’s main job duties included sitting in meetings with other managers and sometimes team leads (but not the actual meetings with technical staff—the team lead took care of that and assigning roles and day-to-day duties). I am pretty sure he made some PowerPoint presentations and reports of some sort, along with annual goals for the team and individual reviews of his team. But he pushed paper and handled the Parkinson duties of the team.

An anecdote into interacting with Brad: I wanted to buy a $35 text editor that I’d used before to help edit the various and sundry text files a Quality Assurance Analyst I would edit during the course of the day, such as configuration files, batch files, and the special files used by chemical modeling software import features. I told Brad I’d like it. He put it into his process and workflow, and he wanted a business case for it. So I wrote a document that included a comparison between the installed text editors, Microsoft Word and Microsoft Notepad, the advantages of the text editor I wanted (IDM Software’s UltraEdit—since I’ve named its competitors already loaded onto my workstation at the firm, I might was well offer an unsolicited testimonial to it). The document identified all the text files I’d edit with it as well as future uses for it (including the buzzword XML, which would prove important although not relevant at the time).

After reviewing the document, Brad called a meeting of the Quality Assurance Analysis team to discuss it. Before that meeting, though, the team lead called a pre-meeting to discuss it. The four QA team members gathered in a meeting room to discuss what a text editor was and why QA might need it. The importance of editing the data files we’d need to test or reviewing log files was a bit lost, but I mentioned XML, the buzzabbreviation took off. Although the product did not use eXtensible Markup Language now, someday it might. The buzzword traveled up the food chain, and Brad turned the either approved or got approved the purchase.

The process to approve the purchase cost more than the purchase itself, but it was the sort of thing that filled Brad’s day. Until the company, trimming its headcount to stave off the disastrous consequences of its altered business model, cut Brad during a set of layoffs. After that time, the QA Team Lead reported directly to the Director or the Vice President with no productivity loss.

Unlike Ron, Brad was not lost in the trappings of being a successful businessman; Brad was lost in the trappings of being a manager. Brad illustrated to me that managing people doing a task works best if you understand the task at hand and don’t get yourself into a situation where your only skill is holding meetings, preparing papers, doing group projects, and doing the sorts of things that earn you an MBA or used to suffice when you reached a certain level within a very large corporation.

In today’s fluid, lean business world, you have to make sure that you grok the thing you manage and that you can improve the efficiencies and add value to those under you. I kept this in mind when I reached the executive level and spent my time helping my people solve the problems they found in their jobs and increasing the company’s efficiency by boosting the employees’ efficiencies. If I didn’t call enough meetings, so be it. The point of the job was to do the job, not to talk about it.

Conclusion
You can read a hundred books about good business practices, but the lessons within them will only be the abstract knowledge distilled from a cavalcade of someone else’s success. The stories and ideas within them might slide from your consciousness like raindrops from a freshly washed (with the deluxe package including the clear-coat sealant) car. Even when you look back to the good bosses you’ve known personally and have worked under will seem translucent in the pleasurable glow you had from working with them and succeeding in your position therein.

But the lessons you learned from your bad bosses are distinct because they were painful. If you, with enough therapy, can look to them to understand why your bad bosses were bad bosses, you can be a better boss yourself. I’m not talking about studying the psychological motivations or getting in touch with them emotionally to understand what compelled them to behave as they did; I’m talking about understanding why what they did was ineffective as a manager or leader.

Besides, they took a little bit of your soul in those brief hours/days/weeks/months/years you worked for them. Shouldn’t you take a little something back?

(Part I, Part II, Part III)

Lee, the Purchaser
The art supply store hired me as a shipping/receiving clerk, which was mostly checking in the supplies as they came off the truck to make sure that Koh-i-noor had sent us the number of pens they said they did and the number of pens we had actually ordered. The store catered to the business community who needed foam board for presentations and to students who needed specific pads of paper for their art classes. In addition to clerks, commercial inside sales people, and a shipping/receiving clerk who was also responsible for custodial duties, small computer administration, and miscellaneous electrical repairs, the store had a dedicated purchaser, an employee whose full-time endeavor was to map the sales of individual products and to order enough to meet anticipated demand. Her name was Lee.

In the early 1990s, personal computer usage was in its infancy, and the store’s inventory was maintained on a minicomputer with thin client terminals. Lee printed out reams of product lists to use as she checked the back stock and the items on the shelf to make her predictions, which were more astrological than based on past sales.

In the late summer, as the store was preparing for the back-to-school rush that produced much of the annual sales, a truck arrived with pallets of paper products, from notepads to 4’ by 6’ boxes of heavy cardstock. The receiving room of the store could handle about 3 pallets of product comfortably. This particular load comprised 14 pallets, including two double-sized pallets containing bins of foam board. The truck driver mercifully left his trailer at the exterior loading dock for a half hour lunch to give the receiving clerk the chance to restack and rearrange pallets to fit six pallets uncomfortably into the warehouse.

“Why so many?” Lee asked, incredulous. She carried a printout of the expected order. The receiving clerk took the papers from her and pointed out how the four on this line translated into so many cubic feet, how the ten on this line translated to so many more cubic feet, and so on. The order matched the delivery.

Fairly often, we worry that someone has forgotten to take the customer into account when making plans or acting. However, Lee, working with numbers in the abstract and little ticks on lines on sheets of paper, became divorced from the realities of the product. The concrete products that filled the warehouse and many backaching hours for the receiving clerk as he somehow fit these products into slots and shelves to make the warehouse navigable.

Lee taught me to remember the customer and the product. In too many instances, particularly in the software industry, the customer-facing professionals keep the customers too much in mind and have little understanding of the technologies of the product or even the things for which the customers will use the software. Instead, their focus remains on pleasing the people who place the orders, and they might find themselves promising more than their teams can deliver. Much like Lee might.

(Part V)

(Part I, Part II)

Ron, “I Own the Business”
Ron was an older gentleman operating a computer assembly and sales business from a converted shotgun shack in the southwest corner of St. Louis. The living room was what you might call the commercial sales division with three desks and tables piled with papers and unopened mail. Ron was not very organized. The dining room was a retail sales floor of sorts with a number of custom assembled machines on display to, generally, nobody. The old kitchen held the bookkeeper and the woman whose sole job was filing return material authorization requests for the cut-rate components that Ron favored. An addition and shed that filled the former back yard held a number of young technicians assembling computers and slightly older technicians repairing computers. The one car garage facing the alley was the loading dock, with a desk for the receiving clerk to check in and label individual components to make it easier for the RMA lady to process when they came back and steel shelves that held a number of broken bits of computers Ron accepted in trade. Piles of boxes littered the floor, since the receiving clerk discarded packing material over his shoulder as he worked. Ron hired me to be a clerk Friday, which meant to do whatever he wanted. In my three months there, this included filing copies of invoices from years past, acting as accounts receivable by calling, without training in the niceties or legalities of bill collection, numbers printed on inches of fan-folded, pin-fed, green-and-white lined paper, receiving (and receiving a tongue-lashing for wasting time in cleaning up the loading dock), computer delivery or pick-up in the far-flung suburbs of St. Louis, and ultimately as a computer assembler when one left in a fit of apoplectic pique.

Ron was the worst boss you could imagine: His self-importance and scattered brain combined to provide moments where he would cross from the front office through the showroom to the accounting room to get the accountant to get “that guy” (the clerk Friday) to come to place a telephone call for him. Instead of coming to get “that guy,” the accountant instead made the call from her phone to ask the call recipient to hold for Ron. Another time, Ron came up to me as I was stocking parts, and led with a noun of direct address to address me directly: “Mark,” he said, gesturing at me. “Brian,” I corrected. “Mark,” he continued, wondering what the gag was. Ron fired me, essentially, by telling me that I would not be needed after Christmas when I told him I was taking the week of Christmas off to have dinner with my father 400 miles away. My father was in a brief remission from cancer that would prove terminal, and my brother had leave from the Marine Corps. I took Ron seriously, unlike one of the sales people who brought in doughnuts every time Ron fired her—and Ron’s wife assured her that she was not fired. But on the Monday of the week after Christmas, Ron called me at home the first work day after Christmas to find out where I was. After I could not convince him that he fired me, I quit over the phone. “Without any warning?” he asked.

I’m sorry to go on so long about Ron, but he is a treasure trove of stories that seem parablic, but actually happened.

Ron’s business stayed afloat not because of Ron’s business acumen, but because of dedicated employees led by Ron’s wife who kept the business going and managed its transition from a business forms printer into a computer dealer in the early 1990s as the business world was rapidly transitioning to desktop computers. The core of loyal employees kept the business a going concern, so some amount of bluster and possible incompetence at the top might not be fatal for a business, but it does make a difference. Ron also reminds me that too much in the trappings of success and importance—spend four minutes to get that guy to dial a telephone—impede progress and efficiency. One really has to gauge whether additional staff and whatnot actually improve efficiency or whether they merely prove Parkinson’s Law.

(Part IV to come)

(Part I.)

Mike, the Telemarketing Manager
Part-time telemarketing fundraising is a tough gig. Wearing a headset, one sits at a table with a computer monitor and keyboard. A mainframe or server somewhere dials a stream of telephone numbers, and when someone answers, the monitor displays information about the person along with the approved script for the fundraising customer. One then tries to sound as fresh and chipper to this potential mark, I mean “donor,” as one did when one started the shift ten and a half hours earlier. Success ebbs and recedes—one gets a couple of the voices on the line to agree to joining the society or supporting the law-enforcement fraternal organization, and one gets confidence that translates into further sign-ups, or one gets a string of hang-ups and angry voices whose ire deflates one’s confidence, which breeds further lack of success. After darkness falls, the calls stop, and the person with the lowest total for the day empties the trash cans. It’s low-rent Glengarry Glen Ross with less swearing and less individual opportunity.

Mike, the manager of the roomful of twenty or so twenty somethings happy to be working outside of retail, was missing his front teeth. A homemade tattoo of his prison number colored the inside of his wrist. The tattoo, he told us, was so that when he got angry in his car, if he reached for the illegal gun under his dashboard, he would see the tattoo and think twice. He boasted that the only two things he had not been to jail for were rape and murder.

Colorful nature aside, Mike was not actually a bad boss. He was a boss in a bad workplace, a workplace that suffered enough turnover that the newspaper carried a running ad for telemarketing fundraisers, and the shop had new interviews—and empty chairs—daily.

Mike, though, was good at the job. His deep, resonant telephone voice bred success as a telemarketing fundraiser. Eventually, he worked his way up from the interchangeable tables through the PCs (previous contributors list, a special phone list of people who had given to the campaign in other years and were expected to be easier marks, I mean “donors,” in successive years) to managing the stable.

Mike demonstrated that one’s past is not necessarily relevant to one’s ability to perform in a position. The right confluence of talents and drive can lead to success regardless of other less savory incidents or experiences. When looking for someone to fill a position, or whether judging someone’s abilities at one’s current job, one must focus on the present and not the past.

(Part III)

Leo Tolstoy said that happy families are all alike, but dysfunctional families are all unhappy in their own particular way. Management lessons you receive from your mentors are pretty much the same, too. They reflect the best practices and some gleanings of a lifetime of achievement and success. They can seem a little plain, clichéd, or easily forgettable. Or maybe I just didn’t pay attention when things are working. Therefore, the things I learned from my inspirational bosses blurred together, but the lessons from bad bosses I’ve endured remain stark and memorable.

After college, I put my English degree to use in various low-wage jobs where I quoted Shakespeare and Melville to unimpressed co-workers. I worked in retail, I worked in warehouses, I worked in a plant operating a piece of machinery that could have removed my arm, and I worked in a pseudo-office environments for a variety of bosses and foremen. Some showed me the right way to do things specific to that job. Others, though, taught me the wrong way to do anything.

Donny, the Produce Manager
I put myself through college working in a grocery store as a bagger, a checker, and eventually, a produce clerk. After the ownership changed, the new owners brought in managers from their other stores to run ours, their new flagship store. They replaced a thoroughly professional produce manager, who showed his keen insight into management by bringing me aboard, with a younger, less expensive manager. Donny had managed the produce department at the new owners’ first grocery store and felt he had a special relationship with one of the owners in particular. This special relationship did not prevent Donny from assigning denigrating nicknames to the owners, and Donny loved to share them with other employees.

Donny’s tenure lasted about a year with the store, during which time he did the minimum work required to keep his employment, relying on his employee to carry the burden of bringing the department’s appearance to standard. Donny spent his days reading the newspaper in the store’s break room and, when he was on the sales floor, regaling me with stories of his satyrical youth and attempts at a satyrical present. Possibly a step ahead of termination, Donny secured an assistant manager position at a larger chain’s store, ironically one owned by the store’s previous owners. Donny closed out his tenure by spending even more time in the break room and making a show of how little he was doing and cared.

Strangely, Donny’s new job and its expectations of effort and professionalism did not suit him. He approached my store’s ownership and management for a position with our store again. He was rebuffed, and not in the fun way his satyrical tastes preferred.

Donny taught me a couple things about workplace relationships. First and foremost, a special affinity or cordiality with someone further up the org chart will not necessarily provide any extra benefits if one is not a productive employee. Don’t mistake a kind word now and then, some bawdy humor shared with a smirk, or other fraternity with professional esteem.

Secondly, Donny emphasized that burning bridges can very often work against your long-term best interests. Remember all the “It’s not you, it’s me” speeches your friends have gotten when they’ve broken up? Use that template for your exit interviews, because someday you might find yourself in another situation in a position to accept work or consulting projects from the very organization or people you cannot stand now. After all, you’re really looking to leave an entire situation, not just a company or some people. Remain diplomatic, and you’ll keep your options open.

Thirdly requires another anecdote. Donny found a contest in one of the monthly produce periodicals. A fruit grower urged produce managers to celebrate National Pear Month by creating an elaborate display of the grower’s pears. Contest participants could send pictures of their creations to win fabulous prizes with the grower’s logo on them. Donny ordered several cases of exotic pears that the customers of our bread-and-butter small grocery would never actually buy, created a simple display on a simple table, photographed his child eating a pear by it, and won something from the contest.

The story offers many counter-examples to what one should do: squandering company resources for personal advancement, for example. But Donny had his eyes open for a small opportunity, an esoteric chance, and he put effort toward it, yielding success. In the course of our day-to-day work life, it’s far too easy to get bogged down in the forest, looking at the trees, and miss a very interesting and potentially beneficial vine or shrub growing amid the trees. Even bad managers can provide good lessons, so don’t dismiss everything they do or say. Just most of it.

(Part II)

So maybe we should count our blessings that he is yet undefined:

What is krux? No doubt the method by which news organizations can turn a profit on the Internet. Which remains undefined.

But a tip of the hat to the developers in the world who name their objects, attributes, and methods to sound like the names of demons.

This is Michal Handzus:

Michal Handzus is a center in the NHL, and regardless of wherever else he has played in with what other teams he has hoisted the Stanley Cup, he will always be a St. Louis Blues hockey player to me and there’s nothing more attractive to me than a woman wearing #26 in the Blue Note. But that’s neither here nor there.

The image you see above is a corrupt, truncated jpg.

You see it correctly because some photo editors and some Web browsers are forgiving of that problematic jpg.

If you’re testing any sort of image processing in your application, you have to wonder, “What would Handzus do?”

Or, you’re not a hockey fan, you can find another truncated jpg image here.

That’s the only way I know.

As a public service, I hereby provide you with the first verse of Electric Six’s “Synthesizer” in a dozen non-Roman alphabets for your testing pleasure. Remember, Hebrew, Arabic, and Urdu read and represent from the right to the left which might bollix your application if it tries to handle them.

Chinese traditional
合成器
您可以撼動它周圍
你可以去向上和向下
你可以失去你
但你不能無視我的化工技術

Chinese Simplified
合成器
您可以撼动它周围
你可以去向上和向下
你可以失去你
但你不能无视我的TECHNO

Arabic
المزج
يمكنك التخلص منه في جميع أنحاء
يمكنك الذهاب صعودا وهبوطا
يمكنك أن تفقد ما وجدت
ولكن لا يمكنك تجاهل تكنو بلدي

Hebrew
סינתיסייזר
אתה יכול לנער אותו בכל רחבי
אתה יכול לעלות ולרדת
אתה יכול לאבד את מה שמצאת
אבל אתה לא יכול להתעלם טכנו

Greek
Συνθεσάιζερ
Μπορείτε να ταρακουνήσει όλο
Μπορείτε να πάτε πάνω και κάτω
Μπορείτε να χάσετε ό, τι βρήκατε
Αλλά δεν μπορείτε να αγνοήσετε techno μου
 
Korean
합성기
당신은 주위를 흔들 수
당신은 가서 다운 수
당신이 발견 잃을 수
하지만 당신은 내 테크노를 무시 할 수 없습니다

Russian
синтезатор
Вы можете встряхнуть все вокруг
Вы можете идти вверх и вниз
Вы можете потерять то, что вы нашли
Но вы не можете игнорировать мои техно

Urdu
مرکب ساز
آپ کے ارد گرد ہلا کر سکتے ہیں
تم جاؤ اور نیچے کر سکتے ہیں
تم ہار جو آپ محسوس کر سکتے ہیں
لیکن تم نے میری تکنیکی کو نظر انداز نہیں کر سکتے

Thai
สังเคราะห์
คุณสามารถเขย่ามันทุกรอบ
คุณสามารถไปขึ้นและลง
คุณจะสูญเสียสิ่งที่คุณพบ
แต่คุณไม่สามารถละเลยเทคโนของฉัน

Japanese
シンセサイザー
あなたはすべてのまわりでそれを振ることができます
あなたが上に移動し、ダウンすることができます
あなたが見つけたものを失う可能性があります
しかし、あなたは私のテクノを無視することはできません
 
Kannada
ಸಂಯೋಜಕ
ನೀವು ಎಲ್ಲಾ ಸುಮಾರು ಅಲ್ಲಾಡಿಸಿ ಮಾಡಬಹುದು
ನೀವು ಹೋಗಿ ಡೌನ್ ಮಾಡಬಹುದು
ನೀವು ಪತ್ತೆ ಕಳೆದುಕೊಳ್ಳಬಹುದು
ಆದರೆ ನೀವು ನನ್ನ ಟೆಕ್ನೊ ನಿರ್ಲಕ್ಷಿಸಿ ಸಾಧ್ಯವಿಲ್ಲ

Tellugu
సింథిసైజర్
మీరు అన్ని చుట్టూ ఇది షేక్ చేయవచ్చు
మీరు అప్ వెళ్ళి డౌన్ చేయవచ్చు
మీరు దొరకలేదు ఏమి కోల్పోతారు
కానీ మీరు నా టెక్నో విస్మరించకూడదు

Also, for your listening pleasure, all of Electric Six’s “Syntesizer”:

Troy Hunt has a long post on how many desktops are still running Internet Explorer 8 on Windows XP and why that is.

If you’ve read this blog for much of its five year existence, you know I harp a lot on understanding why so many users are locked into old browsers, and why the number of them still running old versions of IE is still quite high. And why you need to account for it, whether to make your stuff backward compatible or to consciously decide not to support old beasts out there and what that might mean.

Also, you should always find out what your clients are running. Oh, the number of times developers, left to their own devices, would write things for their clients that their clients would be unable to run.

(Link via tweet.)

Mocking up some fake addresses and using “101 Tester Way”?

Bear in mind these are actual addresses:

101 Tester Lane, McEwen, TN 37101:

View Larger Map

101 Tester Street, Clinton, AR 72031:

View Larger Map

These samples will give you the satisfaction of having Test right in the data and they work for map integration purposes.

Strangely enough, 101 Tester Street is not that far down the highway from my secure mountain redoubt.

The only way it sounded better was on the Commodore 64.

Undoubtedly, I still have that on a floppy disk somewhere.

There’s a White House petition to make the United States change from imperial units to metric units of measurement.

I got two words for you: Gimli Glider, a plane that almost fell out of the sky during the Canadian switchover to the metric system:

At the time of the incident, Canada was converting to the metric system. As part of this process, the new 767s being acquired by Air Canada were the first to be calibrated for metric units (litres and kilograms) instead of customary units (gallons and pounds). All other aircraft were still operating with Imperial units (gallons and pounds). For the trip to Edmonton, the pilot calculated a fuel requirement of 22,300 kilograms (49,000 lb). A dripstick check indicated that there were 7,682 litres (1,690 imp gal; 2,029 US gal) already in the tanks. To calculate how much more fuel had to be added, the crew needed to convert the quantity in the tanks to a weight, subtract that figure from 22,300 kg and convert the result back into a volume. In previous times, this task would have been completed by a flight engineer, but the 767 was the first of a new generation of airliners that flew without a flight engineer and flew only with a pilot and co-pilot.

A litre of jet fuel weighs 0.803 kg, so the correct calculation was:

7682 L × 0.803 kg/L = 6169 kg
22300 kg − 6169 kg = 16131 kg
16131 kg ÷ (0.803 kg/L) = 20088 L of fuel to be transferred

Between the ground crew and pilots, however, they arrived at an incorrect conversion factor of 1.77, the weight of a litre of fuel in pounds. This was the conversion factor provided on the refueller’s paperwork and which had always been used for the airline’s imperial-calibrated fleet. Their calculation produced:

7682 L × 1.77 kg/L = 13597 kg
22300 kg − 13597 kg = 8703 kg
8703 kg ÷ (1.77 kg/L) = 4916 L of fuel to be transferred

Instead of 22,300 kg of fuel, they had 22,300 pounds on board — a little over 10,000 kg, or less than half the amount required to reach their destination. Knowing the problems with the FQIS, Captain Pearson double-checked their calculations but was given the same incorrect conversion factor and inevitably came up with the same erroneous figures.

You can read the whole story of the Gimli Glider in the excellent book Freefall: 41,000 feet & Out of Fuel, which I read on a plane trip to Florida a couple years ago.

No, I have five words for you. The other three are Mars Climate Orbiter:

On November 10, 1999, the Mars Climate Orbiter Mishap Investigation Board released a Phase I report, detailing the suspected issues encountered with the loss of the spacecraft. Previously, on September 8, 1999, Trajectory Correction Maneuver-4 was computed and then executed on September 15, 1999. It was intended to place the spacecraft at an optimal position for an orbital insertion maneuver that would bring the spacecraft around Mars at an altitude of 226 kilometers on September 23, 1999. However, during the week between TCM-4 and the orbital insertion maneuver, the navigation team indicated the altitude may be much lower than intended at 150 to 170 kilometers. Twenty-four hours prior to orbital insertion, calculations placed the orbiter at an altitude of 110 kilometers; 80 kilometers is the minimum altitude that Mars Climate Orbiter was thought to be capable of surviving during this maneuver. Final calculations placed the spacecraft in a trajectory that would have taken the orbiter within 57 kilometers of the surface where the spacecraft likely disintegrated because of atmospheric stresses. The primary cause of this discrepancy was engineering error. Specifically, the flight system software on the Mars Climate Orbiter was written to take thrust instructions using the metric unit newtons (N), while the software on the ground that generated those instructions used the Imperial measure pound-force (lbf). This error has since been known as the metric mixup and has been carefully avoided in all missions since by NASA.

Now, imagine every computer system you know being rewritten to use or convert from imperial measurements to metric measurements. All the Why1K bugs in critical embedded systems. Forget flying. Forget driving. I’ll be walking.

You might be thinking, Gee, Director, aren’t you hitting the luddite thing a little hard these days? Well, I just got a smart phone and a Roku box. It’s an instinctive pushback against my entrance to the 21st century.

(Petition link via tweet.)

Marlena Compton posits If you do testing, you need more monitors.

Au contraire, I say, but I mispronounce it because I do not speak French.

I use a single monitor (across multiple machines, no less, through the magic of KVM).

Ms. Compton says:

Having more monitors leads to better testing because:
More supported browsers are open and easy to compare
More sessions are open so it is easier to see cause and effect problems
I can have more than one or even two or three users signed in with different permission levels.
Even though there are still several browsers open, I can also have some terminals open for grepping through log files and taking notes or logging bugs.

Of all these things, the only time I’ve found multiple monitors to be a worthwhile solution is while running automated tests on a number of machines. Each machine had its own monitor (14″ CRTs back in the day), and the master control monitor (17″ CRT, probably) launched the scripts and displayed a -tailing log while the scripts ran. In the automated environment, where you’re watching the scripts (and maybe the GUIs), this makes sense.

But in my world of manual testing, especially exploratory and ad hockish testing, one monitor is better. A big monitor, to be sure, so you can blow everything up really big, but one monitor just the same.

The reason: Focus.

Ms. Compton says:

In the world of web application testing, this is the difference between noticing something and having it obscured behind too many screens where you will never see it.

The principle extends to across too many screens as well as in open windows that don’t have focus. It’s hard enough to catch one little bit of squirrelly behavior in one little spot in an application page or an application window when it happens right in front of you. If you’ve got to turn your head or rely on your peripheral vision to catch it, you won’t.

Dramatic re-creation

Personally, I focus all my attention on one browser/window at a time. If I could put a photography hood over my head, I would. Come to think of it, maybe I ought to get one. Because I’m zoned in on that thing I’m looking at or testing.

If I need multiple sessions open at once to have different users interacting, I’m still focusing on looking for bugs in one of them at one time. I can do that with multiple browsers open on one machine.

Compatibility testing? Let me tell you how I did it when I was a printer: I took the print sample I was supposed to match and I put the new print sample over it, and I held them together against the light. The Web testing equivalent is to maximize the browser windows, load the pages to compare, and use ALT+TAB to switch between them quickly. Misplaced items will jump around visibly.

So more monitors isn’t necessarily better, especially if your attention has a tendency to

SQUIRREL!

Forget the hashtag #AnnualGoals2013 that I tried and failed to get going on Twitter. Here’s my personal list of strengths and attributes I’d like to improve in the forthcoming year:

An interesting story about the Internet as seen in North Korea:

There’s a curious quirk on every official North Korean website. A piece of programming that must be included in each page’s code.

Its function is straightforward but important. Whenever leader Kim Jong-un is mentioned, his name is automatically displayed ever so slightly bigger than the text around it. Not by much, but just enough to make it stand out.

The article also details the various home-brewed operating systems and whatnot in North Korea.

You know, I think QA’s a pretty high-pressure gig since I’m very eager to make the software perfect before the alpha release even, but I’m not putting my life on the line testing it. I can’t imagine what it’s like to work QA in North Korea.

(Link seen here.)

Noah Sussman has two lists about how developers often bungle time in their applications:

I have repeatedly been confounded to discover just how many mistakes in both test and application code stem from misunderstandings or misconceptions about time. By this I mean both the interesting way in which computers handle time, and the fundamental gotchas inherent in how we humans have constructed our calendar — daylight savings being just the tip of the iceberg.

Read his lists: Falsehoods programmers believe about time and More falsehoods programmers believe about time; “wisdom of the crowd” edition.

Then go ye forth and see if your developers got any of them right.

(Link courtesy Gimlet.)

If you don’t understand nothingness, you cannot be nothingness:

Or maybe this poor Web site is struggling with the works of Heidegger. We’ll never know. All we know is that it’s not doing what it’s supposed to.

You know what is a damn cheap trick? Entering an invalid value in a Zip Code field, especially if your system is trying to validate it.

Here are three Zip codes that do not exist for your testing pleasure:

87258
86705
97052

You’re welcome. Your developers will definitely not thank you.