PragPub 2010-11: Issue #17

Table of Contents

Features

- Let’s Talk about Your Book
by Michael Swaine
Susannah Pfalzer, managing editor of The Pragmatic Bookshelf, talks about writing, from the hero’s journey to PragProWriMo.

- Writing and Performing
by Chris McMahon
Agile software development has all the hallmarks of an artistic performance like those of music, theater, or dance. It requires practice; it requires rehearsal; it requires a team to be constantly negotiating their own personal and professional relationships among themselves.

- Getting Clojure
by Gregg Williams
It’s incredibly easy to call Java code from Clojure, but who would have thought that modifying an existing Java library would be such uncharted territory? Gregg shares what he has learned.

- Shu Ha Ri
by Jeff Langr, Tim Ottinger
Our well-meaning agile coach’s maturity model was based, either deliberately or subconsciously, on Shuhari, a Japanese martial arts concept involving three stages of mastery: “first learn, then detach, and finally transcend.”

- When Did That Happen?
by Dan Wohlbruck
From 1925 to 1955 was the Golden Era of Radio. Almost 90% of the population of the United States owned and regularly listened to the radio. And broadcasting began in this month, ninety years ago.

Departments

- Up Front
by Michael Swaine
This month is PragProWriMo, our month to kick-start your writing.

- Choice Bits
A report on our attempt to crowdsource a novel on Twitter. Also: snakes on a plane, how to pack dirty socks, and other travel tweets.

- Guru Meditation
by Andy Hunt
Avoiding the Infinite Abyss: Constraints foster ingenuity

- Way of the Agile Warrior
by Jonathan Rasmusson
Once regularly producing shippable code becomes a habit to you and your team, it’ll just feel good. You are delivering something of value every week and your customer is seeing steady progress in a live system.

- Swaine’s World
by Michael Swaine
If you’re starting that novel or planning a tech book, here’s some advice on getting to “Hello Page!”

- Calendar
RubyConf is coming, and many of our authors will be speaking.

- Shady Illuminations
by John Shade
John vows to expect nothing, thuse ensuring that he will not be disappointed.

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

PragProWriMo
by Michael Swaine
If you’ve always wanted to write a book, or you’re already writing a book or some shorter-length work, but you’ve hit an iceberg and are now treading water, this issue is for you. You’ll find several articles here on writing—and they’re just the tip of the icebreaker. We’re supporting your writing this month with a dedicated writing forum, a Twitter feed, and a challenge. You can read all about our PragProWriMo program below.

What We’ve Got for You

If you’re old enough to remember Byte magazine from its heyday, or more recently, Apple Directions magazine from Apple’s developer support program, you know Gregg Williams. He introduced Byte readers to the IBM PC and the Apple Macintosh and the Commodore Amiga, and his writing in Apple Directions was the true technical voice of that publication. Lately he’s gotten into Clojure, and this month he shares with us his experience with that JVM-based Lisp dialect.

Our columnists cover a wide range this month. Andy Hunt writes about estimating and how constraints foster ingenuity. Jonathan Rasmusson writes about production readiness. I ramble on about the ebb and flow of writing. And John Shade follows the advice of Jonathan Swift.

In an information-packed interview, Pragmatic Bookshelf managing editor Susannah Pfalzer talks about what it’s like to write a book for the Bookshelf. In May 2009, Chris McMahon organized the first Writing About Testing conference. That experience and his background as a professional musician have shaped his views on his software development work, and he writes in this issue about software development as performance. Agile in a Flash authors Jeff Langr and Tim Ottinger discuss the Japanese martial arts concept of Shuhari and how it applies to agile development. And Dan Wohlbruck is back with another tech history article, this time looking at the history of radio.

And of course we do the wheat/chaff triage thing on the tweets we follow in Choice Bits, and we report on all the good stuff coming up in our Calendar. Ah, but I promised to tell you more about PragProWriMo.

PragProWriMo

Last year we tried an experiment in writing. It worked well enough that we thought we’d do it again.

We call it PragProWriMo, which means Pragmatic Programmers Writing Month. We were inspired by (we ripped off) NaNoWriMo, National Novel Writing Month, which you can read about here.

PragProWriMo is all about helping you write that book, whether “that book” is a technical book you’d really like to write but for some reason haven’t been able to get started on, or the novel you’ve always threatened to write but never seem to be able to get your teeth into. Whatever the book, we have one question for you:

What are you waiting for?

We invite you to decide that you’re really going to write that book. No more putting it off. The time is now. Oh, and you’re going to write it in one month.

We’re not kidding. Last November I took the NaNoWriMo challenge and succeeded. That program works like this: You decide that you’re going to write a 50,000-word novel in the month of November. You don’t revise, you don’t worry about quality, you just write, every day. About 1700 words a day. The organizers and other participants provide a lot of encouragement and some help, but you do all the writing. And on November 30, if you’ve kept up the pace, by golly you’ve written a novel. Over 100,000 people participate in NaNoWriMo every year, and about 15% of them finish their novels.

Our PragProWriMo challenge is a little less daunting.

We’ll provide supporting materials and encouragement and all you have to do is to write 60 pages toward that book during the month of November. If you’re already writing a book for us and you’re averaging two pages a day, then ta-da! you’re already a winner.

To help you along, we’re setting up a forum and a Twitter account. Follow us on Twitter at @pragprowrimo to stay up to date. Join the forum at forums.pragprog.com/forums/190 for more detailed writing advice, answers to your writing questions, and progress reports from participants. And when you finish your 60 pages, you might even get some special recognition from us.

Of course we’d love for you to submit a proposal for that book to us. But it’s your work. You can publish it for free, you can do print on demand, you can hide it from the world and keep it to yourself, or you can take it to another publisher. A great new Prag book may result from this project, or it may not. What we’re really trying to do is to help you write the book you’ve always wanted to write.

Even if you’re not ready to take our PragProWriMo challenge and write a book in November, you can still take advantage of the writing advice and support that we’re queueing up for November. Follow us at @pragprowrimo and visit the forum at forums.pragprog.com/forums/190. You may learn something useful, and the mere act of joining in will focus your attention on your writing in a new way.

Solution to Last Issue’s Quiz

Last month we celebrated 101010 day, the tenth of October, 2010. 101010 is 42 in binary. 42 was the solution to our 0th quiz, as revealed in our first issue. It is also the answer to last month’s quiz, and the answer to so much more.

Why 42 is the answer to last issue’s quiz is simple. Each number in the list is an Easter egg number with special meaning for a director or writer. And 42 is perhaps the most famous of these, or at least the most famous such number that fits numerically between 37 and 47. The list, explicated:

- 19 crops up regularly in Stephen King novels.

- 27 often appears in videos and songs by “Weird Al” Yankovic.

- 37 is frequently used in Kevin Smith movies.

- 42 is the ultimate answer to life, the universe, and everything, according to The Hitchhiker’s Guide to the Galaxy.

- 47 appears in many Star Trek shows.

- 113 appears in the form A113 or A-113 or A1-13 in movies from CalArts grads, including John Lasseter and Brad Bird. It refers to a classroom at CalArts.

- 114 appears in Stanley Kubrick films in the form CRM114.

- 1138 is the number that George Lucas likes to hide in his movies, although sometimes it’s not so hidden.

Coming Attractions

Next issue we’ve got some fine articles lined up, including Adam Goucher’s piece on testing for the cloud. Watch for it Wednesday, December 1.

Choice Bits

Tweets as Literature

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^

4

The RSpec Book

3^

7

Pragmatic Guide to Git

4v

3

The Agile Samurai

5^

10

Programming Ruby 1.9

6^

NEW

iPad Programming

7v

6

Hello, Android

8

8

Seven Languages in Seven Weeks

9v

5

HTML5 and CSS3

10v

9

Continuous Testing with Ruby

11v

2

Pragmatic Guide to JavaScript

Twit Lit

Every month the Choice Bits staff pans the twitterstream for nuggets of tweet gold. It’s a tedious process, not unlike scrutinizing chads in paper ballots in a Palm Beach polling place. (Mandatory timely November election reference checked off.) But we do it gladly, for you. You’re welcome.

This month PragPub is focusing on writing, so we thought we’d start with a look at how people are using Twitter as a writing medium. This person, for example, solicits nouns, then uses the ones that inspire him to write tweet-length stories. How well do you think he succeeds? In what ways are/aren’t these stories? Respond at your leisure.

He’s not alone. Here are a few of the current exercises in tweet-length fiction:

- DeadEndFiction, short horror fiction confined (or coffined) to 140 characters with a beginning, middle and dead end.

- VeryShortStory, Twitter-sized fiction for your entertainment.

- TwitterFiction, great works of fiction in 140 characters or less.

- Thaumatrope, a Twitter fiction magazine for Science Fiction, Fantasy, and Horror fiction under 140 characters.

- Twitter Fiction and Short Stories, by Chris Brauer.

There are several approaches to twit lit, from haiku to attempts to write novels collaboratively, one tweet at a time. Naturally, your trend junkie editor had to give it a try. I didn’t line up collaborators ahead of time, I just started tweeting.

The Short, Happy Life of a Twitter Novel

First, I tweeted this:

It was a dark and stormy night, and I shuddered with eldritch dread to think that somewhere out there novels were being written on Twitter. — @pragpub

Within minutes, I was answered:

A pop! in the fireplace and a shower of sparks snapped my eyes open as a face appeared in the flames. — @KentBeck

Then suddenly, another voice chimed in:

Then suddenly, out of nowhere, a wail appeared and a temporary break from writing was imposed — @davybrion

Emboldened by the responses, I tossed some more chum into the twitterstream:

The wail became a fiendish chortle. “There is no break from writing,” the face laughed derisively, “There will always be another deadline.” — @pragpub

This, too, was answered snappily:

"No break?" I snapped back, "break this," and I threw my drink on the fire, not remembering it was a single-malt scotch. — @KentBeck

The next chapter in the story, however, seemed more like a comment:

true, but better than never having a deadline ever again. — @marczak

In fact, scrutinizing the twitter handle, I began to suspect a hidden motive, a second thread of narrative. Sure enough, it was Ed Marczak, executive editor of Mac Tech magazine, reminding me that I owed him an article. The next tweet, though, was definitely a comment. In fact, it was a review:

Keep on going, this is exiting! :-D And a great idea!! — @danielbrolund

Just then, another writer picked up the thread of the narrative:

