rickscott: Bemused-looking picture of Rick (Default)

Over the past weekend, some folks in the software testing community had a lengthy Twitter conversation about diversity. Being asleep at the time, I completely missed it.

Twitter facilitates some amazing multi-user conversations, but they can be very difficult to follow unless you happen to be playing along in real-time. Things like threaded replies help somewhat, but the flow of the conversation isn't back & forth between pairs of people -- it's more like a roundtable with several people all speaking to each other. I find the easiest way to make sense of things is just to view all the tweets posted by all the participants on one page, sorted by the time that they were posted. Thus, I made a tool to do just that. As an added bonus, if you want to keep a record of a conversation for posterity's sake, it's easy to do so.

The code for Twiner is posted on GitHub. This is a pretty quick and dirty script; it does what I needed it to do, but nothing more. If people find it useful, though, I'd be happy to clean it up, and I'm more than happy to accept patches.

rickscott: Bemused-looking picture of Rick (Default)

Precision in choosing words is important. Shared understanding of what words mean forms the basis of language. If we don't have that shared understanding, we can't communicate. That being said, humans are messy and inexact beings. We're prone to nuance and ambiguity. Words aren't installed in our brains directly from the OED; they accrete meaning over a period of years. No two people are ever going to definitively agree on what a word means, simply because we can't burrow into each other's heads and start rearranging things.

It's a waste of time to try to nail down a word's definition beyond any shadow of a doubt, especially when you're trying to nail it to the inside of somebody else's skull. On several occasions, I've seen what could have been a very productive discussion derailed by an intellectual death spiral where people slug it out over the exact meaning of some term. Better to agree on a provisional definition that will suit the conversation at hand and move on to discussing matters of greater substance.

rickscott: Bemused-looking picture of Rick (Default)

Hi all! Welcome to the new home of my former Posterous blog. I've given my reasons for making the switch back there.

All the content that was up on Posterous is present here as well. One change when it comes to commenting (not that I had a particularly strong comment base) is that you'll want to use your OpenID to comment here. If you already have an account at Blogger, Wordpress.com, Typepad, or any of dozens of other services, you already have an OpenID. You're also welcome to just comment anonymously and leave your name in the comment body.

Onwards! There are better things to discuss.

rickscott: Bemused-looking picture of Rick (Default)

At the Writing About Testing Conference I gave a lightning talk on how to give a lightning talk.

I adore lightning talks. They're a great format for beginning presenters, because you get a nice round of applause if things go reasonably well, and you're off the stage in less than five minutes if they don't. They're great for experienced presenters, because you can field concepts without having to prepare a full-on presentation slot. Finally, they're great for audiences because they're information-dense: they pack 10 to 12 new ideas into a single hour of conference time.

Here's my slide deck: your choice of pdf (560K) or odp (292K).

rickscott: Bemused-looking picture of Rick (Default)

I gave a presentation at Ignite Sault 3 on testing, bug reporting, and purging our software of the many annoyances that people take for granted. The video isn't up yet -- it will take some time for the all-volunteer ignite crew to edit and render it -- but here's my slide deck for the time being (2.2mb pdf).

rickscott: Bemused-looking picture of Rick (Default)

I admit it. One of the best moments of my undergrad degree came when our small group of thesis students was bandying about topics. When I mentioned I was set on doing decompilation, there was a long, awkward silence. One of the other students, apparently speaking for the entire group, said "We wouldn't touch your research subject with a 10-foot pole."

As smugly optimistic as I was, though, my thesis on automated decompilation would never have seen the light of day without the work of Dr Cristina Cifuentes -- particularly her PhD thesis on Reverse Compilation Techniques.

Dr Cifuentes' research runs head-on into some of the most thorny theoretical problems of computer science -- problems like the Halting Problem, which define the limits of what computers can actually do. Amongst other things, she's also worked on binary translation, static analysis, and parallelization, topics that people sometimes shy away from because of their reputation for both practical and theoretical difficulty. But this work yields awesome real-life applications, like programs that find bugs for you by reading your source code, and holds out the promise of many more, like tools that can scan compiled binaries for security bugs, or general-purpose decompilers that can read in a binary originally written in C and 'decompile' it to Ruby source code instead.

I think we forget how many women were involved in pioneering work in the early days of computing (eg the ENIAC programmers) and how many are in the thick of pioneering work today. The hardcore research isn't just done by bearded guys in white lab coats -- women are pushing the boundaries and making the future of computing possible, too.


Ada Lovelace Day is an international day of blogging about women in science and technology. You can find more information at the Finding Ada website.

rickscott: Bemused-looking picture of Rick (Default)

The metaphor of Technical debt has gained currency since Ward coined it. Paying off your tech debt can be thought of as "technical investment": one hopes to reap rewards somewhere down the road, in the form of fewer defects, being able to add features more easily, and so forth.

Just like saving real money, trying to muster the will to pull this off can be difficult. The organization may balk at the notion of sinking the tech team's time into making changes that don't have an immediate customer-visible benefit. Even the tech folks can be unsure that it's going to pay off -- will the code you refactor now be instrumental in the next round of changes, or be thrown out and completely replaced a few iterations from now? Recently, I saw a remarkably clear example of the utility of paying off technical debt.

Backstory: we own a large legacy web application, created by an outsourced development company over a period of years. This application grew to the point where the company that wrote it was unable to maintain it or to add new features. It was brought in house and turned over to a small team of crack developers in the hope that they could bring it under control. In other words, right from day one, the dev team has been saddled with a huge mass of technical debt.

Our app sends a lot of email: monthly account statements, bills, proposals, dialog between users and staff, dialog between users, news and policy updates...the list goes on. As fate would have it, several pressing items to mail all landed right at the same time last month. Combined with an increasing number of clients, this put us well over the limits of our email setup. We needed to rework how our app sent outgoing mail; specifically, we needed it to be able to algorithmically choose from a list of outbound mailservers. The longer we took to make this change, the longer our clients' documents would be delayed.

