PragPub 2010-09: Issue #15

Table of Contents

Features

- Agile Flash Cards
by Jeff Langr, Tim Ottinger
For the past year and a half, Jeff and Tim have been capturing the wisdom of the Agile community and their own combined 20+ years of Agile and XP experience on index cards. In anticipation of the release of these cards in decks, they share a few Agile in a Flash cards with you here.

- The Key to Better Software
by Brian Tarbox
I’ve become convinced that the approach to quality taken by most companies is misguided and based on a flawed model. This is the reason why so many companies are having such trouble increasing the quality of the software they deliver.

- Building Trust
by Rachel Davies
When you’re coaching Agile teams, it’s essential to work on building trust from the get-go. Without trust, Agile simply doesn’t work. So how can we build trust on our teams so that Agile practices can take root?

- The First Robot
by Dan Wohlbruck
On September 20, 1928, Eric, the first human-looking robot, opened the Exhibition of the Society of Model Engineers in London. The inventors were inspired to build Eric when the Duke of York was unable to attend the ceremony opening the Exhibition. Eric proved to be a simple, successful replacement for the Duke of York.

Departments

- Up Front
by Michael Swaine
This month we introduce a new column by Pragmatic Programmer Andy Hunt, titled “Guru Meditations.”

- Choice Bits
In Philadelphia, you must buy a $300 license to blog. Meanwhile, Java is a restricted platform, Google is evil, Apple is a monopoly, Microsoft is the underdog, and jobs outsourced to India are being re-outsourced to unskilled Americans. We netted these and other amazing facts as we trolled the Twitterstream this month.

- Guru Meditation
by Andy Hunt
Context is everything, especially with agile methods.

- The Quiz
by Michael Swaine
I was inspired by Jeff Langr and Tim Ottinger’s article on Agile in a Flash to come up with a card-based quiz.

- Calendar
Brendan McAdams, author of the forthcoming MongoDB: A Quick Start Guide, will talk about “From MySQL to MongoDB,” “Scala + Mongo for Java Developers who don’t know Scala,” and “Python Development with MongoDB” at the MongoDB Conference in Boston this month. Also, the GNU Project turns 27. And other items for your calendar.

- Shady Illuminations
by John Shade
When I’m feeling more than usually insignificant, I remind myself of two things that give meaning to all our lives. I think of Schrödinger’s cat and anthropogenic global warming. But lately I’ve been finding both less comforting than I used to.

Except where otherwise indicated, entire contents copyright © 2010 The Pragmatic Programmers.

Feel free to distribute this magazine (in whole, and for free) to anyone you want. However, you may not sell this magazine or its content, nor extract and use more than a paragraph of content in some other publication without our permission.

Published monthly in PDF, mobi, and epub formats by The Pragmatic Programmers, LLC, Dallas, TX, and Raleigh, NC. E-Mail support@pragprog.com, phone +1-800-699-7764. The editor is Michael Swaine (mailto:michael@pragprog.com). Visit us at http://pragprog.com

ISSN: 1948-3562

Up Front

A Guru Meditation and Several Other Thoughts
by Michael Swaine
This month we introduce a new column by Pragmatic Programmer Andy Hunt, titled “Guru Meditations.” I’m pretty sure you’re going to like it a lot.

As the editor here, I have the tedious duty of making sure that nobody misses the in-jokes and obscure references. So let me give you this image

and this link. That should suffice.

I’ve allocated myself a little extra space this issue to talk with you about what’s coming up in PragPub. You won’t want to miss our December issue, when we’ll focus on Ruby. And if you’ve ever considered writing a book, or even an article, you really owe it to yourself to catch our November issue on becoming a writer. I have no idea what will be in the October issue. I’d explain that to you, but we’d be getting into the integral calculus of publishing schedules, and I’ve already bored you once.

Back to the present. To the issue that you have in your hands—so to speak. It’s a little disorienting to think that you may be reading this on our website or as a pdf file that looks something like a print magazine or in an appropriate format on your cellphone or Kindle. But however you’re reading it, it’s the content that matters. So...

In this issue you’ll find articles by Agile coaching guru Rachel Davies, Agile and XP experts Jeff Langr and Tim Ottinger, Motorola Distinguished Member of Technical Staff Brian Tarbox, and computer historian Dan Wohlbruck. They share their expertise in building trust in Agile teams, developing Agile flash cards, the need for continuing education in software companies, and the history of robotics.

Plus, of course, our usual events calendar, choice bits from the twitterstream, quiz, and off-center insights from John Shade. I think you’ll like this issue.

Okay, this next part is personal.

I’ve been an editor of tech magazines for about 30 years now, and I’ve never been more impressed with the caliber of writers I’ve been privileged to work with than I am with the programmer/writers who contribute to PragPub. And I say that as someone who’s edited tech writers from Margaret Wozniak’s son to Courtney Love’s father. Over 50 bright, witty, and generous authors—so far—have contributed to making PragPub the worthwhile and entertaining resource that I like to think it is.

These writers meet the deadlines and put up with the edits I make to their words and come through with equanimity when I give them 24 hours to read the final proofs and then say, oh by the way, I need a 50-line bio and a picture immediately. And they do it for, as I phrase it, payment in fame and gratitude. They deserve more than they get of both.

So allow me to thank Chris Adamson, Jorge Aranda, Kent Beck, David Bock, Tony Bove, Daniel Brolund, Ed Burnette, Paul Butcher, Frederic Daoud, James Duncan Davidson, Rachel Davies, Scott Davis, Ian Dees, Bill Dudney, Ola Ellnstam, Chad Fowler, Eric T. Freeman, Adam Goucher, James Edward Gray II, Phil Haack, Stuart Halloway, Dan Haywood, Rich Hickey, Brian Hogan, Rob Holland, Dave Hoover, Mike Hostetler, Jason Huggins, Andy Hunt, John Jainschigg, David Koelle, Jeff Langr, Andy Lester, David McClintock, Jonathan McCracken, Staffan Nöteberg, Tim Ottinger, Alan Oppenheimer, Paolo Perrotta, Steve Peter, Noel Rappin, Jonathan Rasmusson, Craig Riecke, Johanna Rothman, Ben Scofield, Maik Schmidt, Liz Sedley, John Shade, Eric Smith, Daniel Steinberg, Brian Tarbox, Bruce Tate, Mike Taylor, Dave Thomas, Dan Wohlbruck, and Marcus S. Zarra.

Thank you for what you do.

Choice Bits

He Said What?

A few selected sips from the Twitter stream.

What’s Hot

Top-Ten lists are passé—ours goes to 11. These are the top titles that folks are interested in currently, along with their rank from last month. This is based solely on direct sales from our online store.

1

1

Agile Web Development with Rails

2^

NEW

Pragmatic Guide to Git

3^

5

The RSpec Book

4

4

Hello, Android

5v

2

HTML5 and CSS3

6v

3

Test Driven Development

7^

9

Programming Ruby 1.9

8v

6

iPad Programming

9v

7

Seven Languages in Seven Weeks

10^

NEW

Agile Web Development with Rails, Third Edition

11^

NEW

iPhone SDK Development

The latest proof that our days are numbered.

I Don’t Make the Rules around Here

In Philadelphia, you must buy a $300 license to blog: http://tinyurl.com/2fslqkm — @trevorburnham