The fire began wrapping the manuscript into the flames. "I have to start over this iteration" I complained. — @mbigatti

…and executed a tricky double-tweet, following one tweet directly with another and managing not to get interrupted by an intervening tweet. This author was moving the story in a new direction:

"I hate the pomodoros where I have to redo what I have already done." But there was no choice, my work was already ashes. — @mbigatti

No further tweets were tweeted on this twisted narrative thread. So there our story ends in ashes, not with a bang but with a tweet. I don’t know how I didn’t see that coming.

Found Art

Hardware guys writing software are occasionally like drunk fighter pilots without helmets on racing bikes. — @mfeathers

"Stack" is a better name than "Pushdown list" is better than "fifo" is better than revomorzoid. — @marick

Well, NOW I see why it won the Nobel Prize! "Latest graphene research could lead to improvements in bluetooth headsets": http://j.mp/anCwil — @tcarmody

I can't be sure .. but it feels like Windows 7 is only working when I look at it. — @jrasmusson

watch this tequila training video http://tinyurl.com/3282jqt, nice work, hope you weren't in SLC — @TotherAlistair

Food can be a challenge here. Flight attendent offered me Snake or Noodles. It could happen, though she meant snack. — @ jwgrenning

Packing dirty socks last in my bag is how I show my love to those that open up my checked luggage w/o my permission. — @duncan

I follow certain people to learn from them. Unfortunately all I learn is that they go to lots of conferences and they are mayors of things. — @ bphogan

It's often all "I want a pony!" collective delusion till either Storytests and/or working code prove otherwise. — @wwake

In an uncaring world, giving a damn is a huge competitive advantage — @deadprogram

This month we were following Massimiliano Bigatti, Davy Brion, Tim Carmody, Alistair Cockburn, DeadEndFiction, Kent Beck, Duncan Davidson, Ron Evans, Michael Feathers, James Grenning, Brian Hogan, Ed Marczak, Brian Marick, Jonathan Rasmusson, Thaumatrope, TwitterFiction, Twitter Fiction and Short Stories, VeryShortStory, and Bill Wake. Also you, but you didn’t say anything quotable. Please funny up your tweets, for the sake of all of us. You can follow us on twitter and make fun of our tweets. Also you can participate in the PragProWriMo program here.

Guru Meditation

Avoiding the Infinite Abyss
by Andy Hunt
Without at least some constraints, you’re just staring straight into infinity. And that’s a little rough on a Monday morning.

Estimating is never easy. In agile projects we try and get a better feel for estimating over the course of a project as we get more familiar with the pace and capabilities of ourselves and this particular team and technology environment. On most projects we want individual team members to come up with estimates for their own tasks, the ones they’ve selected from the current project backlog. That puts the onus of estimating on the person who actually has to do the work, a nice touch of straightforward reality in an otherwise messed-up world.

But for programmers new to this style of working, or new to the team or to the technology, trying to decide on how long a task might take is kinda like trying to pick a winning lottery number: billions of choices, only one right answer.

I was visiting a newly agile team last week, and this was an area of agility they were struggling with. I asked what units they were estimating in (there are so many colorful units in use these days). Bottom line was, they were estimating in hours. That meant that for each estimate, you had around two hundred possible answers using whole hours within an iteration. Turned out you could also specify fractional hours, which meant effectively an infinite number of allowed answers.

No wonder it was hard to decide on an estimate.

Less Is More

“Too many” choices is a mental turn-off; it’s a demotivator. When faced with too many choices in a retail store, consumers choose to not buy anything at all.[1] Too few choices is no bargain either. I can easily imagine a large, formerly waterfall-based bureaucracy mandating that “all agile estimates shall be equal to Three. Four shalt thou not count, nor two, excepting that thou then proceed to Three. Five is right out.” [2] Sigh.

You need a minimum of three alternatives to make a real choice, but you don’t want too many more than that. In the Jam study above, consumers clammed up with 24 choices; that many choices is simply overwhelming.

So for estimating, try to constrain yourself to something like 3 or 4 choices, perhaps:

- One hour

- One day

- Three days

- One week

Now you’re not facing an overwhelmingly infinite choice amongst all the rational numbers, but just a choice from a set of three or four. You’re not trying to codify exactly how long it might take, but you’re taking a pretty good stab at sorting it into a reasonable-sized bucket.

If the task you’re facing is longer than your maximum (one week, in this example), then it’s too big. Break the task down into smaller tasks. Yes, you can refactor the task list, and smaller tasks are easier to estimate correctly.

Constraints Foster Ingenuity

The Beatles recorded some of their most complex works on a simple four-track recorder (yeah, there’s an app for that now.) Imagine if your project had no deadline at all. Think it would ever get done? What about your own hobbies and personal projects that don’t have a deadline? How are those coming along? Constraints—fewer choices—are a good thing, and foster ingenuity.

That’s why timeboxing, in all its various forms, is so popular. Whether it’s a sprint, an iteration, or a Pomodoro, putting a strict limit on time forces you to make the hard decisions. You don’t have forever; you don’t even have a month. You have a short period of time—now—to do what needs to be done. There’s no luxury in waiting, hoping for something better to show up, or for a miracle to come riding over the horizon. It’s just now. So given that, how are you going to go about it?

This month of November, we’re encouraging everyone to write—every day, for one month. You wanted to write that book, that program, or that rock opera? Now’s your chance. But just now, for one month only. Set yourself this deadline: what can you accomplish each day, each week, for a month?

Without at least some constraints, you’re just staring straight into infinity. And that’s a little rough on a Monday morning.

Something to think about.

[1] “When Choice is Demotivating: Can One Desire Too Much of a Good Thing?” Journal of Personality and Social Psychology, 2000, Vol. 79, No. 6, 995-1006

[2] Monty Python and the Holy Grail. I had no idea those guys read the same project documentation I’ve seen.

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.

Way of the Agile Warrior

Production Readiness
by Jonathan Rasmusson
If you practice going live every couple of weeks, when the big day finally comes, it turns out to be a non-event.

Something that doesn’t get talked about enough in agile development is production readiness—the practice of continuously having your code in a state where it could be deployed at a moment’s notice.

Everybody gets the importance of co-location. Most people understand the speed and efficiency that come from user stories. But rarely do I hear people talk about the importance (and challenge) of continuous production readiness.

In this article I want to get into what agile production readiness is, why it’s so important for you and your project, and what you can do to get there.

What is production readiness?

Production readiness is the practice of ensuring that your software is continuously in a state where it could be shipped at a moment’s notice.

It’s an attitude and a mindset in which the team treats the first iteration of their software as something that could potentially be shipped, and each iteration thereafter, they are simply making updates to what they view as a live production system.

Yes. When we are not in production, there are a lot of things we don’t have to worry about.

- We don’t have to worry about testing (can do that later).

- We don’t have to fix bugs (can always do that before we go live).

- We don’t have to demo our software (it’s still in development, after all).

- And we don’t have to integrate everything together (it’s easier just to hook it all up in the end).

- </tongue in cheek>

You can see where I am going with this.

These are exactly the kind of things that, as agile practitioners, we want to be doing early and often in our software. We can reduce a lot of risk by acting as if we had to release it every week. That doesn’t mean we do (there are probably a lot of really important features like security and validation that won’t be done in iteration one). But our attitude is: we could ship whatever we have built (in its limited form) if we really had to.

What Does This Buy You?

There are a lot of benefits that come from treating your software with this kind of respect from day one.

It’s cheaper and faster.

When you are regularly producing working software you spend less time:

- fixing bugs

- deploying emergency patches

- re-writing broken features

- explaining why your project is late and nothing works

And more time:

- improving your customer experience

- adding (or removing) new features

- and wowing your customer in unexpected ways

These benefits don’t come free. You have to write tests, get feedback, and tackle tough problems early. But once you make these investments, you reap great dividends later on in terms of time and money.

You always know where you are.

No need for shenanigans or tomfoolery with the schedule and plan. Features are either done or they are not. It removes any doubt with regard to where you are with the project, and how much you have left to do.

It reinforces the good.

To regularly produce shippable code each week there are certain things you’ve got to be doing:

- You’ve got to break big problems down into smaller, more manageable ones.

- You’ve got to test from the start.

- You’ve got to improve and evolve the design as you go.

- You’ve got to get feedback from your customer.

- You’ve got to stop and fix things when they come up (can’t just brush them under the carpet).

- And you’ve got to get off your butt and talk to people.

All good things for any healthy, exciting project.

Going live becomes way less stressful.

If you practice going live every couple of weeks, when the big day finally comes, it turns out to be a non-event:

- You’ve automated just about everything you can.

- You’ve hit and dealt with all the integration sore points.

- You know who to talk to and what kind of coffee they like.

- You’ve basically worked out all the kinks in the deployment process.

And it builds trust.

Not just between you and your customer. But between you and your team.

Once regularly producing shippable code becomes a habit to your team, it’ll just feel good. You are delivering something of value every week and your customer is seeing steady progress in a live system.

Note: This is not an excuse to stop thinking.

And just to be clear, you can’t be dogmatic about this stuff.

You’ve got to look at your situation and context and decide what’s right for you, your team, and your project at that moment in time.

Like Pete Docter, the director of Monsters, Inc. and Up, says: “Pixar films don’t get finished. They just get released.”

If I had to sum it up in one sentence: production readiness is doing enough work on a feature so you could release it into production if you had to.

If I am making this sound all apple pie and puppy dog kisses, let me be the first to tell you—it isn’t. You’ve got a lot working against you.

First off, regularly producing shippable code changes how people and teams work. And not everyone is into change.

Secondly, you’ve got an industrial mindset (still alive and well in most companies) that believes that writing software is akin to ditch digging.

Then you’ve got unrealistic expectations, impossible schedules, and perverse incentives that all too regularly sacrifice the long term for the short.

But the good news is that it can be done, and lots of people (including your competitors) are already doing it. It just comes down to choice.

What You Need to Get There

Teams that regularly produce production-ready software usually have some combination of the following three things going for them.

Discipline

In the heat of the battle, with all the dysfunction that comes with the work place, you are going to be tempted like never before to take the easy way out:

- You are going to be tempted to not write that unit test.

- You are going to be tempted to guess what the requirement is instead of talking to your customer.

- You are going to be tempted to check in on top of that broken build (because you know your stuff works).

This is what separates you from everybody else. This is where the courage and discipline to do the right thing (often at your own personal expense) comes in.

