Rick Scott

Audrey Tang is far and away the most awesome hacker I've ever had the privilege to have worked with. She's best known for creating Pugs, a perl6 implementation in Haskell. Though it's now semi-retired in favour of the newer implementations that it had a role in inspiring, it represented a huge leap forward and a quantum shift in Perl6 development at a time when enthusiasm around Perl6 was sorely flagging. She was the first CPAN contributor to have uploaded 100 modules. She's the key figure behind Perl 5's internationalization, as well as the i18n of many, many other individual pieces of software. She was part of the committee that designed the Haskell 2010 standard, and has made innumerable other contributions to the open source community.

I never got seriously involved with Pugs, but many of the things Audrey did with it shaped my thinking around open source, community, and how we should collaborate. First was the idea that a project should be optimized for fun (-Ofun¹), not for control, or strict adherence to the founder's vision, or anything else. Second, whereas many open source projects keep a very tight rein on who has commit access and make getting a commit bit an arduous process, Audrey aggressively gave out commit bits to anybody who happened to wander by in the general vicinity of Pugs. Got a great idea? Here's a commit bit, go implement it. Notice something missing in the docs? Here's a commit bit; go add it. Ranting in IRC that something's not working? Here's a commit bit; go fix it. Extending this trust makes people feel welcome and want to contribute. It fosters an air of community instead of making prospective new participants feel as though they are looking at climbing (or worse, building) a pyramid.

Audrey would likely demur at my calling her brilliant, but it's a fitting descriptor for her. She has a unique and penetrating insight into code and an uncanny knack for encouraging the people who write it. I count myself as fortunate to have been able to work with her and to be part of a few of the communities she's had such a profound impact on.

¹ -Ofun: -O is the compiler option that tells it how you want your code optimized. Audrey's presentation on -Ofun [pdf] talks more about how to maximize the amount of fun in your software project.

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.

I'm happy to note that my latest article has gone up on StickyMinds. This one's on Epistemology & Software Testing.

This one was actually a bit arduous to write, because it went off in a very different direction from where I initially thought it'd go. The pieces that do that can end up being the most illuminating ones, though.

Whoops! Forgot to make an entry here when this went up. I had the Stickyminds Weekly Column back on 30 May 2011 with the article Testing Metaphysics.

I neglected to post this at the time because I was enroute to Drupalcon Chicago 2011 when it went live, but -- I had the StickyMinds.com weekly column for 7 March 2011: Philosophy and Software Testing.

So far, I've studiously avoided addressing the morass that is the certification debate, but I wanted to respond to Chris McMahon's "Ignoring Certification -- With Numbers". In doing so, I started thinking about what kind of professions we certify, the ways in which we certify, the rationale for certification, and so forth. This, however, is exactly the kind of detailed analysis that gets dragged down into the Certification Muskeg. Instead I will leave you with these three assertions:

First: We don't certify authors, yet we generally manage to figure out if they are any good or not. Stephen King didn't sit an Authors' Board examination before writing his novels. Similarly, Jeri Ellsworth didn't get a benediction from the Electronic Industry Alliance before creating the C-One. And despite the lack of an Electric Guitar Certification Council, we somehow clued into the fact that Jimi Hendrix was creating something powerful and innovative.

Second: Currently, there exists no entity with the technical or moral authority to administer a software testing professional certification. We have nothing akin to a College of Physicians and Surgeons or a Council of Professional Engineers. In no small part, this is because humanity's understanding of the field of software^[n] is so incomplete and so immature as to prevent an impartial, vendor-neutral certification from existing. Without a consensus around what constitutes good testing or a good tester, how can we certify anyone as a Software Tester in the general sense, as opposed to someone who's merely familiar with how some organization thinks testing should be done?

Certifying software testers in this day and age is akin to certifying nuclear scientists in the 1890s. We need to be growing our understanding of our field substantially, not dwelling on the tiny sliver of it we think we know.

Third: It is human nature to fight the battles that are placed before us instead of looking for the ones we should be fighting. We often start coming up with answers before checking to make sure we are asking the right questions. This is a mistake of the highest order. Fighting meaningless battles is a waste of our time, energy, and karma. Our goal isn't to fight -- it's to win. Slugging it out in the wastelands of the world is a benighted thing to do and an absurd thing to strive for; far better to leave your foes in the wastelands while marching on to your objective.

[n] I would argue that this is true of software creation as a whole, and not just of software testing.