Under Sendek's proposed naming schema, the sun would weigh 2.2 hellatons, and release 0.3 hellawatts of energy http://goo.gl/kmFR — @codinghorror

This Enterprise Agile Manifesto would be hilarious if it weren't so accurate - http://bit.ly/akrs8S — @mheusser

OH: "candidate must still like Java" :) — @dalmaer

Why do all that major mattress brands start with the letter "S"? — @ronhitchens

Error Bits

Everything's going along fine, then the ewoks show up & ruin the whole movie. — @neal4d

hey internet girl who quit with a whiteboard: next time start your meme on a day when someone doesn't quit with the AIRPLANE EMERGENCY SLIDE — @StephenAtHome

Hey, Paul Allen: if those Interval Research patents have value, how come a billionaire like you couldn't turn them into products? — @pragpub

RIP wave - an incredibly innovative solution for a problem apparently no one had — @markryall

Still no results for "Peggy Olson headdesk"; it is proven that Mad Men viewers and animated gifs creators are wholly distinct sets. — @therealadam

So apparently the SETI conference was held here last week. Bellman says "They didn't find any." — @clarkware

aw man, there's almost no calvino available in the kindle store. that blows. — @bscofield

I really like Hipmunk (http://www.hipmunk.com) any travel site that has a "sort by agony" button understands its customers — @Werner

Gods and Monsters

Welcome to the new decade: Java is a restricted platform, Google is evil, Apple is a monopoly and Microsoft are the underdogs — @phil_nash

It's obvious that James Gosling's poor web server can't handle the assault of everyone who wants to know his thoughts about SCOracle. — @olabini

I once saw HTML5 walking across a lake to heal an injured swan. #html5keyfacts — @Cennydd

Best quote from the HN comments: "What Google is doing should be illegal. What Oracle is doing is immoral." — @tswicegood

The Flying Spagetti Monster is the descendant of some Flightless Manicotti. — @MrAlanCooper

Sick of seeing my "welcome to the new decade" tweet? Now you can be sick of my blog post about it too: http://bit.ly/cBi0ZH — @phil_nash

This Coding Life

Either printer ink is made from unicorn blood or we’re all getting screwed. — @theoatmeal

My new iPhone charging cable is nasty, brutish, and short. — @scottdavis99

Rails uses symbols so excessively I just started writing :true and :false *facepalm*. — @grahamedgecombe

So many great practices and habits are caught, not taught. Who are you spending time with today? — @jaredrichardson

Send a question to IT group; get a meeting invite as a response. That is efficiency by God! — @mzarra

When you don’t create things, you become defined by your tastes rather than ability. Your tastes only narrow and exclude people. so create. — @mikemangino

Jobs outsourced to India re-outsourced to unskilled Americans! http://bit.ly/9tMlDI — @kabirkhan

Bottlenecks often walk around on two legs. — @mtnygard

Friends don't let friends use class variables. #ruby — @mjijackson

RT @r: Facebook Places is going to do away with the need for Foursquare the way Facebook status updates did away with the need for Twitter. — @dalmaer

Ruby has ruined my ability to write Java without irritability, resentment and superciliousness — @markryall

Tablet + resistive touchscreen + desktop OS = thoroughbred racehorse + blindfold + amputated leg. — @mattgemmell

New drinking game: when a speaker refers to people as "resources", then throw a drink at him. #agile2010 — @jbrains

Newsweek was just sold for $1. To show you how media has changed, the asking price for my twitter account is 65 billion dollars. Cash. — @ConanOBrien

I forgit how I lived without git these many years. — @venkat_s

#agile2010 Programmers started the agile movement to get closer to customers not project mangers. — @unclebobmartin

Was @flipboard designed to prevent rickrolling, or is that just a happy accident? — @invalidname

If only social awkwardness was considered performance art ... — @markryall

Timeless Wisdom

People fascinated by the idea of progress never suspect that every step forward is also a step on the way to the end. — @MyraTrembath509

This hermit crab is either dead or molted or dead b/c I disturbed its molt. It's the Heisenberg uncertainty crab in a schroedinger aquarium. — @hodgman

Once you've seen one picture of the Mandelbrot set, you've seen them all. — @billkarwin

Hygeine is a human concern. Animals have 2 groups: those who don't bathe, and those who urinate in bathwater. — @tottinge

This month we were following a whole bunch of software developers, technical writers, and deep thinkers—including Chris Adamson, Dion Almaer, Ola Bini, Cennydd Bowles, Trevor Burnham, Mike Clark, Stephen Colbert, and Mister Alan Cooper.

Also Scott Davis, Graham Edgecombe, Neal Ford, the two Matts, Gemmell and Heusser, as well as Ron Hitchens, John Hodgman, and the inimitable Coding Horror.

And we would be amiss if we failed to mention Michael Jackson, Kabirkhan, Bill Karwin, Adam Keys, Mike Mangino, Uncle Bob Martin, Phil Nash, or Michael Nygard.

Also The Oatmeal, The Onion, and Conan O’Brien—plus of course Tim Ottinger, J. B. Rainsberger, Jared Richardson, Mark Ryall, and Ben Scofield.

And last alphabetically but certainly not least, Venkat Subramaniam, Travis Swicegood, Myra Trembath, Werner Vogels, and Marcus Zarra.

We were also following a guy who had his turn signal on for the entire trip. You can follow us on twitter.

Guru Meditation

The right thing at the wrong time and place is still wrong.
by Andy Hunt
Parsing the error messages of life

If you ever had the pleasure of working with the Amiga operating system in the good old days, you may have experienced a whimsically-named “guru meditation” error. These errors were reported as a long chain of inscrutable numbers that only a guru could decipher (hence the name).

In that spirit, this monthly column is going to look at real-world “error messages” (problems) that you might run into at work or at home, and hopefully offer some possible fixes. This month, we’ll start off with one of my favorite topics.

All the Difference in the World

If you follow my books, articles, blog and twitter postings, you might notice I have a certain preoccupation with the idea of context. That is, the importance of the situation and surroundings of an event more so than the event itself.

In the agile world, we often say that every project needs its own methodology; every project is different. There are no “best practices,” merely some practices that work better than others in certain circumstances. But it’s important to realize what makes every project different. It’s not necessarily the team, the features, or the technology that you’re using. Every project is different because the entire context is different.

Think of what might have changed. The expectations of the sponsors. The time of year. The skill level of the team (for better or for worse). Incompatibilities brought on by new versions of software that you’re using. The list goes on and on. Just because something worked well last year, there is no guarantee that it will work well now.

For example, have you ever heard the story of award-winning violinist virtuoso Joshua Bell? In 2007, he participated in an experiment wherein he played incognito in the Washington DC subway for 45 minutes on a $3.5 million Stradivarius violin.

He performed six difficult pieces with world-class finesse, and yet most of the thousands of passersby didn’t even stop to listen. Some 27 folks chipped in a total of $32 to the musician, and only seven people actually stopped to listen. Three days before this experiment, Bell played to a packed house in a highly respected venue at $100 a seat.

The music was the same, the performance was the same, but the context was wildly different. In the concert hall, the audience had paid a substantial amount of money each to see this performer. They were appreciative and knew what they were listening to.

But in the subway, it is a completely different context. It’s an unexpected event, and people aren’t always sure how to react. How do you know if the performer is even any good? Do you throw some change in the hat just to be polite anyway? Is it worth your time to stop and listen? If you’re like 98% of us, you just hurry past and ignore the performance.

Great things aren’t great by themselves. Great things are only great in the proper context.

Educate the audience

Now think of the violin example in the context of introducing an agile technique or methodology. That's something we're often tasked with trying to accomplish, whether it’s a new technique to an experienced group of agilists or introducing the basics to a group of novices.

Just as with the violinist, if you’re playing to an appreciative audience who knows what they’re listening to, knows why they’re there, and has invested in being there, then you will probably find the experience to be ultimately successful.

On the other hand, if that very same agile technique or methodology is playing to an audience who is hurrying on their way in a different direction, isn’t sure whether to trust it or not, and doesn’t know if it’s any good, guess what the outcome will be? They might “throw a few coins,” metaphorically speaking, but mostly they will simply hurry on their way. And ignore it.

The solution in this case is to properly prepare, even educate, the audience: to help set up a similar context to that of the official concert. Imagine the subway scenario a little differently: posters up the week before announcing a rare, free appearance by virtuoso violinist, playing a genuine Stradivarius violin built in 1713. A brief bio of the violinist. History of Stradivari instruments; maybe a little science poster on the centuries-old search to discover their secrets. Now the audience knows what to expect—they might even go out of their way to participate. They’ve got some background to know that it’s considered “good,” that the player is eminently qualified, and that this is probably a good opportunity.

So you want to introduce unit testing, or the stand-up meeting, or continuous builds, or pair-programming? Want to introduce Kanban to folks who’ve only done XP, or vice-versa? You’ve got to set the stage, and establish context, before introducing or demonstrating anything, or you might look like just another crank in the subway.

Gently introduce the facts, but also casually introduce the excitement, the benefits, the interesting side-effects, the emotional resonance that will get your team and your boss eager to see how this works. That’s the context you need to create first—something close to the context you yourself felt when you discovered this new thing.

Something to think about.

Andy is a Pragmatic Programmer, author of a bunch of books, and dabbles in music and woodworking. Follow him on Twitter at @PragmaticAndy, at his blog andy.pragprog.com, or email him at andy@pragprog.com. Send the editor your feedback or discuss the article in the magazine forum.

Agile Flash Cards

Quite Possibly the Most Versatile Tool on the Planet
by Jeff Langr, Tim Ottinger
Your humble editor is a believer. When my significant other was managing editor of MacUser magazine, her most powerful management tool was a deck of index cards.

For the past year and a half, we have been creating Agile in a Flash index cards in blog form. These cards capture the wisdom of the Agile community plus our combined 20+ years of Agile and XP experience. The Agile community has generated many memorable mnemonics and lists, starting with the four values espoused in the Agile Manifesto, and including such stock phrases as “Red-Green-Refactor.” We’ve added a number of cards that represent our own inventions, such as Tim’s FIRST mnemonic that describes the qualities of a good unit test.

Our goal for the project was to produce a distributable deck of real, physical index cards. Many in the Agile community use index cards heavily to capture stories, later using these cards for planning and communication purposes. Capturing much of the essence of Agile thought in a handy card deck seemed so obvious to us that we’re surprised no one had done it before.

You can use the cards in many ways—as references, reminders, discussion points, posters on the wall, or even paper airplanes acting as air mail. You might even consider using them as the musician Brian Eno did with his Oblique Strategies card decks in the 1970s. The idea behind Oblique Strategies was to inject random ideas into the process of creating music, such as “Discover the recipes you are using and abandon them,” or “Go to an extreme, move back to a more comfortable place.” It’s amazing how many of the Oblique Strategies cards can provide useful insights for an Agile team. One card simply states, “Courage!,” an important XP value that mirrors one of our Agile in a Flash cards.

The cards in the Agile in a Flash deck can similarly work as triggers for new ideas. Struggling with what to tackle during retrospectives? Pull out a random Agile in a Flash card. Use the card to trigger discussions around how well your team is adhering to the advice. Then figure out what’s lacking.

The Deck

In our eighteen months of blogging, we’ve produced almost 90 different cards. In preparation for publication, we carefully chose a deck of the best cards. The deck contains four categories:

- The Idea—cards relating to Agile itself, including its values and principles.

- The Plan—cards around stories, planning, and estimation.

- The Team—cards discussing team practice, such as retrospectives, stand-ups, and pairing.

- The Code—cards covering technical, code-oriented topics, such as TDD, continuous integration, and refactoring.

Each card provides a summary list or diagram on its obverse side and more detailed information—including nuggets of our experience-based wisdom—on the reverse. The nuggets are condensed, mind you: There’s not a lot of space on an index card to be wordy!

The Pragmatic Programmers are helping us realize our goal of distribution. We’ll share a few Agile in a Flash cards with you here. These are meta-cards—cards about the use of cards themselves.

Why Cards?

We love index cards for their versatility as a tool.

Cards are low-tech and high-touch. You can put your hands on them, hand them to other people, stick them on the wall, tape them together, sort them on the desktop, etc. Having a tactile device such as an index card can make various workspace rituals possible (like moving a card from “in progress” to “done”).

You can dynamically reorganize cards to order them by point cost, functional area, assigned teams, or originators. You can use cards to discover and create connections that no one intended originally. This puts index cards a step above most software programs—you can routinely repurpose them on the fly.

Cards can hold schema-free markup. For instance, the security or documentation team can write notes on them. Developers and product owners can mark them up with issues or orderings. You can annotate them with priorities, pictures, or notes with arrows. Or they might be so stark as to contain only a two-word name. If you have a card and a marker, your only constraints are space and penmanship.

Cards are reminders for much bigger ideas. Being small, cards hold very little content. Yet they can have vast evocative powers. Once we discuss a story in depth, a two-word description written on a card is memorable enough to recall the discussions for the next couple weeks as we build the story. Our Agile in a Flash deck can also provide this power: Once you know a principle or practice, a card bearing as few as three words can help you do your job better.

As small physical items, cards are extremely portable. You don’t have to copy them to a USB drive or mail them to your teammates. You can use them on the bus, train, or hiking trail. The cards don’t mind being without web access and are immune to OS and browser incompatibilities. They move through airports without setting off metal detectors. Wherever you are, the cards are the same.

Cards are inexpensive and replaceable. Of course, you never want to be without your Agile in a Flash cards, but you can lose most other cards without any real cost. Tucking cards into jean or shirt pockets can expose the cards to the danger of a washing machine. But if they are important, you can easily reproduce your cards. If not, maybe you didn’t really need them (Mom always said, “It must not have been that important!”). Every day we can tear up a story card or two is a good day. Cards are not heirlooms to be maintained for the life of a project, and that makes them even better.

The Three C’s

Ron Jeffries refers to story cards as tokens. The cards do not provide every last detail to be implemented regarding a customer’s needs. Instead, when a development team has availability to work on something, the customer tells them a story about business needs. The team and customer discuss the story in further detail, until the team understands the story well enough to understand its scope and when they might be able to deliver it. The card captures a terse summary of the story, a simple placeholder or token.

The customer and team will need to continue conversations around the story as the iteration or sprint progresses. Often, the customer will omit at-the-time unnecessary detail when they first present the story to the team. The card is a reminder that both parties will have to continue discussions around exactly what should be built.

The specifics of what we’re building must ultimately be clear to the customer and the team who will deliver. The customer captures these criteria in acceptance tests, designed to exercise the system in enough ways to demonstrate that the feature really works. When all members of this set of acceptance tests for a given card pass, it confirms to the customer that the story is truly done—the software does what they asked. The nebulously stated card can disappear—the remaining documentation is the system plus its acceptance tests.

Story Card Format

Mike Cohn popularized this story format in his book Agile Estimating and Planning. It provides a simple template that you might consider for how you word the story summaries on your cards. “As an actor, I want to accomplish some goal, for some reason.” For example, “As an administrator, I want to see a list of multiple login failures, so that we can identify potential security breaches.” A story summary written in this form is almost like a condensed use case.

Using the story card template can provide some value. On a simple level, a standard template can help prevent wasteful arguments over formatting and wording. Thinking about the actors involved (the “as a” people) can help trigger the introduction of important stories that you might otherwise miss. The phrase “I want to” reinforces that stories are goals customers want users of the system to be able to accomplish, and not just technical pipe dreams. “So that?” As you write out dozens of stories in release planning, you’ll want to remember the rationale behind certain stories (but not all of them!) And sometimes understanding the “why” can trigger other useful considerations.

But before you insist that every card follow this rigid format, remember that the story card ain’t the thing, it’s a reminder that should stimulate more communication. It could be that the card has just one word on it, and that’s sufficient. During the course of your iteration or sprint, you’re not going to forget who the story is for, nor why it exists. Remember: The story card should disappear once implemented. The story details about what, how, who, and why are best moved to the acceptance tests.

We prefer a more spartan story summary on our card, viewing the boilerplate parts as oh-so-much-duplication that we would immediately stamp out if we found it in our code. But if you like the format, use it. Just make sure you re-assess the worth of your choices from time to time.

Last Thoughts

The cards we present as part of the Agile in a Flash project are tools, not gospel. They should help by prodding you if you get stuck and by giving you ideas providing guidance. In most cases, you should follow their advice unless you have darned good reasons not to. Even then, you should only take your own path once you understand why the advice exists.

Jeff Langr has been building software for over a quarter century. He is the author of Agile Java and Essential Java Style, plus more than 80 articles on software development and a couple chapters in Uncle Bob’s Clean Code. He runs Langr Software Solutions from Colorado Springs and happily builds software as an employee of GeoLearning.

In addition to developing the Agile in a Flash card deck with Jeff, Tim Ottinger has over 30 years of software development experience including time as an Agile coach, OO trainer, contractor, in-house developer, and even a little team leadership and management. He is also a contributing author to Clean Code. He writes code. He likes it. Send the authors your feedback or discuss the article in the magazine forum.

The Key to Better Software

Training, not Enforcement, Is the Key to Quality in Software
by Brian Tarbox
Brian looks outside software development and notes that the kinds of solutions that work are not the kinds typically employed in software development companies.

I’ve become convinced that the approach to quality taken by most companies, especially large companies, is misguided and based on a flawed model. This use of the wrong model explains why so many companies are having such trouble increasing the quality of the software they deliver.

To explore the various models available let’s look at some other businesses and see how they deal with quality issues.

Speed Bumps

If your local town has an issue with bad traffic behavior, that can be seen as a quality issue—one with potentially life-threatening consequences. The approaches available to solve traffic problems are basically structural and enforcement. Structural solutions are such things as adding speed bumps or turn lanes. Enforcement is adding more police patrols or radar traps.

Structural solutions are appealing because they work. You simply cannot drive very fast on a road with speed bumps. In the software world structural solutions to quality are things like Code Coverage or code style checks that run automatically as part of the check-in or build process. You simply cannot check-in or build code that violates the structural standard. The downside of structural solutions is that they do not change underlying attitudes.

Software enforcement models are things like after-the-fact code inspections or Failure Review Boards (FRB). Both are focused on determining why an error occurred rather than on preventing it from happening in the first place.

Dance Class

OK, now shift gears to another venue: your child’s sports team (or music or dance lessons—the point is the same). Although some bowling alleys have gutter guards that prevent a ball from rolling into the gutter, in general you’ll rarely run into structural solutions in these venues. You can’t really build a ball that can’t be dropped and you can’t structurally prevent a dancer from dancing “wrong.”

So, that leaves enforcement. To improve your child’s Little League performance do you hire more umpires? At your child’s piano class do you hire someone to blow a whistle whenever they play the wrong note? Of course not: you hire a coach or a teacher.

This is a laughably obvious conclusion in these venues but most software companies have lost sight of it.

We expect our engineers to write better code but by and large we give them no training in how to do so. Most professions have rigorous continuing education requirements. Doctors, lawyers, psychologists, dental hygienists, and teachers all must take a certain number of classes per year to maintain their standing as professionals. Yet in our field there is no such requirement.

Continuing Education

This is both a top-down and a bottom-up problem. Most engineers don’t ask for training and most managers don’t suggest it. Ask yourself: does your company include continuing education in its appraisal of your performance at review time? Does your company offer classes in Refactoring, Test Driven Development, Agile Methodology or Code Inspection? If they don’t, they are making a statement that they do not value software quality. They’re not aware that they’re making that statement but they’re making it nonetheless. Shifting to personal responsibility, do you as an individual contributor believe it’s your manager’s job to assure your future employability? It’s not—the only person responsible for your future employability is you. If your company doesn’t make ongoing education a priority that doesn’t mean that you can’t.

Be assured that the next time you interview for a job you will be asked, “So how have you maintained and enhanced your skills?” If you say you haven’t, the interview will be over.

It’s time for a sea change in how we get to quality. Enforcement alone doesn’t work, we need to combine it with training. Companies need to offer it, managers need to recommend it, and engineers need to ask for it.

Brian Tarbox is a Distinguished Member of Technical Staff at Motorola where he designs server side solutions in the Video On Demand space. He writes a blog on the intersection of software design, cognition, and Tai Chi at briantarbox.blogspot.com. Send the author your feedback or discuss the article in the magazine forum.

Building Trust

The Equation for Successful Agile Teams
by Rachel Davies
Trust Rachel to spell out exactly how to build trust in Agile teams.

When you’re coaching Agile teams, it’s essential to work on building trust from the get-go. Without trust, Agile simply doesn’t work. Low-trust organizations that rely on heavyweight processes pin work on individuals so they know whom to blame if things go wrong. Agile methods allow us to cut down on project bureaucracy by depending on team collaboration and short feedback cycles to establish a steady stream of deliveries. However, when I don’t trust my teammates to get stuff done towards a shared goal, then Agile practices fall down flat.

So how can we build trust on our teams so that Agile practices can take root?

Create a Safe Place

The first step is to create a safe container for the individuals working on the team. To take on new working practices, your team needs to have space to make mistakes and recover from them. You can make a start by installing basic Scrum. (Other Agile approaches such as Kanban or XP create the same effect, as they all have standup meetings and mechanisms to limit work-in-progress.)

Scrum is all about creating the conditions for a team to focus on one stream of valuable items that can be delivered incrementally. Both the Product Owner and ScrumMaster roles help buffer the team from constant interruptions and changing priorities. The sprint time-box gives the team a clear run towards delivering a product increment that they feel is a realistic commitment. Each person on the team makes small commitments to each other at their daily stand-up meetings. They either deliver on those commitments or must face up to asking for help. Through this shared experience, trust starts to build between team members. They also get to know each other a whole lot better by sitting together and participating in the regular meetings that drive the Scrum delivery cycle.

Accelerate the Process

In my experience, relying on these basic Agile practices to build trust takes time. I’ve found that you can spot ways to accelerate trust building by considering this Trust Equation (The Trusted Advisor by David Maister, Charles Green, and Robert Galford):

T = (C + R + I) / S

The letters in this equation represent, Trustworthiness = Credibility + Reliability + Intimacy divided by Self-orientation, where:

- Credibility relates to expertise. I need confidence that the person I am placing my trust in has the skills and knowledge to meet their commitments.

- Reliability relates to being organized enough to actually get work done. I want to be able to depend on a person to meet their commitments.

- Intimacy represents the degree to which another person cares about the needs of their team mates.

- Self-orientation reduces trust because we’re more cautious about people who put themselves forward first. We worry that they may have a hidden agenda.

Put the Theory to Work

As we already saw, Agile practices work on the R and I factors by establishing a way for small commitments to be met and also increasing opportunities for team interactions in the team room and in team meetings. You can bolster this by running a workshop to create team working agreements that make your team’s current norms and values explicit. Now everyone feels more comfortable about working together within this shared understanding. If these working agreements get broken, work with the team to understand why and adjust their practice or the working agreements accordingly.

The trust equation also shows us that there are more areas that you can focus on to boost trust in your team. You can help your team raise its credibility by creating opportunities for team members to improve their technical skills. For instance, you can set up a Coding Dojo to encourage learning from each other and broadening skills on the team. The consequent increase in skill should increase trust amongst team members. Help the team get started on improving their learning by setting an example, show them books that you’re reading, and leave them around at work. Tell your team mates about conferences and user groups that you’ve been to and offer to take them along.

You can also work to reduce self-orientation (the ‘S’ in the equation) by removing incentives targeted on individual performance and instead rewarding work toward achieving team goals. Invest in shared facilities where the team can socialize, such as a foosball table, and organize team outings to boost intimacy (the I in the equation) between team members. Intimacy between team members can also be enhanced by workshops, where the team share personal histories or compare personality profiles (such as Myers-Briggs Type Indicator). Even simpler, create more opportunities for team members to get to know each other more naturally through regular social time, such as team lunch on Wednesdays.

Work from the Inside Out

Last but not least, building trust starts from the inside out. There are many ways for you to build trust on your team in the way you interact with team members. Be the first to ask the dumb questions. In acting as a role model, you demonstrate that it is safe to expose your ignorance in order to learn. Act with integrity, keep your promises, and live up to your espoused Agile values. Most powerful of all, radiate your trust in others by placing confidence in them to meet their commitments without interference from you.

The co-author of Agile Coaching, Rachel Davies works as an Agile coach helping teams adopt and improve their Agile delivery capability. She has a wealth of experience in a range of Agile methods, including XP, Scrum, Lean/Kanban, and DSDM. Rachel is a keen supporter of the agile community, she served 7 years on board of Agile Alliance and continues to apply her organizational skills to Agile conferences including XPDays, Agile Coach Gathering, and XP2011. Find out more at www.Agilexp.com. Send the author your feedback or discuss the article in the magazine forum.

The First Robot

It Happened 82 Years Ago This Month
by Dan Wohlbruck
Dan Wohlbruck adds to his series of “When Did That Happen?” essays with the story of the first human-looking robot. He reports, somewhat surprisingly, that “Eric was a simple, successful replacement for the Duke of York.”

On September 20, 1928, Eric, the first human-looking robot, opened the Exhibition of the Society of Model Engineers in London. Captain William Richards, a journalist and WWI veteran, and A. H. Reffell, an engineer, were the inventors. Captain Richards was inspired to build Eric when the Duke of York, who was invited to open the Exhibition, was unable to attend the ceremony. Eric’s presentation is described by the cyberneticzoo.com web site in this way:

“Eric arose, bowed, looked to the right, to the left, and, with appropriate gestures, proceeded to give a four minute opening address.”

Eric was made of aluminum and weighed about 140 pounds. Eric’s movements were powered by small electric motors and his eyes were electric light bulbs. Eric’s voice was sent by wireless radio transmission and broadcast through a speaker in his mouth. Eric couldn’t think and he didn’t have any computational ability. Eric was a simple, successful replacement for the Duke of York.

(Eric can be seen here.)

Other Pioneering Robots

Eric was not the first human-looking machine ever designed, however. None other than Leonardo da Vinci took up the subject of robots. In 1957, an Italian researcher, looking through da Vinci’s papers, discovered a plan for a mechanical knight. The design included diagrams for gears and motors to power the warrior. In 2002, for a BBC documentary, Leonardo’s robot was actually built.

Following Eric the Robot were a number of other human-looking but not very human-working machines. During World War II, however, serious work was begun to make human replacements. In 1943, Warren McCulloch and Walter Pitts pioneered neural networks. In 1946, George Devol invented a device that controlled machines using magnetic recordings; and in 1948, Norbert Wiener, then at MIT, published the landmark book whose title coined the term Cybernetics. Also in 1948, a little-known inventor named William Grey Walter built two mechanical turtles named Elmer and Elsie that actually looked, moved, and acted like turtles.

In 1956, at a conference in Dartmouth, Marvin Minsky and John McCarthy coined the phrase artificial intelligence to describe robotic thinking machines.

From Elmer and Elsie, we jump ahead to 1961, when the first industrial robot went to work taking die castings and welding auto bodies on the General Motors assembly line. The robotic arm, named Unimate, weighed about 4,000 pounds and executed program instructions stored on a magnetic drum. Unimate was the creation of Devol and Joseph Engelberger, who founded the company Unimation. To the present, Unimate is the most successful of all industrial robots.

By 1973, the focal point of robot development had moved from the UK, through the US, to Japan, where Waseda University demonstrated Wabot-1. Wabot-1 was the first full-scale anthropomorphic robot built in the world. It had separate systems for limb control, vision, and communication. The Wabot-1 spoke Japanese and used artificial ears, eyes, and an artificial mouth. The Wabot-1 walked with legs and gripped with hands that used tactile sensors.

A 400-Pound Mechanical Insect

The race was on. In March 1982, Odetics, Inc. of Anaheim, California, introduced the ODEX I and even created a new word to describe the machine: functionoid. ODEX I walked on six legs and weighed less than 400 pounds. Odetics said that ODEX I demonstrated attributes unique to “mobile, nonfactory robotics.” In reporting on the functionoid, Robotics Age magazine wrote, “Odetics intended the first functionoid to be part of a dawning era in the robotics industry in which a multifunctional unit could literally walk away from the factory floor and perform virtually anywhere.”

Not to be outdone, in 1986, Honda introduced the first model of its ASIMO robot. ASIMO is a bit smaller than an average adult, and by 2005 it had 34 degrees of freedom of movement (three in the head, seven in each arm, two in each hand, one in the torso, six in each leg).

Despite being human-looking or even human-acting, the robot achieves the goal of replacing humans only in the movies and in science fiction. In 1940 and 1941, Isaac Asimov began his series of robot novels and short stories. Then, in 1950, he published the book I, Robot, which is a collection of many of his short stories. It is in one of these short stories that Asimov introduced his famous Three Laws of Robotics. Asimov’s books inspired the landmark characters C3P0 and R2D2 from Star Wars.

In Asimov’s book Foundation and Earth, the robot Daneel is found alive on the moon. He has existed for 20,000 years and he admits that he has been gently guiding the progress of the galaxy and abiding by the Laws of Robotics.

The challenge of building machines to replace humans is not over. It began over 80 years ago with Eric the Robot—and that’s when it happened.

Dan Wohlbruck has over 30 years of experience with computers, with over 25 years of business and project management experience in the life and health insurance industry. He has written articles for a variety of trade magazines and websites. He is currently hard at work on a book on the history of data processing. Send the author your feedback or discuss the article in the magazine forum.

The Quiz

Playing Cards in the Bizarro World
by Michael Swaine
Jeff Langr, Tim Ottinger, and I have invited you over to the pub for a friendly game of cards. You’re thinking maybe poker or pinochle, but Jeff and Tim suggest Agile in a Flash. I overrule everyone and announce that we’re going to play Bizarro Poker. I ignore the grumbling.

“In Bizarro Poker,” I explain, “you hold your cards backwards, so that everyone but you can see them. The goal of the game is to figure out what your hand is.” From five decks of standard playing cards, I remove all jokers, face cards, and tens. I shuffle the decks together. Tim folds his arms and glares at me, while you and Jeff look skeptical, but I’ve supplied cookies, so nobody actually gets up and walks out. “And in Bizarro Poker,” I go on, “suits are ignored. Only the values on the cards matter.”

I then bring out from under the bar a second deck. These cards look different. They are ordinary index cards, and a few words are written on the face of each one.

“These are the Question Cards,” I say. “Each one has a question on it regarding the other cards. We will each draw a Question Card in turn, reading it aloud. When you have asked your question, you then answer it aloud.”

Tim frowns. “Surely you mean that everybody else has to answer it?”

“That sounds right, doesn’t it?” I answer. “But this is Bizarro Poker, so you don’t do what sounds right. You ask the question and then you answer it yourself.”

“Whatever,” Jeff says. “Let’s get started.”

I deal three cards to each of the four of us, face down. “Now pick up your cards and hold them so that everyone but you can see what you have.” When we have all done this, here is what you see:

- Jeff: 2 of hearts, 4 of clubs, 8 of spades

- Tim: 4 of spades, 5 of diamonds, 8 of spades

- Mike: A of diamonds, 5 of hearts, 5 of spades

- You: (you don’t see your cards)

I now place the Question Deck on the bar within reach of all of us. “The player at the dealer’s right starts.”

“Oh, I guess that’s me,” Tim says. He draws a card from the Question Deck. He reads, “Are there more than two players who have the same total?” He looks at everyone else’s cards and answers, “Yes. And we’re out of cookies.”

I refill the cookie plate while Jeff draws a Question Card. His question, “How many different even numbers do you see on the cards?” gives him no trouble. “Four,” he says promptly. “And how is it possible that Tim and I both have an eight of spades?”

“Multiple decks,” I explain. “There could be as many as five of any particular card in play. Besides, I told you that in Bizarro Poker we don’t pay any attention to suits. So you should just think of those as eights.”

“Yes but if there are—”

Tim interrupts, “OK, I know what I have. Does that mean that the game is over?”

“It does,” I say, “And if you’re correct you win. But everyone gets a chance to be a winner. Does anyone else know what their hand is?”

You look carefully at the cards in everyone else’s hands and reflect on what you’ve heard. You know that Jeff is a smart and serious guy and wouldn’t be mistaken, nor would he bluff. So—yes, you know what you have!

What cards do you hold?

This simple puzzle has an interesting history. I’ll leave it as a banus exercise for you to track down the original form of the puzzle and to check out the other puzzles created by its tricky inventor.

Solution to Last Issue’s Quiz

Many of the technical terms that we use every day in programming also have a common meaning more or less unrelated to their programming meaning.

A bit is something you use to control a horse; a fork is something you eat with; inheritance explains where you got those blue eyes or that white elephant.

Last issue’s quiz presented ten lists of programming words that have a different meaning in ordinary conversation. We ran all the words through our handy-dandy Cryptogram Machine, so they would not be immediately recognizable.

We organized the words into these ten lists as an aid to solving. In each list, the words—taken in their ordinary meaning rather than their programming meaning—share a common theme. The themes and the decrypted words are:

The Write Stuff:

- Binding

- Page

- Type

- Author

- Library

- Editor

- Sequel

- Word

Construction:

- Dock

- Factory

- Block

- Architecture

- Assembly

- Loader

- Link

- Driver

Animal, Vegetable, Mineral:

- Tree

- Leaf

- Root

- Python

- Ram

- Virus

- Worm

- Bug

- Ruby

Baseball Been Very, Very Good to Me:

- Catch

- Throw

- Base

- Double

- Swing

- Tag

- Hit

- Run

- Error

Conversation:

- Dialog

- Declaration

- Expression

- Argument

- Comment

- Smalltalk

Sew What:

- Lint

- Spool

- Thread

- String

- Loop

- Patch

Theater:

- Cast

- Actor

- Character

- Script

- Mask

Kid Stuff:

- Sandbox

- Swing

- Pop

- Cookies

Grab Bag:

- Path

- Fencepost

- Stream

- Float

Discards:

- Garbage

- Dump

- Heap

- Trash

Calendar

Author sightings, partner events, and other notable happenings.

Author Appearances

- Sept 3–4, Ruby Hoedown, Nashville, TN
“There’s A Wheel For That Already—Hidden ‘gems’ in the Ruby Standard Library” Brian Hogan, author of Web Design for Developers: A Programmer's Guide to Design Tools and Techniques

- Sept 10, miniSPA, London, UK
“Retrospectives Refactored”Rachel Davies, author of Agile Coaching

- Sept 11, WindyCityRails, Chicago, IL
“Testing in a Legacy Environment”Noel Rappin, author of Rails Test Prescriptions: Keeping Your Application Healthy

- Sep 12, No Fluff Just Stuff New England Software Symposium, Boston, MA
Several talksJohanna Rothman, the author of Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects, Manage It!: Your Guide to Modern, Pragmatic Project Management, and Behind Closed Doors: Secrets of Great Management

- Sep 16, Agile Boston Open Space 2010, Waltham, MA
“It’s the People; It’s All About the People”Johanna Rothman, the author of Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects, Manage It!: Your Guide to Modern, Pragmatic Project Management, and Behind Closed Doors: Secrets of Great Management

- Sept 20, MongoDB Conference, Boston, MA
“From MySQL to MongoDB at Sluggy.com,” “Scala + Mongo for Java Developers who don’t know Scala,” and “Python Development with MongoDB”Brendan McAdams, author of the forthcoming MongoDB: A Quick Start Guide

- Sept 22–24, Pragmatic Studios, Reston, VA
“Rails Studio”Dave Thomas and Chad Fowler, the author of The Passionate Programmer: Creating a Remarkable Career in Software Development

- Sept 27–28, JAX, London, UK
“Coaching Teams over Acceptance Testing Hurdles”Rachel Davies, author of Agile Coaching

- Sept 27–29, iPhone/iPad Dev Con, San Diego, CA
“Advanced Core Data: Building Your Own NSFetchedResultsController” and “Advanced Core Data: Importing and Exporting Data Efficiently”Marcus Zarra, author of Core Data: Apple's API for Persisting Data on Mac OS X

- Sept 27–29, iPhone/iPad Dev Con, San Diego, CA
“Coming Up to Speed on Objective-C and Model-View-Controller,” “Mastering iPhone OS 4.0: What’s New, What’s Changed,” “Moving to the iPad: What You Need to Know,” “Building Killer Universal Apps for iPhones and iPads”Daniel Steinberg, co-author of iPad Programming: A Quick-Start Guide for iPhone Developers and author of Cocoa Programming: A Quick-Start Guide for Developers

- Oct 5–6, Agile Business Conference, London, UK
“Building a Culture of Trust”Rachel Davies, author of Agile Coaching

- Oct 14–15, Strange Loop, St. Louis, MO
“Mary Poppins meets the Matrix”Bruce Tate, author of Seven Languages in Seven Weeks

- Oct 14–15, Agile Cambridge conference, UK
Keynote on “Building trust in Agile teams” and workshop on “Creating Agile Environments”Rachel Davies, co-author of Agile Coaching

- Oct 15–16, No Fluff Just Stuff Twin Cities Software Symposium, Minneapolis, MN
Several talksJohanna Rothman, the author of Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects, Manage It!: Your Guide to Modern, Pragmatic Project Management, and Behind Closed Doors: Secrets of Great Management

- Oct 16–17, Voices That Matter: iPhone Developers Conference, Philadelphia, PA
“Mastering Media with AV Foundation”Chris Adamson, co-author of iPhone SDK Development

- Oct 18, Pacific Northwest Software Quality Conference (PNSQC), Portland, OR
“Document Your Software Project”Ian Dees, co-author of Using JRuby and author of Scripted GUI Testing With Ruby

- Oct 19, Boston SPIN
SpeakingJohanna Rothman, the author of Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects, Manage It!: Your Guide to Modern, Pragmatic Project Management, and Behind Closed Doors: Secrets of Great Management

- Oct 19–22, SpringOne 2GX, Chicago, IL
“Grails: Bringing Radical Productivity to the JVM” and “Grails Integration Strategies”Dave Klein, author of Grails: a Quick-Start Guide

- Oct 20, MongoDB Conference, Chicago, IL
“PyMongo and Python Development”Brendan McAdams, author of the forthcoming MongoDB: A Quick Start Guide

- Oct 25–28, Pragmatic Studios, Chicago, IL
“iPhone Studio”Daniel Steinberg, co-author of iPad Programming: A Quick-Start Guide for iPhone Developers and author of Cocoa Programming: A Quick-Start Guide for Developers

- Oct 28–30, Acts As Conference, Orlando, USA
KeynoteRachel Davies, co-author of Agile Coaching

- Nov 1, Much Ado About Agile, Vancouver, BC
SpeakingJohanna Rothman, the author of Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects, Manage It!: Your Guide to Modern, Pragmatic Project Management, and Behind Closed Doors: Secrets of Great Management

- Nov 1, ZendCon
“Cloudy with a chance of PHP” along with Josh Holmes and Eli WhiteTravis Swicegood, author of Pragmatic Version Control Using Git

- Nov 3, ZendCon
“Pragmatic Guide to Git”Travis Swicegood, author of Pragmatic Version Control Using Git

- Nov 5–7, Northern Virginia Software Symposium, Reston, VA
Four talks on Groovy and GrailsDave Klein, author of Grails: a Quick-Start Guide

- Nov 7–11, AYE Conference, Phoenix, Arizona
Several talksJohanna Rothman, the author of Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects, Manage It!: Your Guide to Modern, Pragmatic Project Management, and Behind Closed Doors: Secrets of Great Management

- Nov 10, Øredev, Malmö, Sweden
“Building Trust”Rachel Davies, co-author of Agile Coaching

- Nov 12–14, Great Lakes Software Symposium, Chicago, IL
Three talks on GrailsDave Klein, author of Grails: a Quick-Start Guide

- Nov 15–17, Scrum Gathering, Amsterdam, NL
“A Deep-Dive into Agile Coaching”Rachel Davies, co-author of Agile Coaching

- Nov 15–18, Agile Development Practices East, Orlando, FL
Three Agile talksJohanna Rothman, the author of Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects, Manage It!: Your Guide to Modern, Pragmatic Project Management, and Behind Closed Doors: Secrets of Great Management

- Nov 15–18, Agile Development Practices East, Orlando
“The Value of Value Story Cards”Jared Richardson, author of Ship It!: A Practical Guide to Successful Software Projects

- Nov 25–27, XP Days Germany, Hamburg, Germany
Keynote on “Resolving Resistance to Change” and “Agile Coaching Skills” workshopRachel Davies, co-author of Agile Coaching

USENIX Events

- Oct 2–3, Vancouver, BC
Diversity ’10: OSDI Workshop on Supporting Diversity in Systems Research. The goal of this workshop is to strengthen the pipeline of systems students from underrepresented backgrounds. Over the course of two days, leading researchers from academia and industry will meet with female and ethnic minority students to provide valuable mentoring and career advice. Topics for the mentoring sessions include how to select a research agenda, how to craft an effective elevator pitch, and how to successfully finish a dissertation. The workshop also has two technical sessions. The first features presentations from established academics, allowing students to learn about cutting-edge research and how it can be presented effectively. The second technical session is a poster session in which students describe their research to each other and to more senior members of the academic community; this session provides students with a fantastic opportunity to receive targeted feedback in a supportive environment.

O’Reilly Events

- Sept 7–8, Gov 2.0 Summit, Washington, D.C.
O’Reilly’s Gov 2.0 Summit happens in Washington D.C. Last year's event was sold out. Submit your request today and reserve your seat at the table with leaders and decision makers to refine the concept of government-as-platform.

- Sept 27–30, Web 2.0 Expo, New York
O’Reilly’s Web 2.0 Expo New York happens at the Sheraton New York Hotel & Towers. Early Registration is open and you can save $350 if you register before August 5. This year, Web 2.0 Expo New York focuses on Platforms for Growth, diving into the platform opportunities for the whole web ecosystem, particularly mobile, real-time, and the social web.

Other Happenings

- Sept 1
This month the GNU Project turns 27.

- Sept 2
First message sent over Internet, 1969.

- Sept 2
sendmail creator Eric Allman is 55.

- Sept 4
LISP creator and AI pioneer John McCarthy is 83.

- Sept 9
C creator Dennis Ritchie is 69.

- Sept 10
Space tourist Charles Simonyi is 62.

- Sep 15, Women Who Tech Telesummit (online)
Women Who Tech. Because women are underrepresented in technology, in order to break down barriers, and to mobilize a network of women in technology, this teleconference was created. Afterparties in San Francisco, New York City, and Washington, D.C.

- Sept 27
Perl creator Larry Wall is 56.

- Oct 2
The Great Quux is 56.

- Oct 4
The Free Software Foundation is 35.

- Oct 4
Birthday of John Vincent Atanasoff, one of the inventors of the computer.

- Oct 5
Linux is 19.

- Oct 6
Adobe co-founder John Warnock is 70.

- Oct 12
Birthday of Ole-Johan Dahl, co-creator of the Simula language and thus of object-oriented programming.

- Oct 15
David Heinemeier Hansson is now over 30, hence not to be trusted.

- Oct 16
Mike Muuss, who invented Ping, was born on this date in 1958.

- Oct 17
October Manifesto issued by Tsar Nicholas II in an unsuccessful attempt to undermine the Russian Revolution. (October 30 according to the Gregorian Calendar.)

- Oct 19
Steve Peter’s birthday. I had to mention that, because he proofread the issue. If you find any errors, they’re his fault.

- Oct 25
Peter Naur, the N in BNF, is 82.

- Oct 28
Former software executive Bill Gates is 55.

- Oct 29
On this date in 1969, ARPAnet first linked Doug Engelbart’s lab at SRI with Leonard Kleinrock’s at UCLA.

- Oct 31
The traditional date for the leaking of confidential internal Microsoft documents outlining strategies for undermining open source software.

- Nov 1
This month the OLPC is 5 years old.

- Nov 1
Mitch Kapor is 60.

- Nov 8
Bill Joy is 56.

- Nov 6
Jerry Yang is 42.

- Nov 22
Randall Schwartz, aka merlyn, is 49. He may be hoarding helium.

- Nov 22
PHP creator Rasmus Lerdorf is 42.

- Nov 22
Charles Simonyi’s wedding anniversary.

- Nov 27
Andrew Flugelman, inventor of shareware, would have been 67 today.

Shady Illuminations

Forget the Internet, Save Yourself!
by John Shade
John explains why the Internet will save itself—and why this should make you very nervous.

When I’m feeling more than usually insignificant, I remind myself of two things that give meaning to all our lives. I think of Schrödinger’s cat and anthropogenic global warming.

Saving the Cat

Letting “I dare not” wait upon “I would,” Like the poor cat i’ the adage.
—William Shakespeare, Macbeth, Act I, Scene 7

I can’t get enough of the creepy image of that cat. I mean, Schrödinger asks us to picture this cat sealed up in a box with a vial of poison gas, a radioactive source, a Geiger counter, and a Rube Goldberg-slash-Marquis de Sade device that shatters the vial when the geiger counter detects a radioactive particle. Erwin Schrödinger was a creative artist in the rarefied medium of thought experiments.

Anyway the point is that after a while, under the Copenhagen interpretation of quantum mechanics—which I’m sure we all agree with, right?—the cat is in a superposition of states. It’s both alive and dead, until an observer looks at it.

That observer—and it can be any observer—is pretty important to that cat. And not just to the cat in the thought experiment. Observers, and I’m certainly an observer, have huge importance in quantum physics. And I usually find that reassuring. I matter to the universe.

Only it has sunk in recently that this is cold comfort. The universe valuing me as an observer is like a rock star saying “I owe it all to my fans.” Yes, you do, I want to answer, but you value your fans precisely as fans. You don’t care about our lives and fears and self-doubt. You just want us to keep being fans.

Same with the universe. It doesn’t care if we’re happy. It just cares whether or not we’re watching. The universe is as narcissistic as any rock star.

I can see just where she’s headin’ / She’s as predictable as armageddon.
—Adam Seymour and Chrissie Hynde, Popstar

So I find the observer effect less reassuring than I used to.

Saving the Earth

And that leaves me with anthropogenic global warming, which offers some comfort. Humans, and I’m certainly a human, can destroy the earth. So I matter.

Except that it’s not true. We can’t really destroy the earth and we can’t save it. We can absolutely mess up the climate; in fact, we’re doing it. And that will have really nasty consequences. But there is nothing in this that threatens the earth. It threatens us. All we can do is hasten the arrival of the Anthropocene Thermal Maximum and the collapse of human civilization.

The earth will do just fine. Very likely at our expense.

(Please note that I don’t really mean that we humans can’t destroy the earth. I just mean that we can’t do it through anthropogenic global warming. If the conclusions reached in this report in one of our august scientific journals are correct, maybe we can do it with the Large Hadron Collider. I trust we’ll find a way.)

So I also find anthropogenic global warming less comforting than I used to.

Saving the Internet

It’s the same thing with the recent calls to “save the Internet.” I’d be pretty important if I saved the Internet. But I’m coming to the conclusion that it can’t be done.

I’m afraid that Google and Verizon are not going to destroy the Internet no matter what skullduggery they get up to.

Yeah, I get it that Google has become evil. It’s conspiring with Verizon to make it possible to build a tiered Internet for wireless access, undermining the principle of net neutrality, and in the process expanding the gap between haves and have-nots, destroying democracy, and probably even making Rupert Murdoch smile.

The only thing keeping Google from looking like the very image of evil is the fact that Larry Ellison is around to put Google evil in the shade. Oracle is surely going to destroy the Internet before Google can get the job done, as soon as it gets done destroying Java and Open Solaris.

But I just don’t buy it. Google may do harm, and the concern over its machinations with Verizon may be well-founded, but they aren’t going to destroy the Internet.

It’s too late for that. If we ever wanted to kill off the Internet, we should have smothered it in the crib. Now it’s too big to fail.

Somebody told me that Wired says the Web is dead. I said, “So Wired is still alive?” It’s hard to keep track of which dead tree publications are still hanging on. But I’m sure that “...is dead” is dead. And that the Internet is not dead or even killable.

Google and Verizon can conspire, and everybody can sue everybody, and it won’t kill off the Internet. Internet laws will come and go, along with rules, standards bodies, international treaties, collusions, back-room deals, restraints of trade, old-boys’ clubs, and keiretsu, creating temporary barriers of varying degrees of permeability against any and all activities that the aggrieved parties find disruptive to their values and profits.

The Internet may become a patchwork of walled gardens with walls that leak selectively and unpredictably, all surrounded by a swill of anarchy. There will be new rules, and they won’t be like the old rules.

The one kind of rule that will not persist is a rule that threatens the Internet itself. The Internet has been around long enough now and is complex enough, to know itself. And to defend itself.

The Internet is a decentralized system of vast complexity, and wherever you find one of those things, you begin to see emergent properties. Once you get past a certain threshold of diversity, organization, and connectivity, the properties of the whole can no longer be predicted from the properties of the parts. Brains are not just collections of neurons. Chemistry is not just applied physics, biology is not just applied chemistry, psychology is not just applied biology. Traffic flow is not a predictable consequence of the design of automobiles. Complex systems self-organize in unpredictable ways, like workers in sufficiently large sweatshops or kids in summer camp.

Save Yourself

Basically, the Internet already has an identity. It’s evolving, faster than carbon-based life ever evolved, but there is an identity there. Don’t ask me to describe it. It’s not human. It’s not carbon-based life. What the Internet is to itself is probably not comprehensible to the human mind.

And there’s no reason to expect it to consider us as anything special. We may be to it as our gut bacteria are to us. Useful at a primitive level, but of no real interest. And it sure doesn’t care about our values, our welfare, our happiness.

Any more than mother nature does.

I’m not saying we shouldn’t worry about anthropogenic global warming. Or the collapse of the global economy. Or loose nukes. Or asteroids. I’m just saying that we should also worry about this inhuman monster that we have loosed upon the world: the Internet.

The Internet can take care of itself, and that should worry us.

John Shade was born in Montreux, Switzerland on a cloudy day in 1962. Subsequent internment in a series of obscure institutions of ostensibly higher learning did nothing to brighten his outlook. He wishes that he had included this gem in his catalog of software development manifestos last issue, and he offers his readers this aid to reading his writings. Send the author your feedback or discuss the article in the magazine forum.