Don’t expect much in the way of appreciation initially. You won’t get it.

What you will get is the begrudging respect of your peers (for having the courage to say “enough is enough”) and the self-respect that comes from knowing you produce quality work.

A Culture of Excellence

“Some people aren’t used to an environment where excellence is expected.” –Steve Jobs

Most people aren’t used to doing excellent work <insert favorite excuse here>. The ironic thing is that most people want to do great work. It’s like they are waiting for someone to give them permission.

If this is you—permission granted.

You can create a culture of excellence by setting the bar high in the beginning and keeping it there for the duration of the project:

- Don’t accept untested, poorly implemented features.

- Don’t accept people abusing the build.

- Don’t accept bugs—any.

- Pair.

Setting the bar high in the beginning is way easier than trying to raise it later. Set it high at the start, lead by example, and keep it there for the duration of your project. Make excellence an assumption and it will soon become a habit.

People Who Really Care

I know you care about software. You are here, still with me at the end of this article, when you could be doing any of a thousand other fun things. It’s not you I am worried about. It’s everyone else.

You are going to need to find and track down more people like you—people who care about software, delivery, and excellence.

Finding, and attracting, people with this mindset for quality and craftsmanship is important, because when people care about what they’re doing the little things take care of themselves:

- You don’t need a lot of rules.

- You don’t need to write everything down.

- You don’t need to be afraid.

Because the good people don’t need to be told what to do. They take initiative and do the right thing because they can’t help it—that’s just the way they are built.

“Simple, clear purpose and principles give rise to complex and intelligent behavior. Complex rules and regulations give rise to simple and stupid behavior.” –Dee Hock, founder of Visa

This is the Start

There’s a lot more we could say about production readiness. We haven’t even gotten into the software delivery practices that help us get there. But if you are still here at the end, chances are that’s not going to stop you from finding out what they are.

If your team isn’t thinking like the next iteration’s worth of work needs to be ready for battle, start fostering that culture now. It will pay big dividends later on in terms of time and cash.

And if you’re already there—good for you! Now be vigilant. Don’t get cocky. And show others how to do it. It’s a fun way to work and the more people we can get working this way the more fun it’s going to be for you and me.

Jonathan Rasmusson is the author of The Agile Samurai. As an experienced entrepreneur and former agile coach for ThoughtWorks, Jonathan has consulted internationally, helping others find better ways to work and play together. When not coaching his sons’ hockey teams or cycling to work in the throes of a Canadian winter, Jonathan can be found sharing his experiences with agile delivery methods at his blog, The Agile Warrior. For more information on the Agile Inception Deck check out The Agile Samurai. Send the author your feedback or discuss the article in the magazine forum.

Swaine’s World

Hello Page!
by Michael Swaine
If you’re starting that novel or planning a tech book, here’s some advice on getting to “Hello Page!”

“I’ve had an idea for a book for a long time but have always been hesitant to start it because I don’t know the best tools and format to use,” says a writer in the PragProWriMo forum. In the Pragmatic Authors Google group, another author writes, “As I’m just getting started, I find it a lot easier to maintain my writing flow by just writing using TextEdit and not thinking at all about markup. However—”

Stop right there. You had it right. If not thinking about markup helps you maintain the flow of your writing, then don’t think about markup. Not yet. And don’t let thinking about what tools and format to use get in the way of getting the words down.

Here at the start, you should just get words on paper (virtual or actual) as quickly as possible. Don’t worry about formatting or spelling or punctuation. Those first words on paper are your “Hello Page!” achievement, the first proof that you have something to say and that you can get it out of your head and onto the page. That’s a bigger deal than you realize. You’ll be proving that to yourself again and again as you write. Here at the start, it doesn’t matter if your “Hello Page!” is a mess.

But this is just one case of a broader principle. Not only at the start, but whenever the words are flowing, let nothing get in their way. When the words are coming easily and you feel inspired, that is writing. Don’t let editing slip in. Writing is linear, editing is fractal. In writing, you keep moving forward, in editing you keep spiralling deeper. Do as Susannah Pfalzer says: Write first. Edit later.

It’s not quite that simple, of course. I said if not thinking about markup helps you maintain the flow of your writing, then you shouldn’t think about markup. But markup is a tool, like a typewriter or a word processor. It’s perfectly possible to be so comfortable with markup that you enter the codes automatically and rapidly, and they don’t slow you down. The only rule here is, whenever the words are flowing, let nothing get in their way.

Letting nothing get in the way doesn’t mean you have to write in a padded room. Unless you do. Virginia Woolf argued that one needs a room of one’s own in A Room of One’s Own, but Jack Kerouac wrote On the Road on the road, at least the raw material, in a series of notebooks during a series of road trips. World War II Journalist Ernie Pyle lugged his battered Corona typewriter from Anzio to Okinawa, making notes for “With the Air Force” while actually with the Air Force. I’d love to be able to claim that Beverly D’Onofrio wrote Riding in Cars with Boys riding in cars with boys, but at least I’m pretty sure that’s where she did her research. On the other hand, Thomas Hardy wrote Far from the Madding Crowd far from the madding crowd, in the sleepy 70-year-old Dorset cottage where he was born. You have to find your place.

What you’re looking for is that place where the words flow out of your head as fast as you can get them down, and nobody else can tell you how to get there. “There” either in the sense of a physical place, or in the sense of emotional presence. Did Truman Capote write In Cold Blood in cold blood, or with drops of sweat falling from his brow to smear the words as he typed them? It doesn’t matter; what matters is where you have to be, physically and mentally and emotionally, to maximize the chance for the words to start flowing.

Wherever that place is, that is where your voice asserts itself. That is where you achieve flow. And flow, what’s that, exactly? How do you know when you’ve got it? Well, it’s more about process than result, more a matter of being in it than of achieving it, but it has a lot to do with sound. And with one thought leading inevitably to the next. It’s letting the words come out as they please, which is why this is where your own voice comes through, and it’s why what you write has a naturalness to its cadences. It’s—ah, but you’ll know it when you’re in it.

Maximizing your time in that place is pretty much what our PragProWriMo project is all about. It kicked off at the start of the month, but there’s no reason you can’t jump in—well, now. The forum is a good place to start.

Nothing in this is intended to suggest that you shouldn’t plan and outline up front. You should, but that’s another matter entirely. Nor that it isn’t necessary to edit later. It is. Sometimes a piece of published writing—say, Chronicles, Bob Dylan’s autobiography—reads as though it was written in one inspired burst of flow. It probably wasn’t, but that’s not what I’m talking about anyway. All I’m saying is, when you get into that writing flow, you should go with it.

Oh, there’s another reason you shouldn’t edit your work during this early brainstorming phase. It’s not just that you’re writing so well, it’s also that you’d be editing so poorly. You don’t know enough about the work yet to edit it. You’d only mess it up.

But maybe you should be writing. If so, don’t let me get in your way.

Michael Swaine is the editor of PragPub and the co-author of Fire in the Valley. He is currently writing a mystery novel. Send the author your feedback or discuss the article in the magazine forum.

Let’s Talk about Your Book

An Interview with Susannah Pfalzer, Managing Editor of The Pragmatic Bookshelf
by Michael Swaine
What’s the secret to writing a good book for the Pragmatic Bookshelf? How do you get started? How do you keep writing when it gets tough? Susannah tells all.

Susannah Pfalzer is the managing editor of the Pragmatic Bookshelf. In this writing-focused month, it seemed like the thing to do to chat with Susannah about writing a book for the Bookshelf, and about writing in general.

ms: Susannah, why would anyone want to put themselves through the hard work of writing a book?

sp: Every author has a different story to tell about what motivates them to write. Some authors fall in love with a particular tool and want to bring it to wider attention. Others find a need that hasn’t been met, that their book can fill. Still others have a brand-new idea they must share. Each author’s story is as individual as their books.

ms: It’s still hard work, though. Any advice on how to keep going when it turns into hard slogging?

sp: The one thing that will keep you going during the highs and lows of writing a book is your passion for your topic. If you write about something you really believe in, something you’re excited about and want to share with the world, then your enthusiasm will keep you moving ahead—and your readers will feel it, too.

ms: Pragmatic Bookshelf books have a distinctive style. What constitutes good writing for us?

sp: Our books tell a story. We call it the “hero’s journey,” in which the hero—the book’s reader—starts out knowing little. Slowly, as the book progresses, the reader gains competence and confidence, becomes comfortable and experienced. The reader reaches the end of the book well equipped to go off on their own. To get the reader to that level of competence, we focus on keeping books hands-on and tutorial. We see the reader as an integral part of the text—they’re working along with the author to code and learn and create.

Beyond that, we stay fluff-free. We publish short, targeted, meaningful books that get right to the essence of the technology or concept. Our books are conversational, friendly: like a friend or mentor talking to you over lunch.

Above all, we should feel the author’s enthusiasm. Readers are investing their time in reading several hundred pages—the book should keep them involved, engaged, and excited about the book’s topic.

ms: OK, say I’ve seen a need that isn’t being met, and I want to write a book that meets that need. How do I get started?

sp: For starters, don’t overthink it. Don’t sit down expecting to write perfect prose on the first try—or even the tenth. You can start in a couple different ways. You can outline what your first few chapters might cover, and then start writing based on your outline. Or you can just start writing, feeling your way into the material, not being afraid to throw away the first few tries and start over. Don’t get attached to the particular words, sentences, paragraphs you’re writing. Don’t spend so much time crafting one paragraph to perfection that you discover hours have passed and that one paragraph is all you have to show for that day’s work. What’s important is simply getting it down.

That’s why National Novel Writing Month (NaNoWriMo) and our own PragProWriMo program stay focused on word count and page count—if you spend years crafting your paragraphs into shapely things of beauty, you might have one fine chapter to show for your trouble, but you won’t have a book.

Write first. Edit later.

ms: And how long does it take? Do I have to take time off from my regular job, or can I write this book in my spare time?

sp: You don’t need to quit your job and devote yourself to an ascetic life as a writer. In fact, the opposite is true. A few weeks ago, I was fortunate enough to meet physician and bestselling author Abraham Verghese. He was asked about his advice for aspiring writers. His answer: keep your day job. You’ll be able to write more freely without worrying about where the next paycheck will come from.

None of our authors write full time. They have jobs and family responsibilities, and they fit the writing in where they can. The key success factor here is carving out that time to write.

ms: How do I do that?

