“Hell is where I was born/Hell is where I was raised….” Hellyeah doing “Hush”:
Archive for the ‘Miscellany’ Category
I recently replaced an old timey thermostat that measured the temperature in Roman numerals with a new thermostat that the blister case said was programmable but that doesn’t know Java, Ruby, Python or C# at all (which is just as well, since any programming I did in those languages would undoubtedly set my household temperature to
Inside, though, note the guide to the internal switches, particularly the last:
To turn the battery monitor off, you have to set the switch to the on position. To turn the battery monitor off, you have to set the switch to the on position. It’s akin to clicking Cancel and getting a confirmation dialog box that has a Cancel button which is to cancel the cancellation and an OK button that is to actually cancel. If you mix in some confusing message on the dialog box to confound the user.
Look closer, though.
There is no switch #4 on the board.
Never mind, it’s more like a 404 error then.
It’s good to see our friends on the hardware side of things getting into the slapdash action we’re accustomed to in software development.
And by ‘good,’ I mean terrifying.
The software industry venerates the young. If you have a family, you’re too old to code. If you’re pushing 30 or even 25, you’re already over the hill.
Alas, the whippersnappers aren’t always the best solution. While their brains are full of details about the latest, trendiest architectures, frameworks, and stacks, they lack fundamental experience with how software really works and doesn’t. These experiences come only after many lost weeks of frustration borne of weird and inexplicable bugs.
Like the viewers of “Silicon Valley,” who by the end of episode 1.06 get the satisfaction of watching the boy genius crash and burn, many of us programming graybeards enjoy a wee bit of schadenfraude when those who have ignored us for being “past our prime” end up with a flaming pile of code simply because they didn’t listen to their programming elders.
(Link via tweet.)
Well, no, they tested the eye-hand coordination of Albert Pujols a couple years ago, and the tests seem like they’d be applicable to testers as well:
White, who administers these tests frequently as part of her research and clinical work, was especially surprised by Pujols’ performance on two tests in particular, a finger-tapping exercise that measures gross motor performance and a letter cancellation task that measures ability to conduct rapid searches of the environment to locate a specific target.
Asked to place a mark through a specific letter each time it appeared on a page of randomly positioned letters, Pujols used a search strategy that White had never witnessed in 18 years of administering the test.
“What was remarkable about Mr. Pujols’ performance was not his speed but his unique visual search strategy,” White said. “Most people search for targets on a page from left to right, much as they would when reading. In observing Mr. Pujols’ performance, I initially thought he was searching randomly. As I watched, however, I realized that he was searching as if the page were divided into sectors. After locating a single target within a sector, he moved to another sector. Only after locating a single target within each sector, did he return to previously searched sectors and continue his scan for additional targets.”
Asked to depress a tapper with his index finger as many times as possible in 10 seconds, Pujols scored in the 99th percentile, a score almost identical to one earned by Ruth on a similar test of movement speed and endurance. White was impressed not only by Pujols’ tapping speed (2.4 standard deviations faster than normal), but also by the fact that his performance kept improving after repeated trials.
“It was interesting that he actually tapped faster in later trials of the task, suggesting considerable stamina at a high level of performance,” White noted. “Most people tap somewhat slower as the test progresses because their fingers and hands begin to fatigue.”
Pujols tapped with such force, in fact, that, at one point, he actually knocked the tapping key out of alignment. Pujols then helped White repair the finger tapper, tightening a loosened screw with his fingernail, she said.
On additional test I’d pose is: How many members of an agile team can you depress in ten seconds?
At the dojo, kyoshi told us the parable of the saw:
There was a woodsman who went into the woods one day to cut some wood, and he began cutting wood. He didn’t want to waste any time, so he cut all through the day, working harder as his saw grew duller. Another woodsman too frequent breaks to sharpen his saw, and he could cut more efficiently than the first woodsman, who didn’t want to waste the time in sharpening his saw. Now, at the end of the day, who had the most wood? The second woodsman.
He’s right, of course; we need to take breaks to recenter ourselves, to focus on something other than our computer or mobile screens while working. Have you ever had a project or a deadline where you want to just bull rush through your list of tasks and responsibilities without taking a break or you’ll never get it done. Maybe some of you face each day that way.
However, focusing so hard that the pixels start to swim isn’t the solution. You should get up, walk over to the window, maybe even step outside for a minute. Take a breath of the fresh air or, if you’re in the city, try to guess if that’s the smell of the tannery or the chocolate factory.
But what’s important is that you get up, stretch, and do something other than sit at the computer. Don’t just switch out of the application you’re working on and check Twitter or read a blog entry. These don’t give you the chance to refocus.
And when you’re done and you sit back down at the computer, you’ll be sharpened like a saw and ready to see what’s before you on the screen instead of waving lines of endless obligation.
Want to stay up tonight, QA?
Here’s a story about how a default in a drop-down list almost killed a young man even though a complete triple-checked system and warnings should have prevented it.
The clinicians involved in Pablo’s case that day — physicians, nurses and pharmacists—all made small errors or had mistaken judgments that contributed to their patient’s extraordinary overdose. Yet it was the computer systems, and the awkward and sometimes unsafe ways that they interact with busy and fallible human beings, that ultimately were to blame. And the biggest culprit may well have been the hospital’s incessant electronic alerts. Some automated warnings misled the medical staff; others were lost in the cacophony of alarms going off throughout the hospital.
Read the whole thing, and think about how it should impact your application design and testing.
When I was a lad, fresh out of the university with a degree in English and Philosophy and no actual career prospects, I worked as a produce clerk for a small off-chain produce and cheese shop. They had daily garbage pickup on weekdays, but nothing on the weekends, which were some of the busiest days of the week. As a result, on Sunday afternoons, the dumpster started to fail boundary analysis, at which time the store manager would order a clerk or two to climb up onto the pile and jump up and down to compact it so we could dump the last few cans of refuse into it. Come to think of it, I’ve seen the same philosophy applied to hardware resource management.
So as I stood and watched the younger kids jumping in the dumpster, I decided that if I was ever ordered to climb into the dumpster, I would drop my apron in the alley and never come back.
Want to know what would make me leave QA? Needing an implant of some sort to do my job:
PayPal is working on a new generation of embeddable, injectable and ingestible devices that could replace passwords as a means of identification.
Jonathan LeBlanc, PayPal’s global head of developer evangelism, claims that these devices could include brain implants, wafer-thin silicon chips that can be embedded into the skin, and ingestible devices with batteries that are powered by stomach acid.
These devices would allow “natural body identification,” by monitoring internal body functions like heartbeat, glucose levels and vein recognition, Mr LeBlanc told the Wall Street Journal.
Over time they would come to replace passwords and even more advanced methods of identification, like fingerprint scanning and location verification, which he says are not always reliable.
I’d rather not be personally, bodily on the Internet of Things unless there’s a compelling medical reason for it, and even then I’m going to ask my doctor to examine all the steampunk options first.
A failed data integration is going to cost St. Louis area residents up to hundreds of dollars. Or require a refund.
No, that extra few hundred dollars on your monthly sewer bill isn’t a typo.
A bill miscalculation that began nearly two years ago has the Metropolitan St. Louis Sewer District asking thousands of customers in St. Louis County to pay for services that never showed up on bills. The average undercharge for an affected household: $450.
Nearly 1,900 residential customers and 3,700 commercial customers are being asked to pay more on their current sewer bill, which should be in mailboxes by the week of April 6 at the latest.
The discrepancy began in May 2013, when Missouri American Water, which provides water service in much of the St. Louis County portion of MSD’s territory, changed its billing system.
MSD buys water meter data from Missouri American in order to calculate many customer rates, but the new system’s data wasn’t properly computing with MSD’s billing programs, district spokesman Lance LeComb said.
“Ultimately MSD is responsible for getting the data right and making sure we have correct account information and send out correct bills,” he said. “Missouri American Water was very supportive of our efforts and provided additional staff” to fix the problem.
Dependency upon an integration, and something at the data provider changed. Expensively.
On the MSD bills, they encourage you to “go green” and pay your bills online:
Given their track record, I can understand anyone’s reluctance to allow MSD’s computer systems access to a customer bank account or credit card.
I know it’s a year old, but the topic of this article will never get old: Ways to Say ‘No’ More Effectively:
When asked to help or to do a favor, whether it is to donate money to charity, fill out a questionnaire or let a stranger use a cellphone, research has shown many people will say “yes” simply because saying “no” would make them even more uncomfortable. This is especially true when people have to give their answer face to face, rather than by email.
And even when people do say “no,” they become more likely to say “yes” to subsequent requests. “They feel so guilty about saying ‘no,’ they feel they need to salvage the relationship,” says Vanessa Bohns, assistant professor of management sciences at the University of Waterloo in Ontario, Canada.
The world could use more No.
NASA’s been writing mission-critical software for space exploration for decades, and now the organization is turning those guidelines into a coding standard for the software development industry.
The NASA Jet Propulsion Laboratory’s (JPL) Laboratory for Reliable Software recently published a set of code guidelines, “The Power of Ten—Rules for Developing Safety Critical Code.” The paper’s author, JPL lead scientist Gerard J. Holzmann, explained that the mass of existing coding guidelines is inconsistent and full of arbitrary rules, rarely allowing for now-essential tasks such as tool-based compliance checks. Existing guidelines, he said, inundate coders with vague rules, causing code quality of even the most critical applications to suffer.
It’s not The Programmer’s Book of Rules, but it’s worth reading and considering even if your software can’t kill people.
The Wall Street Journal changes its capitalization of eBay depending upon where it appears.
For example, look at the print edition:
Or this article online: Carl Icahn Boosts Stake in EBay:
Carl Icahn slightly boosted his holdings in eBay Inc. by about $25 million in the fourth quarter, according to the activist investor’s latest quarterly filing.
Let’s look at the discrepancies and inconsistencies:
- In the print edition headlines and drop quotes, only the E is capitalized.
- In the online story, both the E and the B are capitalized in headlines.
- When it appears at the beginning of a sentence, both the E and B are capitalized.
- When the word appears in the middle of the sentence, it is appropriately capitalized as eBay.
This is a style guide issue, as the inconsistent capitalizations are consistent in where they’re inconsistently capitalized.
This doesn’t seem to be a bigger issue regarding trademark capitalization, as iPhone is capitalized correctly, at least online: ‘Staggering’ iPhone Demand Helps Lift Apple’s Quarterly Profit by 38%:
Apple Inc. surpassed even the most bullish Wall Street expectations for its holiday quarter with an improbable trifecta: selling more iPhones at higher prices—and earning more on each sale.
It looks as though the corporate style guide could use a little correction. How about yours?
Breaking Benjamin, “I Will Not Bow”
On the front page of the September 9, 2014, Wall Street Journal, we find that GE has exited the kitchen with the sale of its appliance business:
However, on page B3 the same day, the drop quote in an article would seem to indicate otherwise:
Of course, General Electric is not buying the food company Annie’s; the headline makes clear that the General in this case is General Mills (stock symbol: GIS).
But there’s nothing in the drop-quote to indicate something is wrong within its own context. Maybe General Electric often pays premiums like that during an acquisition. Maybe the copy editor or whomever did this dropquote finished the GE story from page 1 just minutes before working on the General Mills story.
However, we’ve got to retain context when testing and proofreading.
Where does this come into play in testing?
The foremost example in my mind is when we’re doing things to trigger error conditions to make sure that an error message displays. It’s possible that the system will throw up the wrong error message and we’ll miss it. I once wrote automated tests that triggered error conditions and parsed the error message (mostly to make sure an error message applicable to the screen and operation displayed). However, I did not write it smart enough to compare the error message that displayed to the error message expected. So when the application started failing by displaying the wrong message for the occasion, the tests didn’t catch it.
So you’ve got to remember to see the forest and the trees–along with the underbrush, the soil, the other flora, and the carnivorous fauna–when you’re testing.
You’ve spent days wandering the cavernous halls of a convention center, trapped in windowless rooms, drinking too much coffee and talking yourself hoarse. Does anyone ever emerge from a conference as the organizers intended, feeling recharged with new ideas, contacts and energy?
New York City marketing executive Stefany Stanley does. Among conference organizers she is known as a savvy convention-goer, someone with a strategy for rising above the dreary rounds of networking and breakout sessions. Ms. Stanley says she has gained valuable contacts, ideas and insights from the 15 conferences she has attended in the past five years.
The article goes on with tips and tricks to maximizing your meeting other people to sell your services to or to meet people who might help you get a leg up, basically.
I must be doing it wrong; when I go to conferences, I go to attend the sessions and to learn what the speakers have to offer as to professional insight. Maybe I’ll meet someone I know off the QAternet or something, but I don’t count on it, and if I don’t, I don’t think that I’ve lost something.
Of course, I don’t go to enough conferences and conventions often enough to have my soul crushed, and I don’t think of them primarily as mass in-person sales cold calls, so I’m probably doing them wrong when I do go.
But maybe you’ll find the article useful.
Real-estate agents, better take out that red pen.
An analysis of listings priced at $1 million and up shows that “perfect” listings—written in full sentences without spelling or grammatical errors—sell three days faster and are 10% more likely to sell for more than their list price than listings overall.
On the flip side, listings riddled with technical errors—misspellings, incorrect homonyms, incomplete sentences, among others—log the most median days on the market before selling and have the lowest percentage of homes that sell over list price. The analysis, conducted by Redfin, a national real-estate brokerage, and Grammarly, an online proofreading application, examined spelling errors and other grammatical red flags in 106,850 luxury listings in 52 metro areas in 2013.
Think it applies only to real estate and not your product interface? Are you willing to take that gamble?
You’d better make sure your Web labels, error messages, and helpful text are grammatically correct, or you won’t be able to quantify how many people don’t use your software because they thought it was written by third graders. Because they won’t be your users.
(Yes, I know the story is nine months old, but I’m between contracts right now and have a little time to catch up on my newspapers for the last year.)
Over at Medium, they discuss how the intersection of Polish typing custom, Microsoft Windows custom, and user interface colluded to create a defect: The curious case of the disappearing Polish S:
A few weeks ago, someone reported this to us at Medium:
“I just started an article in Polish. I can type in every letter, except Ś. When I press the key for Ś, the letter just doesn’t appear. It only happens on Medium.”
This was odd. We don’t really special-case any language in any way, and even if we did… out of 32 Polish characters, why would this random one be the only one causing problems?
Turns out, it wasn’t so random. This is a story of how four incidental ingredients spanning decades (if not centuries) came together to cause the most curious of bugs, and how we fixed it.
It’s hard to test for the conditions to recreate this bug unless you’re Polish. It’s also a humbling example of how we’re going to miss things because of our (as yet) limited omniscience.
(Link via IDisposable tweet.)
Seen on Twitter:
Engineers don't let engineers design user interfaces. pic.twitter.com/XKSDUOxKHe
— John Bellomy (@cowbs) September 28, 2014
I’ve tested applications like that, where the Web pages are filled with tabs full of edit boxes crammed into the space with inscrutable labels that, I’m assured, the users know what they mean.
Sometimes, these interface designs come straight off of some crowded paper form that a worker would fill out with pen, checking boxes and putting tic marks or numbers in boxes. On paper, this is as quick as moving your eye, moving the pen, and pressing down. With a screen, it’s a little different, as it involves tabbing or moving the mouse and clicking and then typing something, scanning the form, moving the mouse, clicking, typing some more, and so on.
Other times, these interface designs pretty directly capture what the worker saw in a mainframe application or in a terminal window connecting to a mainframe application. With Windows or Web-safe colors instead of amber text on a black background that the worker. A lot of needless tabbing because interfaces could not easily branch. If you check this box, then these blank spaces become relevant. No, paper couldn’t do that and mainframes couldn’t do that, so the new Windows or Web application won’t do that. Because the users are used to it.
- The workers (“users”) today aren’t the users of tomorrow; if you’re not designing the interface right because it’s good enough for the grizzled greybeard who’s been around forever, you’re not appreciating how much easier you could make the process for n00bs. That is, probably most of the users. Especially if you’re writing software for a company that’s okay with this sort of interface. I imagine it has a lot of turnover and a lot of people getting trained to do it the hard way just because it’s always been done.
- Notice that we use the term “users” a lot in relation to people who work with the software we build. That’s defining them in terms of their relationship with our software, but their main jobs are doing something else. If your software design captures workers and traps them into being users too much, it drags on their productivity. Computer software should make their jobs easier and more streamlined, not slower than working with pen and paper. Sure, you can say that the data collection for analysis on the back-end is the driver for the software, but that doesn’t mean you should ignore other efficiencies you can introduce with a good (or at least better than this) design.
I read somewhere recently about hiring tester with test skills rather than domain knowledge, and sure, that’s the right balance, however, domain knowledge is what allows you to spot these sorts of problems. You might be hired because you’re a good tester, but you ought to study up on the industry whose software you’re testing. Me, I’ve been known to refresh myself on the basics of chemistry to better test chemical modeling software and to grok at least a little bit of the workflow of a warehouse when testing order fulfillment software.
Because otherwise you’re only logging the defects qua defects like “The Tare Weight edit box allows alpha characters” and not the higher level concerns about why you’d expect a worker would enter the total shipping weight before the number of items to ship.
Domain knowledge gives you the insight about the worker’s starting point in your software and what he wants to do to get done with your software. And that will give you the possible paths for his interaction without having to make all the possibilities available on one screen in tiny print.
So I’m at a presentation last week, and the presenter’s got his little tablet plugged into the projector. He wanders off and starts talking to someone, and his tablet shuts off automatically after a bit.
So he goes to the tablet and looks down at it. He starts it back up, and he types his password to unlock it, and….
Because it’s a tablet, the keyboard displays onscreen and shows his key taps.
As does the projector.
So we all saw his password. On one hand, it was a strong password. On the other hand, we all saw it.
Don’t do that.