rickscott: Bemused-looking picture of Rick (Default)

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.

rickscott: Bemused-looking picture of Rick (Default)

I've got the front page of StickyMinds.com this week with a column on Ethics & Software Testing.

I would have loved to delve more into the foundations of ethical thinking and some of the ideas people have articulated about how to best "solve" ethical dilemmas, but the length and focus of the piece doesn't really permit. Maybe that's something for the future. =)

rickscott: Bemused-looking picture of Rick (Default)

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.

rickscott: Bemused-looking picture of Rick (Default)

I love this song by the Afro-Cuban All Stars, and not just because it has a great beat. (lyrics)

Yo le puse el corazón // también le puse la mente //
y el producto resulto // bien distinto y diferente.
I put my heart into it // and also my mind;
the product that results // is very unique and different.

A lot of the value I bring to a test team (or indeed any team) comes by virtue of being different -- of bringing a different life experience, different perspective, and different set of skills to the table.

To take one example, I interact with the Internet through a medium that's very different from that of most people. I use Linux and other open-source software well-nigh exclusively, often via a textual interface. I read mail with mutt, chat with people using irssi, and tweet using ttytter. For many years I browsed the web using lynx simply because my outdated pittance of a computer couldn't handle anything more demanding. Even now, my default view of the web doesn't include javascript, java applets, or flash. A lot of things fall apart when the assumptions that they're developed under crumble.

To take another angle, I've worked as a programmer, sysadmin, and a tester in recent memory. While I'd likely lose out on a kernel hacker job to someone who's spent the last 20 years coding in C, small shops (like the one I'm in now) really appreciate having someone around who can kick servers together, debug CMS modules, and come up with testing tools for the open source project we're hacking on. So it goes with other aspects of my background -- knowing i18n and a few snippets of Japanese because of my time as an exchange student; being sensitive to the ethical ramifications of a piece of software on account of my background in Philosophy; thinking things out in terms of concepts, theories, principles, and strategies, because that's simply how my mind works.

It may be presumptuous to think that you can be the best programmer in the entire world, or the best tester, or what have you. But you can be the best you in the world; the best at at offering the unique set of skills and perspectives that only you have. Though I endeavour to give my best, I'm not so presumptuous to think that I am the best. But I hope you will always find my work distinto; diferente.

rickscott: Bemused-looking picture of Rick (Default)

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.

rickscott: Bemused-looking picture of Rick (Default)

Robert O’Callahan very coherently expressed something I've thought about software for a long time:

In software, especially cutting-edge software like Firefox, every developer is an inventor; coming up with new ways of doing things is not exceptional, it's what our developers do every single day.

(h/t Br3nda)

Every piece of software is something new. Every time we sit down to create software, we're inventing something. We're creating something that, in a very specific sense, has never existed before -- much like we didn't have War and Peace before Tolstoy sat down to write it. After all, if you wanted an exact replica of some existing piece of software, wouldn't you just copy it instead of making it yourself?

Horrible metaphors of construction, engineering, or manufacturing are so frequently applied to software creation. "Making software should be just like building a house!" people say, less-than-subtly implying that it should be perfectly predictable in both time and cost (and ignoring the massive schedule and cost overruns that often plague construction projects). But making a new program isn't like making other programs one might have made before. You may be informed by similarities between a new project and older ones, and you certainly get better with the tools, but you're not faster because an identical item has been made before -- it hasn't.

rickscott: Bemused-looking picture of Rick (Default)

Do we have enough hackathons in the testing world?

So over on the open source dev side of the planet, we have these things called hackathons. The archetype for this kind of event goes something like this:

  • Declare a rough topic: "Apache bug bash", "Perl-related projects".
  • Procure an inexpensive conference room.
  • Add a couple dozen highly motivated open source hackers.
  • Throw in snacks, wifi, collab tools, and a lot of caffeine.
  • Shake vigorously and observe the reaction.

Sometimes these are done before or after another major conference; sometimes they're scheduled on their own. They are more or less round-the-clock affairs where a heck of a lot gets done:

  • tens or hundreds of bugs get closed;
  • new releases of major software projects get done;
  • sweeping new features are designed or implemented;
  • entirely new projects get cooked up and launched.

As much as I love remote collaboration, people in the same physical space have much higher communication bandwidth; you can communicate with more nuance and turn around replies much more quickly. They're also much less subject to the interruptions of daily life: fire drill because a server crashed, the garden needs to be fed, the cat needs watering, etc. The cross-talk that does happen tends to be germane to what's happening in the moment. This all means that:

  • many coordinated tasks get done in a relatively short time;
  • discussions can move forward a great distance in a relatively short time; and
  • a lot of cross-pollination happens -- people riff off of each other's ideas and come up with amazing new things.