sp: Think of it like an exercise program—creating a habit of writing, just as you’d create a habit of working out at a certain time.

Start by setting aside a specific time to write, either every day, or a few times a week. Once you’ve got that schedule in place, then be consistent about sitting down and writing at that time, even if you don’t want to, even if you have other things you’d rather be doing.

The thing is, the longer it takes to write a book, the harder it is to write. You lose momentum, work and life issues come up that take you away from the book for longer and longer stretches, and the finish line gets further out of reach. Writing consistently and regularly keeps you on track and gets you finished sooner.

ms: When developing software, programmers have a lot of options for getting feedback. They can run tests that tell if their code is correct, they might pair with another developer or check their code into a repository where others view it. But writing a book is an isolated and ambiguous exercise. So with this book that I’m writing, how do I know that I haven’t gone completely off the track? What kind of support can I find at the Bookshelf?

sp: There’s certainly that raw work of sitting and writing and coding. But then, as chapters are submitted, the book takes shape as part of a larger process of feedback: from the book’s development editor, me, the publishers, and numerous technical reviewers. Many of our books become beta books—they’re sold as ebooks while the writing is still in process, and readers are able to interact with the author in a book forum and to submit errata.

With so much community involvement, the book becomes tuned to readers’ needs. It’s more correct, because it’s been technically reviewed and read closely by beta book buyers. And it’s been crafted, in a very deep and involved way, in tandem with a development editor, so that the writing and structure reflect the book it’s meant to be. Over many iterations, the book becomes shaped into a more perfect version of itself.

ms: You mentioned PragProWriMo. Could you explain what that’s all about?

sp: We started PragProWriMo last year as a counterpart to National Novel Writing Month (NaNoWriMo). The idea is to spend the month of November writing a book, just as thousands of other writers are doing that month. We’re asking writers to set a goal of writing 60 pages, to write every day, and to post progress to our forum.

This year, we’re involving our current authors, too. This month will be an excellent chance for our current authors to get ahead with their books, and for new authors to start writing. We’re building in support with daily Twitter updates via @pragprowrimo and our PragProWriMo forum. On the forum, we’ll have writing tips and advice, support, and a place to discuss progress and post your weekly word count. With all the support you’ll have during this month, there’s no better time to start writing.

ms: How did last year’s PragProWriMo work out?

sp: We’ve signed two authors who started their books during PragProWriMo last year. At the end of November, you’re welcome to submit a proposal for the book you’re writing to us, as well. Or you can keep it to yourself, self-publish it, submit it elsewhere—what’s important during PragProWriMo is simply the act of writing.

ms: OK, let’s talk about the payoff. Does anyone actually make money writing books today? What’s the experience of our authors?

sp: For any book—technical book, novel, how-to book—sure, there’s always the chance of hitting it big. Dave Thomas has posted some statistics on what you might expect to earn writing books for us.

But that’s not why you should write a book. If you go into it only to make money, you’re writing it for the wrong reasons. Write your book because you have something that you must say, something that needs to be heard, and something you need the space of several hundred pages to say.

That said, you want to be rewarded too. And that’s a job in itself. In fact, our authors’ real work often begins when the book is done, because that’s when they get out there and work on promoting their book. Our authors write articles, speak at conferences, blog, and do everything they can to build a name for themselves in the community. A few other success factors: writing on a current, trending topic. Being the first book in a particular subject area. But above all, becoming known and respected in your community.

ms: I guess I’ve been harping on how much work it is to write a book, and I’d hate for that to be the main takeaway for anyone reading this. Because writing a book, a book on a subject you really care about, is also a lot of fun. Isn’t it?

sp: It’s fun. It’s thrilling. It’s exhausting. It’s time-consuming and often life-altering. It’s fun in the way running a long race can be fun, or doing something new, different, and a little scary that you’ve never tried before. It’s an experience you’ll never forget.

ms: It is. Well, thank you, Susannah. I’ll catch you in the PragProWriMo forum.

sp: Great. I hope a lot of people reading this check in there, too.

Susannah Davidson Pfalzer is the managing editor at Pragmatic Bookshelf. Send the author your feedback or discuss the article in the magazine forum.

Writing and Performing

Thoughts on Software Development as Performance
by Chris McMahon
When the features are good, we can watch our audience in real time use our software for real work. And if the feature is no good, we can find that out immediately and tune our approach for the next performance.

We can write about a manufacturing process or an engineering process quite precisely, and we can use those descriptions to help us build factories and bridges that do exactly what they are supposed to do. And yet for all the writing on agile software development, we still hear more stories of mini-waterfalls and technical debt and perversions of the Agile Manifesto than we hear stories about successful agile software efforts. This suggests strongly that agile software development, whatever it is, is not very similar to manufacturing or engineering.

The Standing Ovation

In 1992 I played bass for an obscure singer/songwriter/guitar player named Gerard McHugh, and that summer for a few weeks we had a 20-minute set opening for the Indigo Girls/Matthew Sweet tour through the Midwest leg of the tour, about 14 shows playing for audiences of 8,000-12,000 at each show. For about half of those shows we got standing ovations. It was an amazing experience, both good and bad. The shows were wonderful. Being three unsupported guys in a small Toyota van with two guitars, an upright acoustic bass, and a drum kit for three weeks was hard.

Which suggests an interesting question: how does one get a spontaneous standing ovation from 10,000 people who don’t know who you are? I could write and write and write for years and never explain how we did it. There is no universal process to be described. It takes talent and discipline and dedication and really, really good songs to make that happen. And every case is different. It is not manufacturing, it is not engineering. And yet it happens all the time.

Agile is Art

In various ways and in various forums I have been saying for some time now that agile software development is a species of the performing arts. Agile software development has all the hallmarks of an artistic performance like those of music, theater, or dance. It requires practice; it requires rehearsal; it requires a team to be constantly negotiating their own personal and professional relationships among themselves. And at the end of every iteration, an agile team releases a set of well-executed features to a group of users who come together to appreciate those features, just exactly the way a performance happens at a specific time and place for an audience.

I was not the first to notice this. Rob Austin and Lee Devin, professors of theater and computer science at Harvard, wrote a book in 2003 called Artful Making that demonstrates the close parallels between theater performance and agile software development. But Artful Making is a book for managers trying to understand what agile software development looks like from the outside. In my review of the book on my blog, I said, “This is a book for executives who wander by the agile team room and wonder why it’s so noisy and the floor is covered with index cards and there is a box of Lucky Charms on the table and the scrum master is wearing a Viking hat. It does not tell you how to do artful making, it only tells you what artful making looks like.”

Tools for the Writer

Describing a high-functioning agile team from the inside is hard work. It is exactly the same problem as describing how to get a standing ovation from 10,000 strangers, because it is the same sort of work done in the same sort of way.

One approach is to borrow the language of other disciplines, particularly from the liberal arts. Literary criticism, psychology, history, philosophy, economics all have rich traditions and sophisticated intellectual frameworks to describe the interactions among human beings in complex circumstances. I see the world as a musician and as a performer, so that language comes naturally to me, and applying those intellectual frameworks is productive for me. For another example, explore the Wikipedia page for “audience theory.” Dick Gabriel and Brian Marick have both done work along these lines, but I think we as writers have barely begun to explore what is possible.

Another approach is to use biography and autobiography. Nothing beats an experience report. Those who have worked on high-performing agile teams have a wealth of stories and anecdotes, but far too few are ever written down. Given a large enough pool of accounts of individual experience, both first-person and third-person, those interested may be able to tease out the common threads that make such teams so successful. As the agile movement gains more influence, this becomes more possible. My own feeling is that there is too much noise here in the agile community in late 2010 to isolate the real signal. This article is part of that work.

Another approach that I am finding appealing is to put ourselves in the position of the users of our software, and then to describe what it is like to be a user of software developed by a high-functioning agile team. A few examples exist today: in particular, I am thinking of the idea of “opinionated software” originated by those at 37signals, and of the “software craftsmanship” movement, who have an enormous amount of sympathy for the users of software. Today both of these approaches are overly simple, but I think they also both have a future. I think both movements require more sophistication and discipline, such as is shown by the “audience theory” example I mentioned above, but both have promise. In another article I called this “The Audience Experience,” as distinguished from User Experience (UX), which typically deals with the behavior of individuals. We in software lack an understanding of how we ourselves and our work influence the behavior of large groups of users.

Abstraction, not Analogy

I object to analogy when writing about the work of software development. Agile software development is not like working on a railroad, or like working in a fast food store, or like performing music. If agile software development is merely like an artistic performance, then the intellectual tools available to analyze artistic performance are not available. I assert that agile software development is artistic performance, and I back that assertion with my own knowledge and experience, gained from years in academia, years as a professional musician, and years working on agile teams. This identity makes it possible to bring to bear an enormous number of sophisticated theoretical tools. We must be able to describe our work directly, without analogy.

Much of the agile experiential training I have experienced seems to be constructed far removed from the actual work. Having finished the training, there is nothing useful to apply to the actual work. There is a place for experiential training in agile software development, but it has to be based in abstraction, not analogy. In May 2009 I organized the first Writing About Testing conference in Durango, CO, where the problem of analogy was a constant theme. There I had a number of conversations with Elisabeth Hendrickson, who has an exercise she calls “Wordcount.” It is an experiential training program with no programming or computers involved, but instead of being like working on an agile team, it is working on an agile team. Elisabeth has spent thousands of hours working on high-performing agile software teams, and she distilled that experience into an exercise that exposes the best of such work. This is not analogy, this is abstraction. Elisabeth’s example is worth emulating.

Feedback, Feedback, Feedback

There is a well-known acoustic music club in Nashville called The Bluebird Cafe. For decades now there has been a house rule at The Bluebird: no talking during the performance. I often used to play a well-known club in Atlanta called Eddie’s Attic that once considered instituting a similar rule. I was dead against it. As a professional musician, it is my job to command the stage, and to make the audience pay attention to the performance by sheer talent alone. If the audience is chattering during my performance, then I know that my performance is not good enough. The no-talking rule eliminates a critical feedback channel for the performers.

Today it is a fairly trivial matter to analyze server logs in real time. At the end of every iteration we can release new features and in those logs we can watch our audience view pages and click links and invoke those features. I have done this work, and I consider this a form of applause. When the features are good, we can watch our audience in real time use our software for real work. And if the feature is no good, we can find that out immediately and tune our approach for the next performance.