This kind of thing can be a nightmare. The codebase we're working with doesn't have anything approximating a consistent architecture. The different modules of the system were almost certainly written months apart and by different developers. There's no reason to expect that each function that sends mail does so through the same interface; in fact, given our history with it, there's every reason to suspect that somewhere deep in the guts of the system, there's a well-obscured routine with its own little mailserver configuration hardcoded into it. Sorting through something like this would probably take a few days; the better part of a week for the whole change with testing and release factored in.

About two months ago, however, one of our developers went through the system with a fine-toothed comb, looking for every place the app sends mail. They got rid of the patchwork of ad-hoc methods that were littered through the code and routed all mail sending through a single consolidated class. When it came time to make a change, then, the dev got to make it in one place instead of tracking down multiple places to change or refactor, and I got to focus on how the new mail setup worked instead of trying to find places in the code that bypassed it. The new feature was developed, tested, and rolled out in a single day.

Whether we'd done the consolidation part of the work before or after we found out that our mail setup needed fixing, the total time to make the entire change probably would have been about the same. Had we not paid off our debt, though, this week would have come at a time when we could ill afford to spend it. In short, we were better prepared to react. If we had wanted to make a different change, like digitally signing all of our outbound email, this consolidation would have helped us do that as well.

So there you have it. It's only a single anecdote, but it's a point of reassurance that paying off your technical debt now can work in your favour down the road.

rickscott: Bemused-looking picture of Rick (Default)

I admit, I'm not super-knowledgeable about security. I know some of the fundamentals, but not a great deal beyond that.

Still, in my early days on the 'net I got the distinct impression that allowing random people to execute arbitrary code on your computer is bad. I mean, that's somebody else using your computer to do stuff without your knowledge or consent, right? That's why attacks like this really, really make me shake my head (NSFW, offensive, turn off javascript before following):

hxxp://encyclopediadramatica.com/Firefox_XPS_IRC_Attack 

Despite all this, somehow today's ordinary browsing experience consists of downloading pages full of arbitrary javascript written by any random person who controls a website, then blithely running them on your machine.

I don't get it. Where did we go wrong?

(PS. Firefox users: NoScript is your friend. =)

rickscott: Bemused-looking picture of Rick (Default)

This is more about "mind hacking" than QA or tech, but still, stuff like this fascinates me:

http://en.wikipedia.org/wiki/Pointing_and_calling
http://search.japantimes.co.jp/cgi-bin/ek20081021wh.html

Background: In Japan there's this practice called shisa kanko (指差喚呼), usually translated into English as Pointing & Calling. It's a technique that makes sure you actually check critical safety items. You

  • call out loudly what you're supposed to be checking,
  • point at it,
  • check it and announce the result.

Train drivers are the most conspicuous example; they're actually the ones that started doing this in the first place. If you were sitting in the cab of a train about to leave Ueno station, you might see the driver pointing to items and checking them off like this:

  • (Door indicator light) "Doa: shimete-aru!" (Doors: closed!)
  • (Signal light) "Shuppatsu: shinkou!" (Departure signal: proceed!)
  • (Speed limit sign) "Seigen: sanju-go!" (Speed limit: 35!)
  • (Timetable) "Ueno: hassha!" (Ueno: depart!)

This sounds stilted, nerdy, and quite frankly, embarassing. Does it really work?

"I posed that question to Kazumi Tabata of the Japan Industrial Safety and Health Association, who showed me research conducted in 1994 ...The combination of pointing and calling reduced mistakes by almost 85 percent."

All of us sometimes have to do tasks where the key challenge is to stay sharp and pay attention to a very routine or boring set of inputs. Driving is a good example. Sifting through columns of identical-looking numbers searching for an error is another. We've only got a limited ability to stay alert, so it's easy to go "on autopilot" during tasks like these. We might skip steps in a checklist, or "check" something without really checking it, especially if we're tired or distracted. How many times have you looked both ways at an intersection and completely failed to see an oncoming vehicle?

As technical people, it shouldn't come as a great surprise that we focus a great deal on technical tools and techniques. Will this database tweak make our site run faster? Will this test tool let us catch more bugs? I think we often neglect ways in which we can upgrade our wetware, even though it may be the most fruitful place in the system to look for improvement.

Humans are inherently error-prone and are always going to make mistakes, but that doesn't mean that there's not room for improvement. Any way that we can improve our acuity as individuals reduces the number of mistakes we send downstream for technology, process, or other people to catch. It's a no-brainer.

rickscott: Bemused-looking picture of Rick (Default)

I've had both really great and really bad experiences while telecommuting, as have a lot of people on the writing-about-testing mailing list. Sometimes the bad experiences come down to inadequate tools; more often, it's because not everybody has bought in to having telecommuters working on an equal footing with people who are in the office.

We put together a generic Telecommuting Policy based on our collective experience. If you are or want to to be a telecommuter; if you're considering or engaged in telecommuting at your workplace, then I think you'd be better off for reading it.

http://chrismcmahonsblog.blogspot.com/2009/12/telecommuting-policy.html

Profile

rickscott: Bemused-looking picture of Rick (Default)
Rick Scott

Who?

Canadian philosopher-geek who's profoundly interested in how we can collaborate to make technology work better for everyone. He's an incorrigible idealist, an open source contributor, and a staunch believer in testing, universal access, and the hacker ethic.

Syndicate

RSS Atom

Expand Cut Tags

No cut tags

Style Credit

September 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 2012
Page generated Sep. 20th, 2017 01:02 pm
Powered by Dreamwidth Studios