Despite how productive hackathons can be, they cost very little. All that needs to be paid for is travel, space, and accomodation, and the hackathon location can be selected so as to keep these low.

I think that the writing-about-testing conference engendered many of the points listed above. I'd like to see these kind of affairs happen more often.

The testing world has a number of great 'pro' conferences: StarEast/West, STPCon, CAST, and so forth. But do we have enough hackathons?

rickscott: Bemused-looking picture of Rick (Default)

At writing-about-testing and other places, we've talked about improv. I get the impression that some people freak out when they hear the notion of improv being applied to software creation. "Improv! That's where people just start making up random stuff outta the middle of nowhere! We can't have that in our nice, disciplined, 100% predictable software production process! That would be chaos!"

The short answer is that improv isn't about guessing, or grasping at straws, or pulling stuff out of the air. Improv isn't a crap shoot. There are solid underpinnings to improv, which is why skilled performers can reliably do it.

First, a bit on Improv

Improv is something that happens in most every field of endeavour, not just those we think of as artistic. It's common in music; famously so in jazz. Improv in the kitchen is a familiar notion; tweaking a recipe or putting together a unique new dish both spring to mind. The Army, on the other hand, isn't usually thought of as a hotbed of creativity, but you just have to speak the jargon: look for the term "field expedient", and you'll find improv being used for everything from building customized radio antennae to repairing vehicles with gun tape and para cord. It's an age-old approach to solving problems in a small-a agile manner, and it has a discernible modus operandi.

Improv Involves Preparation

As oxymoronic as it may sound, improv requires preparation. When the time comes to improvise, you must be ready with the knowledge and tools you need to act. A sig (military communications tech) who wants to create an improvised antenna needs the formulae that dictate its dimensions as well as the wire and sundry bits required to construct it. A chef who wants to create a meal that will address a diner's special needs must have ingredients prepped and at the ready. A jazz musician who wants to be able to solo needs to know their way around their instrument, not just how to play a scale.

Improv Involves Expertise

To improvise effectively, you need expertise and judgement to know how to apply your ability to the situation at hand. A sig needs the wherewithal to know when it's useful to set up an improvised radio antenna and which types the local terrain will support. A chef must know how different flavours hang together, how different ingredients of a dish complement each other, and what kind of meals they can assemble with what they have on hand. A jazz performer needs to know where they can take a tune given its melody, chord progressions, mood, and so forth.

Improv Involves Creativity

Creativity is improv's defining element. It involves taking your preparation and expertise and, in the moment, creating something that addresses the unique situation at hand. A sig comes up with an antenna that gets the radio range they need while blending into the surrounding landscape. A chef comes up with an off-menu dish that looks spectacular and tastes amazing, but doesn't contain the nuts or eggs their customer is allergic to. A jazz musician blows a solo that's unique, expresses their style and mood, and gels with the tune, the rhythm section, the previous solo, and the atmosphere of the evening.

Improv Involves Style

Finally, every practitioner has a different approach to improv. Whether they dub it their style, their reperoire, or their bag of tricks, different improvisors will come up with different things in similar situations. Sigs may have a favourite set of go-to antenna designs; chefs specialize in different regional styles of cooking; jazz musicians have trademark riffs. Styles are unique to each person and their background, and while they seem to bring an element of randomness into the equation, they're internally consistent -- styles evolve over time, but don't change at the drop of a hat. Moreover, oftimes style is a factor of the improvisor bringing their most exceptional or best-practiced skills to bear on a particular problem.

In Conclusion

It's not an accident that skilled improvisers can reliably and repeatably come up with something when called upon to perform. While improvisations are not reproduceable in a carbon copy sense, neither are they arbitrary, capricious, or based around mere hope or chance. They're based on a foundation of preparation, judgement, creativity, and individual skill. Far from being irresponsible, improv highlights how prudent it is to be prepared and agile -- it makes it possible to react to a situation quickly with a response that is masterful, timely, and appropriate.

rickscott: Bemused-looking picture of Rick (Default)

Last weekend, a conversation about diversity took place on twitter between several prominent folks in the Agile and Testing communities. There's a transcript archived here, and if you're not familiar with the gist of what transpired, this reply may make more sense if you read the transcript first.