Agile is Ongoing Interaction

Specifying a software system precisely is fundamentally impossible, because the activity of software development, and the interaction of users with the software, is by its nature not subject to rigorous specification.

Instead, what we have is an ongoing interaction. The relationship of agile software development, the software itself, and the users of that software is exactly the same relationship as that of performers, the performance, and the audience.

We agile software people put on a show; the audience either buys tickets every two weeks or else they leave. Everything else is irrelevant. The trick is to put on a good show. The trick for us as writers about software is to show others the way to get that standing ovation.

Chris McMahon is a software tester and former professional bass player. His background in software testing is both deep and wide, having tested systems from mainframes to web apps, from the deepest telecom layers and life-critical software to the frothiest eye candy. Chris has been part of the greater public software testing community since about 2004, both writing about the industry and contributing to open source projects like Watir, Selenium, and FreeBSD. His recent work has been to start the process of prying software development from the cold, dead hands of manufacturing and engineering into the warm light of artistic performance. A dedicated agile telecommuter on distributed teams, Chris lives deep in the remote Four Corners area of the U.S. Luckily, he has email: christopher.mcmahon@gmail.com. Send the author your feedback or discuss the article in the magazine forum.

Getting Clojure

Extending Java Classes Using Proxy
by Gregg Williams
It’s incredibly easy to call Java code from Clojure, but who would have thought that modifying an existing Java library would be such uncharted territory? Gregg shares what he has learned.

One of the key advantages of Clojure over other versions of Lisp is its baked-in connection to Java. It’s easy (in most cases) to write Clojure code that executes Java code or any of the thousands of Java libraries that exist today. However, the correspondence between a unit of Java code and its Clojure equivalent is not always one-to-one, and an unsuspecting Clojure programmer can move from competence to total cluelessness, completely without warning.

At least that was my experience when I decided to use a Java graphics library named Piccolo2D for an application that uses an “electronic notecard” data format that I’ve created. Integrating Piccolo2D into my Clojure program was easy: just put its two JAR files on the Clojure classpath, and suddenly Piccolo2D was as much a part of my Clojure environment as Java was.

It was simplicity itself to call a Piccolo2D class from Clojure; subclassing (or, to use the preferred Clojure terminology, extending a base class), was something that existing Clojure documentation and web pages were strangely silent about. I eventually found that the proxy macro was the simplest way to do this in Clojure. The examples that I found showed how to redefine base class methods in the extended class, but I could find nothing on how to give an extended class its own constructor method.

This article, drawn from my experience in getting comfortable with Clojure, is a tutorial on the basic use of proxy, showing you what to do and how to think about extending Java classes and using them within Clojure. The code you will be looking at is a Piccolo2D sample program (written in Java) and an equivalent Clojure program that I wrote.

Introducing the Code

The Java and Clojure code that is important for this article is shown in Listings 1, 2, and 3. If you are interested, however, you can see the complete Java and Clojure programs at gist.github.com/369239; the original Java program is explained at www.piccolo2d.org/learn/interface.html.

I think, though, that I should explain the context of the code we’ll be examining. The complete InterfaceFrame program just demonstrates how to use various parts of Piccolo2D to draw various kinds of images in a Swing window. In Listing 1, the Piccolo2D class PPath is a type of object that can be drawn, and the ToggleShape class is an extension of PPath that has a new behavior added: when the mouse cursor is over an instance of ToggleShape and the mouse is pressed, the shape changes from an ellipse (its normal form) to a rectangle, and when the mouse is released, the shape resumes its original elliptical form. The Java variable fIsPressed represents the state of the mouse button, the paint method redraws the shape based on the value of fIsPressed, and the repaint() method forces the window to be redrawn to show the changes that have been made to the window.

Gregg/Listing_1.txt

/* Listing 1: The Java Implementation */

99  class ToggleShape extends PPath {

100

101      private boolean fIsPressed = false;

102

103      public ToggleShape() {

104          setPathToEllipse(0, 0, 100, 80);

105

106          addInputEventListener(new PBasicInputEventHandler() {

107              public void mousePressed(PInputEvent event) {

108                  super.mousePressed(event);

109                  fIsPressed = true;

110                  repaint();

111              }

112              public void mouseReleased(PInputEvent event) {

113                  super.mouseReleased(event);

114                  fIsPressed = false;

115                  repaint();

116              }

117          });

118      }

119

120      protected void paint(PPaintContext paintContext) {

121          if (fIsPressed) {

122              Graphics2D g2 = paintContext.getGraphics();

123              g2.setPaint(getPaint());

124              g2.fill(getBoundsReference());

125          } else {

126              super.paint(paintContext);

127          }

128      }

129  }

Gregg/Listing_2.txt

; Listing 2: This Clojure code implements the same

; functionality as Listing 1:

30   (defn create-toggle-shape

31     "Creates an ellipse that changes shape when it is clicked."

32     []

33     (let [fIsPressed? (atom false)

34           shape (proxy [PPath] []

35                         (paint

36                           [#^PPaintContext paintContext]

37                           (if @fIsPressed?

38                             (doto (.getGraphics paintContext)

39                               (.setPaint (.getPaint this))

40                               (.fill (.getBoundsReference this)))

41                             (proxy-super paint paintContext))))]

42

43       (doto shape

44         (.setPathToEllipse 0 0 100 80)

45         (.addInputEventListener

46           (proxy [PBasicInputEventHandler] []

47             (mousePressed

48               [event]

49               (proxy-super mousePressed event)

50               (reset! fIsPressed? true)

51               (.repaint shape))

52             (mouseReleased

53               [event]

54               (proxy-super mouseReleased event)

55               (reset! fIsPressed? false)

56               (.repaint shape)))))))

Reassembling the Onion

You’ve heard the phrase “peeling the onion” used to describe the process of understanding something from the outside in. In this article, I’m going to reverse that process, in the hope of making this article interesting to people of different levels of Clojure experience. Part I will explain the basic minimum needed to understand how to use the Clojure proxy statement to implement the Clojure equivalent of extending a Java class. Part II gives further helpful details if your program uses Swing. Part III covers several additional topics that will be useful to some readers.

Part I: Understanding Proxies

In Clojure, proxy is a macro that you use when you want to extend a base class or implement an interface—but only when you don’t need to add any new methods to the extended class. (For the latter, you must use gen-class, which is outside the scope of this article.) Java and Clojure implement this process in different ways: Java implements all the details in code that defines the extended class, while Clojure puts certain details inside the proxy form and other details elsewhere in the program. This article will explain how to extend classes in Clojure by first showing you the individual details, then explaining how they fit together.

The first step toward learning how to use proxies is to understand the following:

The First Law of Proxies

The proxy form itself can only redefine zero or more of the methods inherited from the Java base class (i.e., the superclass) or its ancestors.

The Second Law of Proxies

Everything else necessary to implement the extended class (i.e., the subclass) must be done in the environment surrounding an instance of the proxy class that was previously created from the base class. This includes Clojure equivalents of instance variables and the extended class’s constructor method.

With this as background, let’s look at each detail in turn.

The Syntax of proxy

The simplest version of a proxy form looks like this:

(proxy [baseclass-name] [baseclass-constructor-parameters]

method-redefinition-1

...

method-redefinition-N)

where a method redefinition looks like:

(method-name [parameters]

method-body)

Studying Proxies in the Wild

Look at the Clojure definition of create-toggle-shape, in Listing 2, lines 30 to 41 (which will be abbreviated in this article as L2, 30–41). The proxy corresponding to the Java class ToggleShape (all of Listing 1) is at L2, 34–41. On line 34, you can see that the proxy form’s base class is PPath and that PPath’s constructor takes no arguments. The rest of the form comprises a redefinition of one Java method, paint.

When you use the proxy keyword, you are creating an instance of an anonymous class that “stands in for” (i.e., serves as a proxy for) the base class. When you call a method on this instance-of-an-anonymous-class (called the proxy class), if the method is defined within the proxy form, it is executed; otherwise, Clojure looks to the base class and its ancestors to find and execute the code corresponding to the method named. This is exactly the same thing that Java does when it finds a method not found in the class corresponding to the method’s target object.

This is all I’m going to say about the proxy form itself. But there’s plenty more that needs to be done before this Clojure program will act like its Java counterpart.

Instance Variables

One of the ways in which the Java class ToggleShape extends class PPath is that ToggleShape has an instance variable fIsPressed, which is used to keep track of whether or not the mouse button is currently pressed.

How do you create the Clojure equivalent of a Java instance variable? According to the Second Law of Proxies, you must make the appropriate binding in the environment surrounding an instance of the proxy class. (The binding of a value to a symbol is roughly equivalent to assigning a value to a variable in state-based languages.) In this case the binding is done at L2, 33, which is in the same environment as the proxy form of lines 34–41. (Note that this proxy form is bound to the symbol named shape.)

Operating on the Proxy Instance

If you look at the code for ToggleShape, you will see that the constructor (L1, 103–118) creates and gives a value to the instance variable fIsPressedq, then it executes two methods on the new ToggleShape object being created, setPathToEllipse (line 104) and addInputEventListener (line 106). I just finished describing how the Java instance variable is transformed into Clojure binding. The next question is: How do you translate these two method invocations?

The answer is again to be found in the Second Law of Proxies (since the First Law doesn’t apply). Java uses a method operating on an object to get a lot of its work done. The Clojure equivalent of this is calling a function, one argument of which is a value representing the corresponding Java object.

Understanding how this occurs involves understanding the syntax that each language uses. On the Java side, line 104 reads setPathToEllipse (0, 0, 100, 80);, but this is assumed to be a shorthand for this.setPathToEllipse (0, 0, 100, 80);, where this represents the Java object being created. The Clojure equivalent is (.setPathToEllipse shape 0 0 100 80). To understand the code that is present at L2, 44, (.setPathToEllipse 0 0 100 80), look at the previous line, (doto shape. The doto macro is used when several Java methods are being called on the same object. By wrapping a series of Java-in-Clojure-syntax forms in a (doto object-value form, you can remove the value corresponding to the Java object (in this case, shape) from each method form. (A Clojure form, which is equivalent to a Java statement, is simply a unit of source code bounded by matching parentheses.)

Java Is super, Clojure Is super-proxy

Most Java method calls translate quite nicely into Clojure using a simple, well-known pattern (see “Clojure Syntax for Java Method Calls,” in Part III of this article, if you’re not already familiar with it). However, when the object is represented by the Java keyword super, this common pattern does not work.

Let’s start with the following “simple” Java method call:

my-object.paint(paintContext);

The equivalent form in Clojure would be

(.paint my-object paintContext) ; note the dot in ".paint"

However, in situations where you would be using super as the “object” (referring to the superclass of the current Java object), the corresponding Clojure code is different from what you would expect. Take, for instance, the “super” Java method call in line 126 of Listing 1:

super.paint(paintContext);

The correct Clojure code for this Java method call is

(proxy-super paint paintContext)

Note that the pattern of symbols here, ("super-object" method-name argument), is different from that of the “simple” method call, (method-name object argument). It’s very important to note that in the "super" method call, you do not place a dot after the method name—it’s paint, not paint.!

Putting the Pieces Together

Now that we’ve seen all the pieces that comprise this Clojure program, let’s put them together. In Java, the extended class (ToggleShape) is defined in one place as an extension of the base class, PPath; see L1, 99–118. The Java code contains an instance variable, fIsPressed (line 101), the constructor for ToggleShape (lines 103–118), and a redefinition of the paint method (lines 120–129).

Things are considerably different on the Clojure side, though. Only the redefinition of paint is contained within the body of the proxy form, as given by the First Law of Proxies; see L2, 34–41. The instance variable fIsPressed? (line 33) is bound within the scope that encloses the creation of the proxy class and its binding to the symbol named shape (line 34).

So where did the constructor go?

Before we get to the answer this question, I want to draw attention to a fundamental difference between the two programs being studied here. The Java program (Listing 1) customizes the base class PPath by defining a new class, ToggleShape, that acts like the base class except for the extensions described in its own definition.

The Clojure program (Listing 2) does not create a new, named class that extends an existing base class. It can’t, because proxy can’t do that; creating a named class is another reason to use gen-class. Instead, proxy creates an anonymous instance that “proxies” (stands in the place of) the base class, and other parts of the program must add the remaining extended-class behaviors that you want.

In short, in Java, you extend an abstraction and give it a name (by defining the extended class), then make an instance of it. In Clojure, you make an instance of an abstraction, give it a name, and then extend the instance. The proxy form (and the First Law of Proxies) covers the first step, and additional coding (and the Second Law) covers the second and third steps.

Let’s look at the details of this in Listing 2:

- The proxy form (line 34) creates an instance of a class that “proxies for” the base class, PPath, and does only that part of the class-extension process that can be accomplished by redefining existing methods (here, the redefinition of the paint method in lines 35–41).

- This instance is given a name, shape, on line 34.

- The additional code that extends the instance by acting in the environment surrounding the instance occurs in several places: line 33 (creating the instance variable fIsPressed?), lines 43–44 (setting the physical appearance of the instance), and lines 45–56 (redefining the listener code for the mousePressed and mouseReleased events).

So where, within all this code, is the equivalent of the ToggleShape constructor? It’s in the “additional code” described in the previous paragraph, lines 33 and 43–56. It corresponds directly to the Java code for the ToggleShape constructor in Listing 1, lines 106–117.

This ends the explanation of how proxy (at least, in its simplest form) works. If you’ve written a few Clojure programs, this may be all you need to start using proxy to extend (subclass) an existing Java base class.

Part II: Swing GUI Issues

Creating software that other people will use typically means providing a graphical user interface for a desktop application. The Swing GUI is part of the standard Java distribution, which means that it is always available from Clojure.

As with extending a class, implementing a Swing GUI is done differently in Java and Clojure. The rest of this section describes the differences found within the Java sample code and its Clojure equivalent.

Implementing Event Handlers

In Java, the constructor for ToggleShape adds its own event listeners by creating a new PBasicInputEventHandler and passing it to addInputEventListener (L1, 106–117). If you don’t know Swing very well, this chunk of code may look impenetrable. Think of the PBasicInputEventHandler as an object that “packages” two event listeners, mousePressed and mouseReleased. PBasicInputEventHandler can be thought of as “installing” these event listeners into the program, so that they will be called when the user presses or releases the mouse button. Also remember that PBasicInputEventHandler is itself a Java method that is called on the implicit object named this, which represents the ToggleShape that has just been created.

An examination of the Java and Clojure code implementing the mousePressed event handler shows several differences that it’s important to keep in mind when you write your own Swing event handlers in Clojure. (I assume that something similar would be true if you were to use the Eclipse SWT graphical interface as well.)

First, note how the addInputEventListener method is applied in each language. In Java, it is applied to the implicit this object (L1, 106). In Clojure, however, the method’s object is shape (L2, 43), for reasons described earlier in this article.

Second, addInputEventListener requires a different kind of argument. In Java, you create a new PBasicInputEventHandler object (L1, 106). In Clojure, you extend (subclass) the PBasicInputEventHandler class and redefine two of its methods using proxy.

Third, event handlers are defined differently in the two languages. Java defines the mousePressed method using a simple method definition (L1, 106–111) defined in no particular context; it is understood that this replaces the default mousePressed method that Swing supplies. However, the equivalent definition in Clojure (L2, 47–51) is made in the context of its enclosing proxy form, which is itself in a specific context (that of a specific object, shape).

Part III: Other Topics of Interest

We Don’t Need No Stinking Type Declarations

One small but welcome difference between Java and Clojure is the kind that make Clojure a joy to use. In Java, you must declare the type of methods, parameters, variables—well, everything. You can see this, for example, in the definition of mousePressed, which has one parameter (L1, 106). When calling Java code from Clojure, you don’t have to do this; witness the absence of the method type (public void) and the argument type (PInputEvent) on the Clojure side (L2, 47–48). In most cases, Clojure infers the argument type that the situation requires.

This same ability also means that you can often use the desired value in its current form, rather than the one that Java requires. For example, if a method requires an argument of type float and the value you want to use is of type int, you don’t need to coerce it into a float before using it—Clojure will usually do it for you! And if it doesn’t, see the next topic, below.

Type Hints

If your Clojure code gives a particularly odd error message or unexpected results, it may be that your code contains a typed value that Clojure isn’t interpreting correctly. For such occasional events, Clojure provides type hints, which Clojure uses when they are provided.

A type hint is an annotation that appears just before the value being annotated. It consists of the two characters #^ followed, without space, by the required type name—for example, #^PPaintContext. In fact, you can see an example of this same type hint In Listing 2, line 35, where the parameter paintContext is given the type PPaintContext. (By the way, the #^ notation is a shorthand for a longer notation that looks like this: #^{tag: PPaintContext}.)

Note: Starting with Clojure 1.2, the notation for type hints has changed. The old notation, #^, has been deprecated in favor of a different notation, ^. Clojure 1.1 and before still use #^. Clojure 1.2 can use either. In some future version, only ^ will work.

Clojure Syntax for Java Method Calls

Most Java code of the form

object1.method2(arguments3);

is “translated” into the following Clojure form:

(. object1 method2 arguments3)

(Be sure to remember the “dot” operator just after the opening parenthesis.) I like this syntax because the argument order, with the object first, reminds me that this code runs in the environment of Java, not Clojure.

However, most programmers in the Clojure community prefer the alternative syntax, which mimics the standard (function-name arguments) syntax of Clojure and all other Lisp-family languages. This is the syntax that is used throughout Listing 2. The above example translates to the following “idiomatic” Clojure code:

(method2. object1 arguments3)

The method name is placed first (with a “dot” character placed after the name), followed by the object name, and ending with the zero or more arguments listed in the same order as they would be in Java.

Importing Java Classes into Your Clojure Program

There is, regrettably, one way in which Java is better than Clojure—at least in the sense that chocolate is “better” (i.e., more pleasant) than broccoli. The Clojure way is “better” in the sense of “better for your program;” your program is smaller and (possibly) faster because no unused methods have been included, but it’s a lot more hassle to the programmer.

In any case, here’s the story: In Clojure, as in Java, you must specify each and every class you want to use in your program. (The one exception to this is that all classes in java.lang are automatically imported.) In Java, you can import all the classes in a given package by using the * wildcard character—for example, import javax.swing.*;.

Rich Hickey, the inventor of Clojure, didn’t think that importing all the classes from a package into the program’s namespace was “a good idea,” so that’s what he implemented. As a result, you must explicitly name each Java class that you want to use.

Listing 3 shows the ns (short for namespace) form that begins my Clojure program (Listing 2 occurs later in the same Clojure source file). There is an import macro in Clojure that can also be used, but using the import: keyword within the ns form at the top of your program is the preferred method of importing in the Clojure community.

Listing 3: Java class import information, found within the Clojure ns (namespace) form:

Gregg/Listing_3.txt

/* Listing 3: Java class import information, */

/* found within the Clojure ns (namespace) form */

16   (ns piccolotest

17     (:gen-class)

18     (:import

19       (java.awt Color Graphics2D)

20       (edu.umd.cs.piccolo.nodes PHtmlView PImage PPath PText)

21       (edu.umd.cs.piccolo PCamera PCanvas PInputManager PLayer PNode

22         POffscreenCanvas PRoot)

23       (edu.umd.cs.piccolo.event PBasicInputEventHandler PDragEventHandler

24         PDragSequenceEventHandler PInputEvent PInputEventFilter

25         PPanEventHandler PZoomEventHandler)

26       (edu.umd.cs.piccolo.util PAffineTransform PBounds PDebug PDimension

27         PObjectOutputStream PPaintContext PPickPath PStack PUtil)

28       (edu.umd.cs.piccolox PApplet PFrame)))

Each form inside the (:import ... ) “clause” has the following syntax:

(package-name method-name-1 ... method-name-N)

where all the methods listed belong to the package listed. You can see instances of this in L3, 19–28.

Ensuring that External Libraries Are Present

Novice and professional alike inevitably have the experience of writing a program that looks perfect in all respects but doesn’t run. If the classes you are importing aren’t part of the Java language (e.g., the Piccolo2D library used in this program), then you need to ensure that this external library is available for loading by your Clojure program. How this is done varies with the Clojure environment you’re using, so you should consult the appropriate documentation for details. In most Clojure IDEs, your program is part of a group of resources called a project; the IDE’s documentation will tell you how to add an external library (usually one or more .jar files) to a project.

Conclusions

Various Clojure bloggers and book authors praise the mechanism for calling Java code from Clojure as “simple and direct,” but I have to say that in my experience that’s not always the case. Java statements do not always translate one-to-one into Clojure forms, and the two languages handle class extension (i.e., subclassing) differently.

With its many differences from state-based, procedural languages, Clojure is, in itself, a challenge to most mainstream programmers. I can’t deny the exhilaration of seeing Clojure code running, but being stuck is no fun at all. I wrote this article in the hope that it will prevent you from being stuck like I was, so you can spend more of your time enjoying the leverage that Clojure brings to programming.

I invite feedback, corrections, and alternative solutions in relation to this article; you can reach me at gregg@GettingClojure.com. Until then, good hacking!

Gregg Williams got his first taste of computing programming an IBM 1130 in FORTRAN-IV. He started his first programming job working in APL and finished it programming COBOL and RPG-II. As senior editor at BYTE magazine, he wrote the cover stories on the IBM PC, the Commodore Amiga, the Apple Lisa, Macintosh, and Macintosh II, and many long-defunct computers. During 10 years at Apple, he edited and wrote for Apple Direct (later Apple Directions) as part of Apple’s support to developers. He has an open-source project at www.InfoML.org and is managing www.GettingClojure.com, a website for Clojure beginners, where a slightly different version of the article first appeared. Send the author your feedback or discuss the article in the magazine forum.

Shu Ha Ri

Learn, Detach, Transcend: Steps to Agile Mastery
by Jeff Langr, Tim Ottinger
Our well-meaning agile coach’s maturity model was based, either deliberately or subconsciously, on Shuhari, a Japanese martial arts concept involving three stages of mastery: “first learn, then detach, and finally transcend.”

Many well-meaning agile proponents have devised various scales to measure agile maturity, not unlike the Capability Maturity Model (CMM). A Google search for “agile maturity model” returns a fair number of results, including a blog post whose title, “Yet Another Agile Maturity Model,” suggests their unwillingness to disappear. The intended goal of such a model is to help managers, developers, and coaches assess the effectiveness of their company’s transition to agile methods, and to highlight which practices need further development.

We have no problem with the notion of a team wanting to understand areas in which they need improvement. But we also think most teams have a sense of what they’re doing poorly. A good coach can spot these same problems in short order, although it usually takes longer to understand root causes.

Practice-Driven Scale vs Goal-Driven Scale?

At one company, an agile coach introduced a five-level maturity model, very much like the CMM. The scale was backed by a checklist oriented toward goals, not practices. At the lowest maturity level, the goal was basic education and understanding of agile. At the highest level, the expectation was that the team continually assessed and improved themselves. Well, that’s agile, right? All practices, principles, and values aside, if your team isn’t continually seeking improvement, you’re not agile.

While the intention for the model was noble, unfortunately it ended up being used for nefarious ends. Although it was dreamed up by a respectable agile coach in one organization, an executive in another organization appropriated the scale and began to use it to grade teams. Insidiously, the perception of agile shifted from a team-centric mechanism to a top-down governance scheme.

The thing that worries us most about agile maturity models is the idea of consistent scale. Standardization is a good idea, and indeed we always seek some level of standardization within an agile team (see our Coding Standards card for an example). But across teams, not so much: it’s simply pointless to seek the same progress on the same scale with different people all working to the same end state.

It is hard to imagine that software developed for different types of products, by teams with varied experiences, for deployment in different regulatory environments, or for different markets should operate in precisely the same way or conform to the same metrics. It is rather unlikely that two different teams would optimize the same way, let alone all of the teams within a corporation.

Still, it is not wrong for a company to want to measure the accomplishment of its people. What if we rate according to proficiency at agile practices like TDD or pairing? That measurement certainly has more meaning than counting lines of code per week or “stays later than his coworkers.” But it can also be damaging if, for example, you unfairly pit the Python team doing greenfield development against the C++ team struggling with a large legacy code base. It may also be meaningless: A team might have produced the best possible code using TDD and yet still fall down when it comes to delivering on customer expectations.

The most useful measurements of a team’s ability are necessarily customer facing. Look at Running Tested Features (RTFs), defect counts, consistency of delivery, and customer satisfaction metrics, all directly related to how well the team can deliver quality software. Measure the trends over several releases. And remember that it’s still meaningless to compare these numbers across teams—it provides no value to the customer. It will definitely not improve the team’s capacity, and may even demoralize them.

Instead, to understand your maturity, look inward. Your goal is to improve yourself and your team, not keep up with the Jones’s team. The empowered, energized team is best characterized by the self-awareness of need and the desire to improve both team and product.

Shuhari

One scale that seems to have some meaning (though no certification body and no way to standardize) is Shuhari, a simple—but romanticized and mythologized—concept. Our well-meaning agile coach’s maturity model was based, either deliberately or subconsciously, on Shuhari. Both scales are focused on stages of learning.

Shuhari is a Japanese martial arts concept (also encountered among players of Go and is actually built upon three Japanese words, thus three stages of mastery, that roughly correspond to the phrase “first learn, then detach, and finally transcend.”

Shu

At the shu stage, the student copies the master’s moves as perfectly as possible. The mentor corrects the student if the movement is imperfect, inefficient, or ineffectively performed. A student really has very little self-expression, but is being schooled in the fundamentals of the art. When the student has reached a solid level of mimicry, he has learned what to look for in form and balance and style and posture. He is competent enough as a novice, yet his knowledge is more memorization and even muscle memory. He is aware of his movements and knows he is “doing them right.”

This is how we often began agile transitions. We started with strict workflow, strict practices, scheduled pair programming, rules, and strictures. Stand-up meetings were strictly three questions, and we sometimes limited attendance to only those producing the software (pigs v. chickens). We may have placed restrictions on hours worked per week. We programmed in pairs and conducted workshops on refactoring, TDD, planning, etc. The goal of the training and coaching was to deliver fundamental theory and guide students to proper form and practice.

When a team produces consistent results using rigid methods, they have completed their shu stage. It is better to reach shu than not to reach it. It is better still to go beyond the kinds of things that can be measured with a practice-oriented Agile Maturity Model.

Ha

A budding martial artist will move from the shu to the ha stage. In this stage, he or she understands the principles well enough to depart from rigid mimicry and try different variations. Because he knows the accepted forms and their purposes, he may notice the difference in effect between his experimental way and the way he was taught. If his departure works less well, he returns to the way of his teaching. If his variation works better for him, he may retain it. This stage involves experimentation and observation, and in time the techniques become his own.

In our agile transitions, we try to quickly reach a point where the team can retrospect and make measured improvements on its own practices. If those changes don’t pan out, they are abandoned or modified. A coach still provides value at this stage by helping keep the team mindfully measuring their changes and not falling back on old habits. The more a team becomes self-directing, the less they need a full-time coach.

In the ha stage, teams often will start to innovate in the way they close their feedback loops, the data they use in their big visible charts, and the way they design their software. They may adopt different tools and different protocols in dealing with each other. The ha stage will include some successes and some failures, but the team will be wiser with each experiment.

Meaningful retrospectives are critical if the team is to reach ha. Some teams will reach shu, then abandon retrospectives and cling to the rules. Such teams are practicing Scrum or XP (or what-have-you) mechanistically, and will rarely move forward. This stagnation may require a coach change to re-trigger the team’s interest in improvement and self-management.

As the team matures in the ha stage, it’s perfectly reasonable for them to depart from purely Agile concepts. They may adapt more techniques and concepts from the Theory of Constraints or Lean. They may adopt the Pomodoro technique or features from Getting Things Done. They may create or adopt new build and test tools. They may begin to adopt portfolio management and prioritization techniques they had never considered before. They may automate more of their processes.

Some leaders may take advantage of increased freedom to push their teams to return to pre-agile practices, all the while declaring themselves to be “post Agile” without ever internalizing the principles. They will abandon practice and principle alike. A coach can tell progress from abandonment.

Ri

In the ri stage, the martial artist has reached a point of mastery. Her reflexes and thinking are well-formed and she requires little conscious guidance to carry out combinations of movements. She is largely free from slavishly following old forms, in that the forms have become second nature (tacit knowledge). She is able to teach and to adapt to new situations easily.

At the ri stage of an agile transition, the team becomes capable of abandoning rules and strict forms. They can produce quality work, groom the code base, and satisfy customers because it is their collective will to do so, and because they have built and tested their own body of rules and practices. They may discover ways to transform their work system that their coaches never considered.

The ri stage is the goal of agile team, coach, and company who have sought to honestly pursue this type of work system.

Shuhari is the progression through these three stages. The Shuhari progression helps a team develop its ability to deliver value, but it makes the very term “agile” start to look pretty nebulous. Is a team that no longer follows the practices non-agile, or post-agile, or just advanced agile? How do we measure relative agility of one team against another? How do we reward teams who have become agile? How do we correct those who don’t get it?

Measurement and comparison, as we’ve mentioned, are not very important. The real questions are whether the quality of delivery is improved, and whether the organization as a whole is delivering value to the customers in an effective way. Far from blurring the term “agile” to mean merely “good,” Shuhari defines agile as one way to do good things well. When we find better ways, you’ll hear from us.

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.

When Did That Happen?

On the Radio
by Dan Wohlbruck
In the Golden Era of Radio, people listened to live concerts from New York, soap operas like “Stella Dallas,” the comedy of Amos and Andy, and thrillers like “The Phantom.” Until 1950, all radio broadcasts were live.

On November 2, 1920, just ninety years ago, station KDKA in Pittsburg, Pennsylvania, began broadcasting the first commercial radio signal. Without wires, needing only a relatively inexpensive receiver, radio was an instant success that soon went nationwide. Radio, however, and the waves that were sent into the air, were first considered as a wireless telegraph which was better suited for ship-to-ship and ship-to-shore communication than as a commercial means of entertainment.

Heinrich Hertz first demonstrated the ability to generate radio waves in 1886. Hertz was inspired by Maxwell’s theory of electromagnetism and his prediction of the existence of electromagnetic waves that would travel at the speed of light. To generate and transmit radio waves, Hertz used a high voltage induction coil, a condenser, and a spark gap. The poles at each end of the spark gap oscillated and sent an electromagnetic wave. To prove the existence of the wave, Hertz invented a receiver made of copper wire molded into a circle with a brass sphere on one end. The sphere was placed close to the wave generator and when the receiver sparked, the existence of radio waves was confirmed.

The person who took radio from an interesting experiment in electricity to a worldwide phenomenon was Guglielmo Marconi. Marconi was born in Bologna, Italy, on April 25, 1874. He was educated by tutors at his father’s estate where he became interested in electricity in general and Hertz’s waves in particular. In 1895, Marconi began his radio experiments, succeeding in sending an electromagnetic signal over a distance of 1.5 miles. In 1896, Marconi was awarded the world’s first patent for wireless telegraphy. In 1897, he founded The Wireless Telegraph & Signal Company which was re-named in 1900 to Marconi’s Wireless Telegraph Company. In 1899 he established wireless communication between France and England across the English Channel. In 1900 Marconi was awarded patent No. 7777 for telegraphy and, on an historic day in December 1901, he proved that wireless waves were not affected by the curvature of the Earth when he used his system to transmit the first wireless signals across the Atlantic Ocean, a distance of 2100 miles.

The world began to find uses for Marconi’s radio waves. In 1903, President Theodore Roosevelt exchanged greetings with King Edward VII by wireless transmission and in 1905 the battle of Port Arthur was reported in the same way. In 1915, speech was first transmitted across the continent from New York City to San Francisco and across the Atlantic Ocean from Naval radio station NAA at Arlington, Virginia, to the Eiffel Tower in Paris.

Then came radio station KDKA.

The Westinghouse Company owned KDKA and, within months, launched radio stations in Boston, Chicago, and New York. Corporate stations soon competed with amateurs and experimenters for the airwaves. In response to the proliferation of broadcast signals, in December 1921, the Department of Commerce announced regulations to limit public radio stations to those that met new standards for equipment and signal strength. Standards aside, by the end of 1922 there were more than 500 public radio stations in the United States, operating in every state.

The general public wanted to know how to receive these radio signals and the programs that they carried. In response, radio clubs sprang up and a mini-publishing boom in how-to manuals ensued. But not everyone saw the radio as the road to paradise. The Nation magazine, in an article published in March 1922, lamented this new development:

“Think of the tragic fate of some future Thoreau who goes to his beloved woods in search of solitude only to find the night made suddenly hideous by the ‘famous laughing saxophone’ played at station XYZ and received and amplified by equipment in possession of the Boston Boy Scouts in camp not far away!”

The laughing saxophone of 1922 gave way to the Golden Era of radio, a 30 year period from 1925 to 1955. Everyone caught the radio fever. At its height in 1947, almost 90% of the population of the United States owned and regularly listened to the radio.

On November 15, 1926, just six years after the first commercial broadcast, the National Broadcasting Company (NBC) was formed. The network had the task of serving daily programming to 13 million radio sets. Their radio stations carried live concerts from New York, soap operas like “Stella Dallas,” the comedy of Amos and Andy, and thrillers like “The Phantom.” Adding to the drama, until 1950, all radio broadcasts were live.

NBC investors wondered how to pay for all this. In early 1922, the American Telephone & Telegraph Company promoted the idea of using advertising to finance programming. Initially AT&T claimed that its patent rights gave it a monopoly over national radio advertising, but a 1923 industry settlement allowed other stations to begin to sell time, as well. And so it was advertising that paid for free, public programs.

Then, in the 1950s, television broadcasting superseded the radio. Radio stations dropped their dramatic programming and became niche carriers of specialized content. Although the golden age of radio was over, the spread of wireless communication devices was about to begin.

The radio era began 90 years ago—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.

Calendar

Author sightings, partner events, and other notable happenings.

Author Appearances

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

- Nov 7–11, AYE Conference: Exploring Human Systems in Action, Phoenix, AZ
Many sessionsEsther Derby, author of Behind Closed Doors and Agile Retrospectives

- 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 11, RubyConf, New Orleans, LA
“Maintaining Balance while Reducing Duplication”David Chelimsky, author of The RSpec Book

- Nov 11–13, RubyConf, New Orleans, LA
MCChad Fowler, author of The Passionate Programmer

- Nov 11–13, RubyConf, New Orleans, LA
KeynoteDave Thomas, co-author of The Pragmatic Programmer

- Nov 12, University of Wisconsin Milwaukee Learning Technology Center, Milwaukee, WI
“Seven Languages in Seven Hours” full day workshopBruce Tate, author of Seven Languages in Seven Weeks

- Nov 12–14, Great Lakes Software Symposium, Chicago, IL
Various topicsDave Klein, author of Grails: a Quick-Start Guide

- Nov 12–14, Great Lakes Software Symposium, Chicago, IL
“Improving Customer Conversations” and several other talksEsther Derby, author of Behind Closed Doors and Agile Retrospectives

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

- Nov 13, Marion Correctional Institute (MCI) Technical Conference, Marion, OH
Keynote and a session on test-driven developmentJeff Langr, co-author of the Agile in a Flash card deck

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

- Nov 14–19, 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, FL
“The Value of Value Story Cards”Jared Richardson, author of Ship It!: A Practical Guide to Successful Software Projects

- Nov 19, Italian Agile Day, Genova, Italy
“The BDD Live Show” and “Workshop: Ruby for Java programmers”Paolo Perrotta, author of Metaprogramming Ruby

- 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

- Nov 30–Dec 3, The Rich Web Experience, Ft. Lauderdale, FL
“Grails: Bringing Radical Productivity to the JVM”Dave Klein, author of Grails: a Quick-Start Guide

- Dec 1–3, Summit 2010 Europe, London, UK
Workshop Seminar: “Agile in the Workplace”Rachel Davies, co-author of Agile Coaching

- Dec 2–3, Agile, Lean & Kanban EXchange, London, UK
SpeakingRachel Davies, co-author of Agile Coaching

- Dec 7–10, Pragmatic Studios, Denver, CO
iPhone/iPad Programming StudioDaniel Steinberg, co-author of iPad Programming: A Quick-Start Guide for iPhone Developers and author of Cocoa Programming: A Quick-Start Guide for Developers

- Dec 8–10, Pragmatic Studios, Denver, CO
Pragmatic Rails Studio with Dave ThomasChad Fowler, author of The Passionate Programmer

- Dec 9, IIBA, Boston Chapter, Waltham, MA
“The Role of the BA in an Agile Project”Johanna Rothman, 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

O’Reilly Events

- Nov 15–17, San Francisco, CA
Web 2.0 Summit: An invitation-only event, Web 2.0 Summit brings the intelligence, innovation, and leadership of the Internet industry together to discuss and debate the most critical issues and strategies driving the Internet economy now and in the near future.

USENIX Events

- Nov 7–12, San Jose, CA
Lisa ’10: 24th Large Installation System Administration Conference. The 2010 training program includes over 45 classes and they’re again offering series of classes focusing on some of the most important topics you’ll encounter.

- Nov 29–Dec 3, Bangalore, India
Middleware 2010: ACM/IFIP/USENIX 11th International Middleware Conference. The Middleware conference is a forum for the discussion of important innovations and recent advances in the design, construction, and uses of middleware.

Other Happenings

- 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.

- Dec 3
John Backus would have been 86.

- Dec 4
Eric Raymond, aka ESR, is 53.

- Dec 9
Grace Hopper’s 104th birthday.

- Dec 10
Ada Lovelace’s 195th birthday.

- Dec 10
Ada, the programming language, is 30 today.

- Dec 16
John Bardeen and Walter Brattain created the first transistor on this day in 1947.

- Dec 17
Ken Iverson, creator of APL, would have been 90 today.

- Dec 17
Les Earnest, inventor of first spell checker and of the finger protocol, is 80.

- Dec 23
Birthday of Bob Miner, who wrote Oracle’s original database software.

- Dec 25
Richard Greenblat, famed MIT hacker, is 66.

- Dec 26
Charles Babbage’s 219th birthday.

- Dec 28
Linus Torvalds is 41.

- Dec 30
Bjarne Stroustrup is 60.

- Dec 31
Leonard Adleman, the A in RSA encryption, is 65.

- Jan 10
MUD co-creator Richard Bartle is 51.

- Jan 10
Donald Knuth, who continues to inspire authors who are having trouble finishing that book, is 73.

- Jan 11
Tony Hoare, author of Quicksort, is 77.

- Jan 20
Sims creator Will Wright is 51.

- Jan 21
Paul Allen is 58.

- Jan 22
On this day in 1984, Superbowl viewers watched a woman with a hammer smash Big Brother.

- Jan 24
Alain Colmerauer, Prolog’s creator, is 70.

- Jan 25
Pac-Man creator Toru Iwatani is 56.

- Jan 31
Guido van Rossum, author of Python and possessor of an excellent last name for a programmer (Google “R.U.R.”), is 55.

Shady Illuminations

The Undisappointed
by John Shade
John vows to expect nothing, thuse ensuring that he will not be disappointed.

Blessed is he who expects nothing, for he shall never be disappointed.
–Jonathan Swift

Thanksgiving is bearing down upon those of us who live in the United States, Canada, or Grenada. For those of you out of the path of the annual Gratitudinalia, an explanation may be in order.

In the United States, Thanksgiving is the day on which we celebrate having enough to eat by eating everything in sight and falling asleep on the couch. In Canada, the holiday commemorates Martin Frobisher’s unsuccessful search for a Northwest Passage. Frobisher gave up, went back to Newfoundland, and resolved not to be disappointed. On Thanksgiving Day in Grenada, they remember the 1983 U.S. invasion.

If those are my choices, I prefer the Canadian model of Thanksgiving. I choose to honor the day in Swift/Frobisher style by resolving not to be disappointed.

Here are the matters in which I resolve not to be disappointed this year:

As the winds of political rhetoric rustle the November leaves, I will keep in mind that the trees of bureaucracy are deep-rooted, and I will not expect anything but Business as Usual from my government. Or from business.

I will not expect Apple to change its pricing model, although I expect them to move the sap bucket from tree to tree regularly.

I will not expect the island nation of Tuvalu to survive global warming, except in the form of the .tv domain, which I think will continue to do very well.

I will not expect Oracle to do anything with Java but what benefits Oracle.

I will not expect to start liking cranberries. Why in the name of all that is rational farmers slap on the waders and slog out into the November bogs to harvest those bitter little pills I’ll never understand.

I will not expect 2011 to be the Year of Artificial Intelligence, the Semantic Web, or Unix on the Corporate Desktop. I expect 2011 to be the Year of the Hangnail.

John Shade was born under a cloud in Montreux, Switzerland, in 1962. Subsequent internment in a series of obscure institutions of ostensibly higher learning did nothing to brighten his outlook. For which he is thankful. Send the author your feedback or discuss the article in the magazine forum.