First, I need to make clear that I'm not involved with the Diversity in Agile project in any way. What I'm about to say is based on having observed other initiatives of this same sort, and on seeing a pattern of discussion that's been repeated in workplaces, in the open source community, and now, to my dismay, in the Agile testing community.

Why give out awards for being a female in the technology field?

jbtestpilot: Request: can a "woman-in-test" explain to me how it feels to be honored & rewarded because of their gender?
Sat Jun 05 05:10:01 +0000 2010

As several people involved in the project have since pointed out, the project isn't giving out "awards". Moreover, the point of initiatives like this isn't to give out some kind of condescending "You're pretty good, for a girl!" award. It's to increase the visibility of women who are successful in the Agile community -- to adjust people's mindsets so that their idea of a successful Agile professional includes someone who happens to be female.

This has -- one hopes -- these benefits:

  • People in the Agile community become less likely to make negative assumptions about women in the community. Life for women in Agile gets better, in that they're less likely to be subject to sexist behaviour, like someone questioning their competence because they are female.
  • The Agile community is seen as a group that welcomes diversity. Women or other minorities who are considering taking part in the Agile community feel as though they are welcome to do so -- that they won't be singled out because of their gender, race, orientation, and so forth.

This isn't about trying to enforce some kind of "diversity quota". It's about making our community more aware of diversity issues, more welcoming for folks of diverse backgrounds, and a better place for everyone who's part of the community, regardless of their background.

What's this about "empowering women"? Is this all about women gaining power?

Protestations to the contrary aside, the phrase "empowering women" isn't about placing women above men. The starting point for this discussion is that women are disempowered, and so "empowering women" means to bring them to a place of equality. It's a level playing field that's being aimed for, not some kind of reverse sexism.

Gender & Biology 101

jamesmarcusbach: @lanettecream I guarantee you every normal male who works with you is actively suppressing certain thoughts. That's just biology.
Sat Jun 05 08:40:56 +0000 2010

I take exception to the insinuation that because I am male, there is some part of my mind that is perpetually thinking about sleeping with my female peers. This might be James' experience. It's not mine, and it's presumptuous and insulting to claim that it is.

Telling someone that she is constantly being viewed as a sexual object by all of her male peers, and further that this is the incontrovertible natural order of things, is not helpful. It's fucking creepy.

Gender & Biology 102

On the topic of biology: while it's been shown that men & women have neurological differences, it's a gross mistake to overgeneralize this and assume that all women tend to think in one way and all men in another. The differences between individuals are much greater than any biological difference between sexes. To use a coarse example: there are both women and men who are fantastic chefs. Even supposing that one sex has more inherent culinary ability than the other, that difference is completely eclipsed by the chasm in ability between individuals who are spectacularly talented cooks and those who are abysmal ones.

We have a whole bunch of different straight white guys on the team. Isn't that diversity?

There are two "diversities" that are being conflated in this discussion. I'll arbitrarily dub them "thought diversity" and "personal diversity".

Personal diversity has to do with each team member's background and who they are. Do they hail from Argentina, Australia, or Angola? Do they have a degree in computer science, philosophy, or none at all? What's their gender identity, their race, their class background? This is personal diversity -- the differences between the team members as individuals.

Thought diversity refers to the diversity of ideas that people come up with as a result of their different ways of thinking. Thought diversity is informed by each person's life experience, and thus by "personal diversity". Say two testers are trying to reproduce an elusive bug. Perhaps one will start by trying actions that have caused similar bugs in the past. The other might start by looking through log files to see if anything relevant turns up. These two different approaches represent thought diversity.

An Agile team needs to cultivate thought diversity because it needs different perspectives on problems to succeed. It needs welcome and support personal diversity not just as a means to engender thought diversity, but because it is the right thing to do. Treating someone inequitably is wrong. It's as plain as that.

Diversity's Not My Problem

Screw that, it's everybody's problem.

If we have an imbalance in who can take part in the Agile community, or in our industry -- if people are leaving the profession because they're being singled out for unfair treatment, or not joining it because they don't feel like dealing with the environment they'll find there -- that's a problem for all of us. By turning people away, we are missing out on talent and ideas that can help us propel our craft forwards.

If you care about the future of our industry, you should care about diversity. Think about it.

rickscott: Bemused-looking picture of Rick (Default)

Last weekend, a conversation about diversity took place on twitter between several prominent folks in the Agile and Testing communities. I think what was said needs to be archived for posterity, so I made a tool that helps do just that.

This is a straight-up transcript with no commentary. My response to some of the points that were raised is here.

Transcript of the conversation... )

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 Oct. 24th, 2017 02:28 am
Powered by Dreamwidth Studios