PragPub 2011-06: Issue #24

Table of Contents

Features

Pair Programming in a Flash

by Jeff Langr, Tim Ottinger

The rules of pairing, pairing smells, and what you can do when a pair isn’t available.

Practical Mock Advice

by Zach Dennis

Zach shows mocks some much-needed respect.

Language Lessons

by Michael Swaine

A guide to all the programming language articles published in PragPub to date.

When Did That Happen?

by Dan Wohlbruck

The author of the first book on computer programming was born in this month, nearly a century ago.

Departments

Up Front

by Michael Swaine

Something old, something new...

Choice Bits

On a bus going to a secret location! Fueled by desperation! And a disturbing lack of pants.

Guru Meditation

by Andy Hunt

Learning curves are typically not uniformly steep, or we’d call them learning slopes. Andy tackles one of the steeper segments of the agile learning curve.

Way of the Agile Warrior

by Jonathan Rasmusson

Velocity is a powerful tool for planning. The trick is to get managers to use it correctly.

Calendar

Author sightings, upcoming conferences, and all the coverage of the royal wedding that you will ever need.

Shady Illuminations

by John Shade

John can’t resist the temptation to make fun of dumb laws, short attention spans among technology marketers, and Mark Zuckerberg.

Except where otherwise indicated, entire contents copyright © 2011 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

Permeable Boundaries

by Michael Swaine

Something old, something new...

Electronic publishing is permeable publishing.

Old-fashioned print-on-paper publishing wrapped each book or magazine in an impermeable membrane, the cover. Inside the cover, you were in the world of Amazing Stories or Wuthering Heights. Each book or magazine was its own world.

Electronic publishing, potentially at least, embeds a book or magazine in the real world. Or the World Wide Web, which is rapidly coming to mean the same thing, it seems.

An electronic magazine, like this one, can link to articles outside its covers. It can even link to articles in other issues of itself. So, as we do in this issue, we can include an additional two dozen articles that logically fit the theme of an article in this issue. And in doing so, we can present the material in a new context, as we do in “Language Lessons” in this issue.

But I don’t want to give the impression that this issue is all PragPub Remixed.

Zach Dennis is here with some fresh insights on using Mocks. Zach helped write The RSpec Book, so he knows his Mocks.

Jeff Langr and Tim Ottinger have been demonstrating what you might call pair authoring in PragPub recently, and they are back this month with the first part of a two-part exploration of pair programming.

And that’s not all. Dan Wohlbruck flashes back to the first book on programming ever written, Andy Hunt tackles one of the steeper segments of the agile learning curve, and Jonathan Rasmusson devotes his “Way of the Agile Warrior” column to getting you up to speed on velicity.

As for John Shade, well, he has a few things he wants to get off his chest.

Welcome to our permeable little world. Oh, and one more thing: Next issue will be a bit special. We’re going to focus on Clojure, a language that has permeable boundaries itself, with ties to one of the oldest programming languages and some of the most cutting-edge applications.

Choice Bits

Ballad of a Thin Medium

Something is happening here and the twittersphere knows what it is.

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^ | NEW | CoffeeScript
2v | 1 | Agile Web Development with Rails
3 | 3 | Crafting Rails Applications
4 | 4 | Programming Ruby 1.9
5 | 5 | The RSpec Book
6^ | NEW | HTML5 and CSS3
7^ | NEW | Metaprogramming Ruby
8^ | NEW | Rails Test Prescriptions
9v | 2 | iOS Recipes
10^ | NEW | Continuous Testing
11^ | NEW | Exceptional Ruby

The Stuff We Have to Put Up With

Holy crap, Internet. STOP SHOWING ME ADS FOR SHOES. I bought ONE PAIR from you MONTHS ago. Don’t make me kick you with them! — @SaraMG

Dear LinkedIn, I don’t need a reminder; I know you exist. Sending me this many mails about people I don’t know makes me wish you didn’t. — @terriko

Check out how I am sick of my clojure feed being filled up with how I solved 4Clojure problem n #clojure. — @abedra

This Coding Life

The talent agent that shares the floor with my office is still on AOL. I hear “you’ve got mail!” throughout the day. It’s not ironic. — @snipeyhead

Going to an ironic cocktail party themed party tonight and a costume party 12k race tomorrow morning. Ah, SF. — @harthvader

It’s said that 10,000 hours makes you an expert at something, and I just realized I’m at 10,000 tweets. Does that make me an expert tweeter? — @pamelafox

Flickr notified me that I was tagged in a photo but my name was spelled wrong. How did it know it was me? — @yardi

I find your lack of pants disturbing. #replaceawordinastarwarslinewithpants — @darthvader

Funniest thing I’ve heard RE: C++ —When the only hammer you have is C++ every problem looks like your thumb. — @bdudney

Haven’t written this in a while: public static void main (String[] arrrImAPirate) { } — @invalidname

A simple regex can make life so much better. — @cdwarren

Entropy as a Service. #eaas #thankmelater — @abedra

On a bus going to a secret location! Might not be secret, maybe they told us and I wasn’t listening. #zeitgeistym yfrog.com/h0xsoifj — @anna_debenham

I know induction works because it has worked reliably in the past. — @stuarthalloway

Oh Randall. :) One for the geek feminists! http://xkcd.com/896/ - Marie Curie — @ginatrapani

Bears and Other Thirsty Things

Thirsty Bear was mobbed, watching 3d YouTube with 2 color glasses fun. Dinner at Mel’s now. #io2011 — @eburnette

My review is coming up at work. My boss just informed me that he is going to rate me a "2-needs development" on drink ordering. — @snipeyhead

Looking up the nutritional content of Rum during an office discussion on Scurvy. — @Poshy

...& many folks report that drinking makes it easier for them to not be shy. But, people, you can’t just get drunk every day. Doesn’t scale. — @pamelafox

Also, free beer to anyone who can distract Ward Cunningham long enough to make sure he doesn’t attend my session. #intimidated #osbridge — @ElizabethN

What It Is

Clojure; It’s the new Ruby! http://t.co/2LXDglL — @slagyr

“It’s in Dropbox” is the new “It’s on the wiki.” — @anildash

Planking—it’s the new vogueing. — @BXGD

Whiskey wine—it’s the new pear cider!! yfrog.com/hscymwcj — @liammcguire

Popular in Canada, it’s the new big in Japan. #eurovision — @bowendesign

Amish. it’s the new hipster. RT @Holl_x: Amish twerker party — @Liz_Money

I’m pretty sure this bus is fueled by desperation. It’s the new bio-fuel, I’m told. — @sketchset

People had better get used to gas prices at around $4/gallon. It’s the New Normal. — @RockDots

And yes, Alabama is wearing camo hats. It’s the new houndstooth. — @WarBlogle

This month we followed Chris Adamson, Heather Arthur, Aaron Bedra, Benedict Bowen, Ed Burnette, Anil Dash, Anna Debenham, Röck Döts, Bill Dudney, Pamela Fox, Sara Golemon, Stuart Halloway, Jason the commenter, Lynn, Liam McGuire, Micah Martin, Liz Money, Elizabeth Naramore, Terri O, Jamie Orz, snipe, Gina Trapani, Darth Vader, WarBlogle.com, Christopher Warren, and Sarita Yardi. You can follow us at www.twitter.com/pragpub.

Guru Meditation

Getting Past Agile Advanced Beginner

by Andy Hunt

Learning curves are typically not uniformly steep, or we’d call them learning slopes. Andy tackles one of the steeper segments of the agile learning curve.

Again and again folks tell me that they’re stuck. They embarked on the journey to become agile practitioners, but despite the best intentions, they can’t seem to break through to function as a true, self-directed, self-correcting agile machine.

Instead, they are stuck. Stuck following published “best practices” that someone else came up with for a magazine article. Stuck following a plan that was handed down to them, due on a deadline negotiated by lawyers they’ve never met or spoken with.

The team is practicing some agile methods, but they aren’t agile. Left to their own devices, nothing will change that. They’ve reached the Advanced Beginner stage, and it’s going to take some care and attention to move past this to become a competent practitioner.

To understand this, let’s look at the Dreyfus Model of Skill Acquisition.

The Dreyfus Model

The Dreyfus Model is a helpful way of looking at how people acquire and grow their skill sets. It defines five levels that you experience as you gain abilities at some specific skill (for more, see Pragmatic Thinking and Learning).

Here are the levels, with some key features of each:

Novice - Rules-based, just wants to accomplish the immediate goal

Advanced Beginner - Needs small, frequent rewards; big picture is confusing

Competent - Can develop conceptual models, can troubleshoot

Proficient - Driven to seek larger conceptual model, can self-correct

Expert - Intuition-based, always seeking better methods

Most people, in most skills, never get beyond Advanced Beginner. This certainly seems to be true for would-be agile practitioners. At the Advanced Beginner stage, you’re comfortable enough to sort of muddle your way through. And for most folks, that’s enough. It kind of looks good on the outside, and you can list it on your resume. But that’s a hollow victory. You won’t reap the benefits that an agile approach can provide. In terms of productivity, you might as well be coding in COBOL with a pencil on a yellow legal pad.

Fortunately, we can do better than that.

There are five levels in the Dreyfus model, but not all of the levels are equal sized or as easily traversed. For instance, it’s easy to go from Novice to Advanced Beginner, but the jump from Advanced Beginner to Competent is much harder.

What we need to do is to see how, specifically, to make the jump from agile Advanced Beginner to becoming a Competent agile practitioner. If you look at the levels above, one big difference between an Advanced Beginner and a Competent practitioner is the Competent’s ability to develop and use conceptual models.

So it seems the first thing we need to do is to establish some kind of a mental model about agility.

An Agile Mental Model

Agile is all about taking small bites and focusing on continuous, not episodic, development. You want to do a little of everything all the time, and not face big lumps of major events. That’s the “constant” part in this definition:

“Agile development uses feedback to make constant adjustments in a highly collaborative environment.” (Practices of an Agile Developer by Venkat Subramaniam and Andy Hunt)

The idea of correcting based on continuous feedback is key, but in order to do that successfully you’ll need to ensure that all the following are true:

All of your development and management practices generate continuous, meaningful feedback.

You are able to evaluate that feedback appropriately, in context.

You are able to change your code, your process, your team, and your interface to the rest of the organization and the customer in order to respond to the feedback.

That’s just the mechanical portion. To be agile, you need to start off with an agile mindset. Look at the agile values from the Manifesto:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

...and review the definition above. If you can proceed in a fashion that honors these values and adheres to that definition, and you’re able to respond as needed, then you’re headed in a more-or-less agile direction. You’ve got the basic model of agility in your head, and by asking questions and constantly reviewing what you’re doing in terms of this model, you’ll make progress.

Put it in Practice

That’s the theory, anyway. But theory does you no good unless you can put it into your practice. And practice means trying, failing, learning, and trying again.

Embrace the idea that there’s no one here to tell you what to do next. It might seem nice to have someone hold your hand at this point, but that’s a luxury few can afford. You’re on your own.

Familiar and comfortable ways of doing things may look attractive, but that’s a trap. Don’t fall for it. You’ll need to venture into the unfamiliar and uncomfortable, and lose a lot of mental baggage while you’re at it. Think of the XP maxim and ask yourself, what’s the simplest thing that could possibly work? What’s the least you could possibly get away with? That question works for code, process, documentation, training, QA, and more.

Suppose you need to accomplish a particular goal, XYZ. How can you accomplish that in a lightweight, low-ceremony, agile fashion, and still fully accomplish the goal?

For example, take testing (please :-).

You’ve started a new agile-based project and have been getting everyone up to speed on this new “agile stuff.” Now you’re tasked with bringing the QA staff into your fledgling environment to do testing. How can you do so in an agile fashion?

Let’s clarify what it is they’re doing—which is always a fine idea when starting out. We’re not talking about Unit Testing. Unit testing is mis-named; it’s a coding practice, not a testing practice. Yes, developers need to do it, and no, it doesn’t negatively impact your QA staff. So perhaps your development team is doing Test-Driven or Test-First Development. That’s great, they should be writing unit tests on an ongoing basis, keeping it continuous and episodic.

So now you need to bring QA into the fold to do more comprehensive testing, maybe focusing on acceptance testing, performance testing, other non-functional requirements, and so on. Are you going to wait for the end of a major release to give them code to test?

Of course not, that’s thinking of the event as a large, discrete episode—that violates the model. You don’t want episodic development, you want continuous development. Are you going to wait until the end of an iteration? Perhaps, but that’s still waiting and making a bigger event out of the situation than is needed.

Give QA the ability to pick up a testable version right off your continuous build machine. Every build that passes all the automated developer tests is eligible, and QA can grab the latest functioning code base and have a play. They have the opportunity to grab releases every hour, every half-hour, all day long. Or they can wait and grab it once when done (in a non-agile fashion), but the choice is theirs and they can change that choice at will.

Does it Work?

How does this simple example stack up to our mental model?

You’ve implemented a policy that’s lightweight and easy to maintain. You’re delivering value Continuously, and you’re delivering actual Working Software. Like the Hungry Consumer Model (see The Pragmatic Programmer), QA can make their own decisions about when and what to test. You can experiment with feedback to the development team based on both team’s needs. So you’re honoring Individuals and interactions over some rigid process. You’re able to Respond to Change easily, without affecting the development rhythm, as the two teams are loosely coupled.

Of course, things rarely go exactly as planned. That’s just how the world is. Maybe this scheme doesn’t quite work out for you. That’s great! Evaluate the feedback on where the problems are cropping up, and make constant adjustments to try and fix it. Just as with novice drivers, don’t overcorrect, or you could slam into oncoming traffic (metaphorically speaking). Tweak a little, check the feedback, and tweak some more. Even corrections to code or process shouldn’t be big, major events. Change a little, all of the time. And now you’re practicing agility.

Something to think about.

Andy is a Pragmatic Programmer, author of a bunch of books including Pragmatic Thinking & Learning, 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.

What’s a guru meditation? It’s an in-house joke from the early days of the Amiga computer and refers to an error message from the Amiga OS, baffling to ordinary users and meaningful only to the technically adept.

Send the editor your feedback or discuss the article in the magazine forum.

Way of the Agile Warrior

Velocity is not a Lever

by Jonathan Rasmusson

Velocity is a powerful tool for planning. The trick is to get managers to use it correctly.

Ever had that manager who says he’s read all the agile books, gets how agile projects like to flex on scope, and then tells you to go faster when the project starts to fall behind schedule?

Why do intelligent people do that?

While most managers understand intellectually that velocity isn’t a lever, many still reach for it at the first sign of pressure.

In this article I thought it would useful to remind ourselves what agile velocity is and why it’s such a good tool for planning.

What Is Velocity?

Velocity is a measure of how fast your team is going. It’s the rate at which your team turns features (user stories) into working software.

We measure it by sizing our user stories relative to each other and then summing in each iteration how many “points” of stories we’ve done.

Once you know how fast you can go, planning becomes a breeze. Simply extrapolate out your remaining work load and—voila!—you have your date.

What Makes It so Good for Planning?

Velocity is a powerful tool for planning because it’s measured. There is no wishful thinking.

No matter how hard someone wishes the project would be done by a certain date, if our measured velocity doesn’t support that, we have a pretty compelling case for changing the plan.

Now you’d think that this would be enough reason for most folks to update their plans. But reality (or what I like to call Microsoft Project reality) doesn’t always work that way.

Promises have been made. Short-term bonuses are on the line. Those facts, combined with the drama we get from the annual budgeting process, are some of the reasons why we often see so much dysfunction on software projects.

Many projects are just systematically built to ignore reality from the start.

Which is why velocity is so powerful. It enables teams to present the facts in an unambiguous, unemotional way.

No need to get excited. No need to get emotional. We’ve got a simple case of too much to do and not enough time—which is the perpetual state of any interesting software project.

How to Use It

Now, as good as velocity is at showing when a plan is diverging from reality, you’ve still got to set expectations right up front.

For one thing, you’ve got to make sure your customer understands that your initial high-level estimates are guesses—not commitments. That’s because we don’t know what our velocity is at the beginning of a project. We have to guess. So until we do three to four iterations worth of work, measure how long that takes, and then feed that back into the plan, we can’t say for certain when we expect things to be done. We can only guess.

The second thing I usually like to do when starting a new project is to start with a spartan version of whatever it is we are building.

The thinking here is that if we can’t build a stripped-down, bare-bones version of what we want with the time and money we’ve got, then there is no way in H E double hockey sticks that we’re gonna be able to afford the more rich one (that our customer may be looking for). Better to know that now than halfway through the project.

Thirdly, if you start your project and things aren’t going according to plan, you’ve got to deliver the bad news early. I don’t mean get all excited in iteration one if your velocity isn’t where it needs to be. I mean if after three or four iterations it becomes apparent that there is too much to do, you’ve got to be upfront and share that with your customer.

I know it’s not fun, and it goes against how the vast majority of our projects have been managed in the past (management by miracle) but your customer will appreciate it, and it’ll give them a chance to reset expectations on their end.

Velocity Is not a Lever

I wrote this article because it surprised me how after reading The Agile Samurai, and going through basic boot camp training, managers I know and love were still reaching for the velocity lever, expecting it to bail them out when it became apparent there was too much to do.

It’s not that the question was wrong. Teams should always be looking for ways to go faster. It’s just that when a team is doing everything right, and going as fast as they can, expecting to be able to pull a lever and suddenly go faster isn’t realistic.

Agile projects react the same way you and I do when faced with too much to do—they do less. And asking your team to go faster is like to asking them to grow taller. It might happen, but I wouldn’t plan on it.

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.

Pair Programming in a Flash

How to Pair, and Why

by Jeff Langr, Tim Ottinger

Jeff and Tim enjoy pairing so much that they want you to learn how to do it well. Here they present three cards on pairing from their Agile in a Flash card deck, covering its fundamental rules, a number of smells for you to sniff out, and guidelines for what you can do when a pair isn’t available.

Yes, we’re going to resurrect this contentious practice that divides programmers into oil-and-water camps. As much as some developers can’t stand the idea of pairing, we continue to find value and enjoyment in it, hence our insistence on revisiting it.

The Rules of Pairing

Most developers are at least familiar with the concept of pair programming, or pairing, but let’s quickly review the ground rules. They seem brief and simple:

We didn’t dream up these rules for Agile in a Flash just to fill out the letters from A through E! We learned these more-or-less original guidelines for pairing as part of extreme programming. More than a decade later, after observing many development teams adopt and apply them (or not!), we see little need for these core rules to change. We’ve also noticed that teams that attempt pairing and then subsequently give up have usually violated one or more of these rules.

Yes, rules are meant to be broken—particularly as you advance to the shu-ha-ri mastery phase of ri—but shu’ers and ha’ers should first obtain a solid understanding of pairing by following all of the rules. Here’s why.

All production code must be done by a pair. You build production code with a pair to avoid institutionalizing low quality code in your system. Once bad code gets in, it increases the cost of maintenance on your system. It’s also expensive to remove. You could use after-the-fact review to sidestep this #1 rule for pairing, but these reviews incur a high cost for what are typically only small improvements to the quality of the overall solution.

Both parties contribute to a solution. Pairing is a social activity, which is the primary reason it’s a challenging practice. Think of a pairing session as a collaborative design session during which you capture the result in code. You’re continually discussing the design—sometimes vocally, sometimes in code. You’re not taking turns watching someone else code—that would be pointless!

Change pairs frequently. Creating quality software requires socializing the code and solutions throughout the team. Stagnant pairings can result in solutions that are almost as bad as those produced by lone, unchecked developers. Try to take the time to swap in a new set of eyes for each solution. Not only will bringing on a newcomer bring the quality of any given solution up a notch, an effective context switch will also require an improvement in the code’s readability.

Develop at a comfortable workstation. A successful social activity must be comfortable for all involved. Discomfort will dissuade people from wanting to pair. Neither partner should be disadvantaged by the space, and adding large monitors and good chairs make a bigger difference than you’d expect.

End pairing when you get tired. Tired developers make more mistakes and derive less effective solutions, pairing or not. But a good pairing session sucks you in while time flies by, sometimes making it hard to notice that your brain is operating at less than optimal capacity.

Pairing Smells

Pairing Smell:

Unequal access

Relates to:

D, Develop at a comfortable workstation

What to Do:

Make sure that both developers can easily get to the keyboard and see the monitor clearly, without having to play musical chairs or perform acrobatics!

Pairing Smell:

Keyboard domination

Relates to:

B, Both parties contribute to a solution

What to Do:

Ensure that keyboard control passes easily between both programmers. Talk about what you’re doing, and learn to communicate in code as well as spoken word.

Pairing Smell:

Pair marriage

Relates to:

C, Change pairs frequently

What to Do:

It’s easy to fall into the habit of working with one or two people that you know better than the rest. Long-term, though, it’s far more valuable to be able to understand and collaborate with anyone on your team.

Pairing Smell:

Worker/Rester

Relates to:

A, All production code is produced by a pair

and:

B, Both parties contribute to a solution

What to Do:

We all get tired or frustrated with a task from time to time, but a better solution than sitting back and disengaging is to be honest and request a break or switch pairs.

Pairing Smell:

Second Computer

Relates to:

B, Both parties contribute to a solution

What to Do:

While some expert practitioners have found using two computers effective, it’s too easy for a second computer to be a distraction for the person not currently coding.

Pairing Smell:

“Everyone does their own work”

Relates to:

A, All production code is produced by a pair

and:

B, Both parties contribute to a solution

What to Do:

When a manager mandates individual accountability, the interest in “getting my stuff done” can result in me giving short shrift to “your stuff,” and thus reducing the overall quality of the system.

Pairing Smell:

“90% of work 90% done.”

Relates to:

B, Both parties contribute to a solution

What to Do:

Stories that aren’t completely implemented are a result of individual interest in getting their tasks done, and not in producing a combined solution.

Pairing Smell:

People who can't stand to program together

Relates to:

C, Change pairs frequently

What to Do:

Pairing or not, dissension on a team can devastate its ability to deliver. At least with pairing, the issue becomes obvious to any good coach or manager that intervention is required.

Pairing Smell:

Debates lasting more than 10 minutes without producing new code.

Relates to:

Well, this isn’t a direct violation of any of the ABC’s of pairing, but it does go against the core incremental nature of agile.

What to Do:

The more you learn to debate and demonstrate in code, the more you will be comfortable with taking demonstrably safe incremental steps (sometimes backward) to grow your system.

Sometimes the pair won’t notice any of these problems; a coach or any external observer may have an easier time of spotting and suggesting solutions.

When Not Pairing

“But Tim and Jeff, we can’t pair all the time. We have odd numbers. We have meetings where some people have to disappear for a while. Not everyone is in the office at the same time. And we really like to have good excuses for why we can’t pair.”

Each team and each day has its own challenges, but if you find yourself reaching for the excuses, perhaps your team isn’t really interested in pairing. If you are facing legitimate difficulties that prevent you from pairing, you’ll want to derive some ground rules for how to proceed. Producing production code alone should be a last resort, and if you check in to that resort, you need a backup contingency to deal with that new, potentially frightful code.

The “When Not Pairing” Agile in a Flash card recommends a number of useful tasks that can accelerate the whole team. Occasional breaks from pairing allow your team to put effort into improving things in your environment that might otherwise degrade. Build systems are an obvious target in most teams—how many times have you cursed about the complexity of the build, or the fact that it spews fifty pages of mostly worthless material that buries questionable exceptions?

Not everyone wants to pair 100% of the time, either. Jeff looks forward to having some time each week—even if it’s only a couple hours—to do things like play around with alternate solutions for an upcoming story, to experiment with a new API, or to clean up tests written earlier.

Programming solo? Just remember that there are always plenty of things you can do that will benefit the rest of the team.

But Why?

We pair because we enjoy it. Recently, Jeff moved into a development role where he found himself programming alone in an office for the bulk of the day. That’s nothing new—he spent the first 18 years of his career not pairing and often isolated in a cube or office. Now that he’s returned to solo development, though, he yearns for the social interaction of a pair and the ability to immediately bounce ideas and questions off someone else. It’s not that he’s incapable of developing good software on his own, but he feels much more effective when working as half of a programming pair.

Is our enjoyment enough to justify the cost of doubling up developers? Tim’s recently been concerned that we spend too much time talking about personal enjoyment in the office space—no doubt a reaction to some folks’ insistence that “this is all serious stuff and money we’re talking about. The business doesn’t care whether or not you’re happy, you should just be happy to have a job.” Harumph. Burnout, employee turnover, and the low-quality product of disgruntled workers is something the business should be dearly concerned with.

In any case, there are many reasons to embrace pairing: Benefits can accrue for programmers, their managers, and for the business as a whole. We’ll talk about those benefits of pairing next month.

Jeff Langr has been happily building software for three decades. In addition to co-authoring Agile in a Flash with Tim, he’s written another couple books, Agile Java and Essential Java Style, contributed to Uncle Bob’s Clean Code, and written over 90 articles on software development. Jeff runs the consulting and training company Langr Software Solutions from Colorado Springs.

Tim Ottinger is the other author of Agile in a Flash, another contributor to Clean Code, a 30-year (plus) software developer, agile coach, trainer, consultant, incessant blogger, and incorrigible punster. He writes code. He likes it.

Send the authors your feedback or discuss the article in the magazine forum.

Practical Mock Advice

Mocks? Really? Yes, really.

by Zach Dennis

Opinions about mock objects are not hard to find. Rarer is the kind of solid practical advice on using mocks that Zach offers here.

Mocks have long been a source of question and confusion for a lot of people, myself included (see "Mocks? Really?"). Years ago I embarked on a journey to make sense of mocks and add them to my toolbox. I had almost entirely forgotten about this voyage when I was in Charlotte a few weeks ago eating lunch with Jim Van Fleet and Matt Overstreet and Jim asked, “When do you use mocks?” It started me thinking about the legendary tales of mocks.

Mock objects, as you no doubt know, are simulated objects designed to mimic the behavior of real objects for testing purposes. Mocks are also a subject of software development controversy and folklore. From the folklore surrounding mocks, you might think that clarity and mocks are mutually exclusive. We’ve likely all heard a story or two of how interaction-based testing with mocks changed lives. Sometimes it’s a story of change for the better and sometimes for the worse. So which is it, folklore? Better or worse? Are mocks useful tools to employ in our everyday pursuit of building useful software? Or are they a failed experiment that we should walk away from and not look back? These are the questions I asked in my journey, and heard others ask.

As with most things, the usefulness of mocks isn’t a matter of black or white. Mocks are just another tool, and using them under the right circumstances is what makes them valuable. Just as using a cross-cut saw to hammer nails won’t provide much value in building a house, using mocks in every unit test won’t provide much value in building software.

When to Mock

So it’s not a question of whether to use mocks, but of when it might be useful to use them. Over the years I’ve seen cases where mocks were appropriate and where they were not.

Consider this example from when I was implementing a caching mechanism for a Ruby on Rails library. One behavior in the library worked like this: after a method was called on an object which delegated to another object the result would be cached and used for subsequent calls. To ensure this functionality worked as expected I used a mock. It was the simplest technique for testing the caching behavior. More on this later.

In contrast, consider this example. We were working on an email parser which pulled out the original sender and receiver from a forwarded email. We wanted this to be represented in the same way we handled the sender and receiver of a non-forwarded email. It’s common for emails to not only include the email address, but also a display name and potentially a mailto link. In the implementation we ended up with two separate objects: an EmailParser and an EmailAddress. However, in our test we didn’t use mocks to verify that the EmailParser constructed EmailAddresses. Instead we wrote the examples in our test to expect a particular API. We just happened to use an EmailAddress object to satisfy the API we expected. Using a mock here would have worked, but it would have brought along some additional trade-offs we didn’t feel were necessary for driving this behavior.

I’ve described these cases in some detail because it all comes down to the details. If a few of the details in these situations had been different it’s likely our decision to use or not use mocks would have been different. Okay, but why, exactly? Is there some general principle that can help us decide when to use mocks?

The most relevant guideline I’ve found is in something that Dan North said about Behavior Driven Development (BDD) in The RSpec Book: that a characteristic of doing BDD is recognizing that software is “all about behavior.” This same idea has tremendous power when used as a guideline for using mocks. If caring about an implementation detail doesn’t help you drive or ensure the behavior of your code, then you shouldn’t use a mock. This simple qualifier will save you and future maintainers of your application’s test suite a lot of time and frustration.

I want to expand on that with some specific examples, but before we dive in, let’s make sure we are using our words in the same way.

What’s a Mock?

The term “mock” refers to an object that is used to set expectations on, which are later verified. If the expectations are not met, then a mock raises an exception indicating failure.

A mock expectation refers to a method that is expected to be called on a mock. These expectations often include expected method arguments. Other properties of expectations can include indicating the number of times the method should be called, which may include never, as well as a return value.

How Do You Use a Mock?

You’ll find more detailed documentation for how to use a mock in your mocking library’s documentation, but should you not have that handy, here’s a quick overview that will put us on the same page.

A basic RSpec example using a mock:

| describe "DogWhisperer#command" do
| it "has the dog obey the command" do
| dog = mock("Dog")
| cesar_millan = DogWhisperer.new dog
| dog.should_receive(:obey)
| cesar_millan.command
| end
| end

According to this example, when Cesar Millan commands the dog, the dog obeys. If the dog doesn’t obey, the example will fail. If the dog does obey, the example will pass. You’ll notice that there is no code to verify the expectation. This is because most modern mocking libraries do this for you after each test run.

To see how this example can be satisfied, here’s a passing implementation:

| class DogWhisperer
| def initialize(dog)
| @dog = dog
| end
| def command
| @dog.obey
| end
| end

Our code does just what the example specified. When Cesar commands the dog, the dog obeys.

Mock Expectations Outside of a Mock Object

We just used a dedicated mock object. Now let’s expand our understanding of how mock expectations can be used. In more dynamic languages like Ruby, an expectation can be set on any object, not just mock objects.

An example is worth a thousand paragraphs so here’s an updated RSpec example to use a real Dog object instead of a mock(“dog”):

| describe "DogWhisperer#command" do
| it "has the dog obey the command" do
| dog = Dog.new
| cesar_millan = DogWhisperer.new dog
| dog.should_receive(:obey)
| cesar_millan.command
| end
| end

Here we used an actual Dog object instead of creating a mock(“dog”). This technique is often referred to a partial mocking, meaning that we’re using mock expectations outside of a dedicated mock object. This allows us to use real objects from our own applications and only mock out expectations that we care about.

Okay, hopefully this primer has been enough to build a shared understanding for the concepts of a mock. Now let’s look at Jim’s question. Remember Jim’s question?

When Do You Use Mocks?

Generally, there is one overarching reason for why you would use a mock. That reason is this: You care about an implementation detail in your code. And when do you care? You care when it drives behavior.

Let’s look at three specific examples where mocks have routinely been helpful.

Third-party/external systems integration

Caching implementations

Coordinator objects

The use of mocks is by no means limited to this list, but these three examples represent types of situations where I’ve found mocks valuable.

Third-Party/External Systems Integration

Mocks are a great tool to use when writing tests around third-party/external systems integration in your application. It frees your unit tests from depending on the external system while allowing you to verify the application’s behavior for integrating with that system.

The primary trade-off with external systems is that for a more reliable unit test suite around how your application behaves, you get less coverage on integrating with the external application. This applies almost universally to unit tests only since unit tests are where you want to isolate sets of behavior in order to ensure that they are working as expected. However, unit tests without integration tests don’t cut the mustard. You would be well served to have at least an integration test that integrates with the external system without the aide of mocks.

Consider the DogWhisperer example. Imagine the dog.obey call connected to a web-service. Each time dog.obey gets called, that would need to connect to dog.com, authenticate as the proper dog, and then issue the obey command. This takes time to connect, handshake, send our request, and then receive a response. What if dog.com was down or simply timed out? We’d end up with really slow tests, a lot of potentially incorrect failures, and a lot of time spent investigating these failures.

Mocks serve us well here. They disconnect our code from being affected by things that are out of our control. Removing unnecessary variables allows our code to be repeatably and consistently exercised. We can be more confident that our code is working—or that when it breaks, it is actually broken. And we can have an integration test that verifies actual integration. We may still get a false positive, but we’ve minimized the number of failures to an extremely small number. Those failure(s) can quickly be investigated to determine if the integration broke or if all is well.

A secondary benefit of using mocks is that you get faster tests. This is a nice side effect of connecting to fewer external systems and resources and can be a great thing to keep in mind with your testing strategy. Also, this speed benefit isn’t limited to testing third-party/external systems. It exists in any situation where mocks can be used. Be cautious though: speed is not the most important thing—far from it, in fact. Mocks make your tests go extremely fast, but that kind of fast can be like putting a Ferrari on blocks and punching the gas.

If it comes down to having slower, meaningful tests or just fast tests, always choose slow and meaningful. If a meaningful test is slower than you’d like, but you’re out of ideas for the moment, write it down and come back to it later. I always find it helpful to talk it through with other developers.

In general, mocks provide a good value when dealing with third-party/external systems integration.

Caching, an Example of Caring about Implementation Details

Object oriented programming is all about encapsulation and information hiding. Conventional wisdom suggests that you shouldn’t care about the details. I wholeheartedly agree with this as a general rule of thumb. But experience has shown that sometimes you do care.

Consider the caching library example from the opening paragraphs of this article. I knew how I wanted the cache to work, but I needed a way to verify that it was working properly. Without mocks, this would have been difficult.

Here’s the RSpec example for the case we’ve been talking about:

| class ScoreboardPresenter < CachingPresenter
| presents :scoreboard
| end
| describe CachingPresenter do
| describe "delegating method calls to the object being presented" do
| it "caches implicitly delegated methods" do
| scoreboard = mock("scoreboard")
| presenter = ScoreboardPresenter.new :scoreboard => scoreboard
| scoreboard.should_receive(:results).at_most(1).times
| presenter.results
| presenter.results
| end
| end
| end

This example is short, concise, and clear. Heck, it’s readable! There was no need to involve file systems, databases, or any other external resource. A mock was all we needed.

More often than not you won’t care about the implementation details; you’ll care about the behavior. In situations where caring about an implementation detail helps drive and verify the behavior, mocks can be a great tool. This caching illustration is an example of that.

Coordinator Objects

Coordinator objects are at the heart of design patterns like Model-View-Controller and Model-View-Presenter. You may recognize them as the controllers in Rails applications and presenters in applications that follow the Presenter-First design pattern. They can commonly be spotted by their names as they routinely end in -Controller, -Manager, or -Presenter. They are coordinator objects because they are rarely responsible for doing any heavy lifting and are instead tasked with coordinating the interactions between two components.

To illustrate a coordinator object in practice, consider a Rails controller. Its job is to take an incoming web request and hand it off to the appropriate object to do the work. Once the work has been done, it’s responsible for initiating the communication back to the requesting web client. At no point should the controller become the place where all of the business logic and work takes place. Back in 2006 Jamis Buck coined the term Skinny Controller Fat Model which reinforces this concept that a controller is a coordinator and not a doer.

In the Presenter-First world, the presenter plays a similar role to the Rails controller. It listens to the events from the view and makes the appropriate calls on the models. Likewise, when models trigger events, the presenter listens and calls the appropriate methods on the view. The presenter exists to manage proper interactions between the views and models. No more, no less.

In traditional TDD you test-drive these coordinator objects into existence, often times using a mock to ensure the interactions being coordinated are what you want. A benefit of this is that it guides you to drive the APIs you want on the objects being coordinated and it helps keep unnecessary logic out of the coordinator. On the flip side, paying so much detailed attention to a coordinator takes a lot of time and care. I’m not convinced it’s always worth it.

Consider when the design benefit is most effective: when you aren’t experienced with making the kinds of design decisions which lead to skinny, narrowly focused coordinator objects. If that’s you, then the traditional TDD route with mocks can be a very good thing to practice. And by practice, I literally mean a 15–30 minute practice session. Through practice you experience pain points, have an opportunity to challenge your design thinking, rethink the design, and try new things. It is a catalyst to making good designs and avoiding painful ones. Out of it you’ll even begin to naturally apply principles like single responsibility and separation of concerns.

Deliberate practice with mocks and coordinator objects will help you to grow as a developer: of that there is no doubt. But on a daily basis while you’re performing the act of building software there are very real trade-offs with strictly following the traditional TDD route.

For instance, testing every Rails controller in isolation with mocks takes time and care to create and maintain. As the application evolves, you commonly find yourself making changes to meaningful tests and then also having to go back and make a change to a controller test. But why? To what benefit?

Coordinator objects like controllers are driven into existence because you need to hook two areas of your application together. In Rails applications, you usually drive the controller into existence using a Cucumber scenario or some other integration test. Most of the time controllers are straightforward and not very interesting: essentially a bunch of boilerplate code to wire your app together. In these cases the benefit of having isolated controller tests is very little, but the cost of creating and maintaining them can be high.

A general rule of thumb is this: If there are interesting characteristics or behaviors associated with a coordinator object and it is not well covered by another test, by all means add an isolated test around it and know that mocks can be very effective.

As Albert Einstein once said, “Make everything as simple as possible, but not simpler.” This applies not only to production code, but also test code. Therefore I want simple, concise, meaningful, and valuable test code. If another test provides adequate behavioral coverage that communicates well, I see no reason to make more work for myself or future maintainers of the code.

Summary

Mocks are just tools. No different than stubs, factories, or fixtures. What makes them valuable is using them in situations where they are effective. In order to be effective, they need to help drive and/or verify behavior of your application. When they are doing that, you will receive the most value out of the mocks, short-term and long-term. If they’re not doing that, get rid of them.

As we saw with third-party/external systems, integration mocks can be very effective in ensuring that our code responsible for integrating is behaving as expected. The value received by knowing details about the integration code outweighs the risk of not knowing.

In the caching example, we saw a case where caring about an implementation detail helped drive and verify behavior. Most of the time you won’t care about implementation details, but there are times when it makes sense. In those times mocks can be very helpful.

Lastly, we looked at how coordinator objects could benefit from and be impaired by the use of mocks. The ability to discern when to use isolated tests with mocks around coordinator objects can mean good, effective test coverage rather than something unnecessarily costly.

You may have noticed that the central theme throughout this article really isn’t mocks at all. It’s behavior. To quote Dan North again, a characteristic of doing BDD is recognizing that software is “all about behavior.”

So take this as a parting guideline for using mocks: a mock should help drive or ensure behavior of your code. This simple rule can go a long way.

Zach Dennis is a co-author of The RSpec Book and a co-founder and fellow human at Mutually Human Software, an expert custom software strategy and design consultancy in Grand Rapids, Michigan. He has been enjoying Ruby for nearly eight years and has contributed to several projects such as Ruby’s standard library documentation, Ruby on Rails, and RSpec. In his spare time, Zach loves spending time with his family, continuously learning, playing music, and running continuousthinking.com.

Send the author your feedback or discuss the article in the magazine forum.

Language Lessons

A Couple Dozen Programming Language Articles in PragPub

by Michael Swaine

You should learn a new language this year. Maybe we can help.

Somewhat surprisingly, C++ was the subject of a moderately interesting discussion recently on our Yahoo group. The topic was “What’s up with C++ (books)?” and the poster pointed out that there are lots of people programming in C++ and there are book-worthy things happening in the C++ world, like the prominence of the Boost libraries, but that production of new books on C++ topics practically stopped about six years ago.

You probably aren’t surprised at this. As our own Dave Thomas said in the discussion, we “don’t we have C++ books under development... [b]ecause no one asks for them, and we’re here to serve the readers.” But if lots of people are programming in C++ and there are developments in C++-related tools that would justify new books, why aren’t those programmers asking for those books?

As Jared Richardson points out, some programmers read books, go to conferences, read blogs, and stay up to date on developments in their field, while some programmers tend to get their knowledge by talking to others on their team and mostly just spend their time grinding out code. C++ programmers, he suggests, are in the second camp.

I’m guessing that you’re in the first camp.

In The Pragmatic Programmer, Andy and Dave suggest as a goal that you learn at least one new language every year. Seeing how different languages encourage different approaches to the same problems will expand your own problem-solving bandwidth. Andy and Dave are talking there to the programmers in the first camp, so they’re talking to you. And I’m guessing that you already have that goal of learning a new language every year.

But real immersion in a new language is quite a plunge. If you want to dip your toe in the water before diving into the stream, we can help with that. The fact that every article of every issue of PragPub is available online for free means that we can facilitate your toe-dipping. The articles range from John Shade’s lightweight take on Google’s Go language and a quiz in which you are asked to identify languages based on snippets of code to serious discussions of languages from Clojure, Scala, Python, Ruby, and Objective C to HTML5, SASS, JavaScript, and CoffeeScript. Here, then, is a guide to every article on a programming language published in PragPub to date.

Why Clojure?: An Interview with Rich Hickey

by Rich Hickey in PragPub July 2009

Rich Hickey created Clojure, a modern dialect of Lisp that targets the JVM. In this PragPub interview, Rich explains what that means to you.

When Things Go Wrong: Clojure’s Exceptional Handling of Exceptions

by Stuart Halloway in PragPub July 2009

As Stuart demonstrates in this deep immersion in Clojure coding, one of Clojure’s strengths is how it shines when things go wrong.

The Quiz: This Month: A is for APL

by Dave Thomas in PragPub July 2009

A monthly diversion at least peripherally related to programming. You’ll find the solution here.

Writing an iPhone App: Thinking Different(ly) about the iPhone

by Chris Adamson in PragPub August 2009

Developing iPhone apps is in some ways remarkably like writing desktop apps—and in many ways jarringly different.

Language Workbenches: Is This the Era of the DSL?

by Michael Swaine in PragPub October 2009

DSLs rule! Now if only they weren’t so unruly.

Shady Illuminations: Is Google’s New Language a Goer?

by John Shade in PragPub December 2009

Google releases a new programming language and John Shade finds a bit of Python in it.

Much Ado About Nothing: Gazing into the Abyss of Ruby’s nil, amongst Null Objects, Ghost Methods, and Black Holes.

by Paolo Perrotta in PragPub January 2010

Paolo plumbs the depths of nothingness to show the power of metaprogramming in Ruby.

Better CSS with Sass: Make Your Website Stylesheets Sassy

by Brian Hogan in PragPub February 2010

Brian shows off some of the magic of Sass, a DSL for generating stylesheets.

JavaScript: It’s Not Just for Browsers Any More: Three Significant Events in 2009 Changed the JavaScript Landscape

by Jason Huggins in PragPub March 2010

Node.js is a toolkit for writing high-performance network servers in JavaScript. And it’s events all the way down.

The Bruce Tate Interview How Do You Dive Deeply into Ruby, Io, Prolog, Scala, Erlang, Clojure, and Haskell in One Book?

by Bruce Tate in PragPub May 2010

Behind the scenes with the author of Seven Languages in Seven Weeks.

Agile Microsoft: An Introduction to ASP.NET MVC

by Jonathan McCracken in PragPub June 2010

Microsoft’s Model-View-Controller web presentation framework is being called “Rails for .NET.”

Why ASP.NET MVC?: An Interview with Phil Haack of Microsoft

by Phil Haack in PragPub June 2010

We chat with the Project Manager for the ASP.NET MVC project at Microsoft.

Not Quite New in iOS 4: Three New-to-You Features for iPhone Developers

by Daniel Steinberg in PragPub July 2010

Three unsung developer features of iOS 4 will make your life easier and change your code dramatically: blocks, gestures, and properties without ivars.

Great Expectations: Better Testing Through DSLs with Ruby and Scala

by Paul Butcher in PragPub August 2010

Improve your tests with custom expectations

Page Objects in Python: Automating Page Checking without Brittleness

by Adam Goucher in PragPub August 2010

The Page Object pattern is the key to implementing smart automated checks. Here’s how Python programmers can make use of it.

HTML5: Accessibility For All: Accessibility, Unobtrusiveness, and Progressive Enhancement with HTML5

by Brian Hogan in PragPub October 2010

One in every ten people in the world has some sort of disabiliy. That’s 650 million potential users of your software, and 650 million people you should think about when developing web sites.

Getting Clojure: Extending Java Classes Using Proxy

by Gregg Williams in PragPub November 2010

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.

Chad Fowler on Ruby: An Interview with a Ruby Pioneer

by Chad Fowler in PragPub December 2010

A legend in the Ruby community shares his recollections and insights and hopes, from the early days of Ruby enthusiasts to the future of Ruby on silicon and Ruby for phones.

What’s New in Ruby 1.9.2: If you’re not using it, you should be.

by Dave Thomas in PragPub December 2010

It’s been a long time coming, but we finally have a worthy successor to Ruby 1.8. Fast, fully featured, and fun, Ruby 1.9.2 should be your Ruby of choice.

Three Bundler Benefits: Bundler Gives You Pay-as-you-go Gem Management

by Paolo Perrotta in PragPub December 2010

Why you should start using Bundler to manage your Ruby gems right now.

New Series: Everyday JRuby Part 1: Writing a Plugin

by Ian Dees in PragPub December 2010

Wherein Ian begins a series of articles on using Ruby on the JVM to solve everyday problems.

Grokking Pattern Matching and List Comprehensions: Two Language Features that Rock

by Bruce Tate in PragPub January 2011

Bruce explores two powerful features of modern programming languages that can make your code more beautiful and you more productive.

Everyday JRuby Part 2: Sharing Your Software

by Ian Dees in PragPub January 2011

Wherein Ian creates a simple game and then shows you several ways to deploy it.

Punk Rock Languages: A Polemic

by Chris Adamson in PragPub March 2011

In an era of virtual machines and managed environments, C is the original Punk Rock Language.

A CoffeeScript Intervention: Five Things You Thought You Had to Live with in JavaScript

by Trevor Burnham in PragPub May 2011

Trevor takes us on a tour of some of the ways this hot new language improves on JavaScript.

When Did That Happen?

How Maurice Wilkes Wrote the First Book on Computer Programming

by Dan Wohlbruck

Wilkes wrote, “I had other objects in view besides solving problems in electronic engineering. I wanted as soon as possible to have an electronic computer and to experiment with the writing of programs to solve real problems.”

Maurice Wilkes was born on June 26, 1913, in England. He passed away just a few months ago, on November 29, 2010. He was, among many other things, co-author of the first book about computer programming titled The Preparation of Programs for an Electronic Digital Computer and published in 1951. Thus, 2011 marks the 60th anniversary of books about programming computers.

How Maurice Wilkes Built the First Off-the-Shelf Computer

After studying mathematics and physics at Cambridge University, Wilkes served England during the war years. When he returned to Cambridge in 1945, Wilkes was named the acting head of the University’s Mathematical Laboratory. Wilkes’ interest in analog computing machines and his reading of von Neumann’s famous First Draft memo led him to attend a series of lectures at the Moore School in Philadelphia about electronic computers. Once back at Cambridge, Wilkes became the Laboratory’s permanent director and he assembled a small team, arranged funding, and began the construction of the world’s first operational electronic, digital computer, the EDSAC (Electronic Delay Storage Automatic Calculator).

In May, 1949, the EDSAC went operational. This stunning achievement was made possible because Wilkes’ design was less ambitious than his American counterparts and used components and technologies that were proven and already in use. About the off-the-shelf computer, Wilkes wrote, “I had other objects in view besides solving problems in electronic engineering. I wanted as soon as possible to have an electronic computer and to experiment with the writing of programs to solve real problems.”

How He Got the Money

The funding that allowed Wilkes to accelerate the development of the EDSAC had come from an unlikely source, the Lyons Tea Company. Two Lyons’ employees had also traveled to America to investigate the degree to which office procedures were being automated. They visited with Aiken at Harvard, they saw the ENIAC, and they spoke with personnel at the Prudential Insurance Company who were planning an entirely new way of processing information. The Lyons’ team wrote of that particular interview, “We believe that we have been given a glimpse of a development which will, in a few years time, have a profound effect on the way in which clerical work is performed.”

The team recommended, and the Lyons’ Board approved, a contribution of $8,300 to Cambridge to fund Wilkes’ new computer. The money came with strings attached, however. It was understood that Lyons Tea Company would use EDSAC as a model to build its own machine. Wilkes accepted, EDSAC was built, and Lyons proceeded with LEO, the Lyons Electronic Office. LEO ran the first commercial computer program in November, 1951. LEO was such a boon to England’s post-war economy that it was demonstrated to Her Royal Highness, Princess Elizabeth, the current Queen of England.

During the 1950s, LEO and its later versions the LEO II and LEO III, were the preeminent mainframe computers in England and Europe. In 1954, the Lyons Company formed LEO Computers Ltd. to build and market the mainframes. Inevitably, they were overtaken by their American competitors and by 1968, after a series of mergers, the company became International Computers Limited (ICL) and the LEO was no more. But I digress...

How Wilkes Launched Computer Science as an Academic Discipline

The photo illustrating this article is of the Cambridge University Computer Laboratory—the original, not the new building named for Bill Gates. This is where the world’s first practical stored program computer was built and operated and where the world’s first computer science course was taught in 1953, all under the direction of Maurice Wilkes.

Oh, and then there was the book.

Wilkes also wrote the first book about computer programming, The Preparation of Programs for an Electronic Digital Computer. The book actually had three co-authors. As well as Wilkes, David J. Wheeler and Stanley Gill were contributors. Gill was a “vacation” student at Cambridge who helped develop the EDSAC, and Wheeler wrote the first program for the EDSAC.

From the MIT press description of the book:

“The authors were principle contributors to this system, which they describe in detail in this first, practical text on computer programming. The book presents the elegant symbolic notation and coding for the large subroutine library that provided the building blocks for an array of programs. At the time, these concepts were at the leading edge of programming virtuosity, foreshadowing the powerful systems that were developed later.”

Wilkes’ Legacy

After EDSAC, Wilkes became interested in microprogramming and he is credited with pioneering its use within the CPU.

Upon his death last November, the Guardian wrote the following in Wilkes’ obituary:

“Sir Maurice Wilkes, who has died age 97, was the most important figure in the development of practical computing in the UK. Not only did he lead the development of EDSAC, the first stored-program digital computer to go into service in the 1940s, he and his colleagues at Cambridge University also made significant contributions to software development, and built one of the first high-speed distributed computing networks, the Cambridge Ring. His vision was less about producing bleeding-edge designs than about developing machines that could reliably do calculations for the university’s scientists and engineers—people like himself. In the early 1950s, EDSAC, the Electronic Delay Storage Automatic Calculator, was the basis for the world’s first business computer, LEO (the Lyons Electronic Office), which was used to run the operations of the eponymous tea-shop company.”

It all started in June, 1913—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.

Like this article? Hate it? Want to remind us about Ada Lovelace’s translation and expansion of Luigi Menabrea’s notes on Charles Babbage’s Analytical Engine, and make the case that Ada really wrote the first computer book? Send the author your feedback or discuss the article in the magazine forum.

Calendar

Author sightings, partner events, and other notable happenings.

Author Appearances

Jun 5–6, Better Software Conference/Agile Development West, Las Vegas, NV

Agile Architecture workshop with Rebecca Wirfs-Brock

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

Jun 6–10, Better Software Conference/Agile Development West, Las Vegas, NV

Speaking

Pragmatic Programmer Andy Hunt

Jun 7, Better Software Conference/Agile Development West, Las Vegas, NV

Agile Program Management for Agile and Non-Agile Projects

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

Jun 7, Mongo NYC, Ney York, New York

TBD

Brendan McAdams, author of the forthcoming MongoDB: A Quick Start Guide

Jun 7–8, agical, Stockholm Sweden

“TDD in Clojure”

Brian Marick, author of Programming Cocoa with Ruby and Everyday Scripting with Ruby

Jun 8–9, Better Software Conference/Agile Development West, Las Vegas, NV

“Faltering Projects: Getting Them Back on Track”

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

Jun 10–12, Central Ohio Software Symposium, Columbus, OH

“Hello! Groovy,” “Grails: Bringing Radical Productivity to the JVM,” Apprenticeship Birds of a Feather

Dave Klein, author of Grails: A Quick-Start Guide

Jun 13, SPA Conference, London, England

Workshop: “Improving Trust in Teams”

Rachel Davies, co-author of Agile Coaching

Jun 16–18, Ruby Kaigi, Tokyo, Japan

Keynote

Pragmatic Programmer Dave Thomas

Jun 19–23, Ignite Outsourcing, Tel Aviv, Israel

“Making Geographically Distributed Agile Work,” “Agile Program Management,” and “Agile for Executives: A Half-Day Briefing”

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

Jun 21–24, Open Source Bridge, Portland, OR

“How 5 People with 4 Day Jobs in 3 Time Zones Enjoyed 2 Years Writing 1 Book” (solo) and “Give a Great Tech Talk” (with Josh Berkus)

Ian Dees, author of Scripted Gui Testing with Ruby

June 27–28, GR8 Conference, Minneapolis, MN

Grails Workshop

Dave Klein, author of Grails: A Quick-Start Guide

June 28, Better Software 2011, Florence, Italy

“Java Viene da Marte, Ruby da Venere” (in Italian)

Paolo Perrotta, the author of Metaprogramming Ruby

July 12–15, UberConf, Denver, CO

“Uber Groovy,” “Grails: Bringing Radical Productivity to the JVM,” Apprenticeship Birds of a Feather

Dave Klein, author of Grails: A Quick-Start Guide

July 18–21, Pragmatic Studios, Reston, VA

iPhone Studio

Daniel Steinberg, co-author of iPad Programming: A Quick-Start Guide for iPhone Developers and author of Cocoa Programming: A Quick-Start Guide for Developers

July 25–29, OSCON, Portland, OR

“Projects and Community With Github”

Andy Lester, author of Land the Tech Job You Love

Aug 11, Agile 2011, Salt Lake City, UT

“The Only Agile Tools You'll Ever Need”

Jeff Langr, co-author of Agile in a Flash (with Tim Ottinger) and Agile Java

Aug 12–13, Cocoa Conf, Columbus, OH

Keynote: “Your Code: The Director’s Cut” plus sessions “Mac OS X for iOS Developers” and “The Key to Blocks”

Daniel Steinberg, co-author of iPad Programming: A Quick-Start Guide for iPhone Developers and author of Cocoa Programming: A Quick-Start Guide for Developers

Aug 12–13, Cocoa Conf, Columbus, OH

“Introduction to AV Foundation” and “Advanced AV Foundation”

Chris Adamson, author of iPhone SDK Development

Aug 22–25, Pragmatic Studios, Denver, CO

iPhone Studio

Daniel Steinberg, co-author of iPad Programming: A Quick-Start Guide for iPhone Developers and author of Cocoa Programming: A Quick-Start Guide for Developers

O’Reilly Events

June 14–16, O’Reilly Velocity Conference, Santa Clara, CA

Velocity: “Web performance and operations, once the secret sauce of elite Web companies, are now essential ingredients in every company’s online strategy. The business value of ‘fast and reliable’ has been established, and stakeholders are demanding more and better results now. Get the skills and tools you need to master this ever-shifting, increasingly complex domain at Velocity.”

July 25–29, OSCON, Portland, OR

O’Reilly Open Source Convention: “Join today’s open source innovators, builders, and pioneers as they gather at the Oregon Convention Center in Portland, Oregon, to share their expertise and experience, explore new ideas, and inspire each other.”

USENIX Events

What’s coming from our USENIX friends.

Jun 14, HotCloud '11, Portland, OR

3rd USENIX Workshop on Hot Topics in Cloud Computing: Part of 2011 USENIX Federated Conferences Week. “Back for 2011, USENIX is combining established conferences and new workshops into a week of research, trends, and community interaction.”

June 14, HotStorage '11, Portland, OR

3rd USENIX Workshop on Hot Topics in Storage and File Systems: Part of 2011 USENIX Federated Conferences Week. “Back for 2011, USENIX is combining established conferences and new workshops into a week of research, trends, and community interaction.”

June 14, WIOV '11, Portland, OR

3rd Workshop on I/O Virtualization: Part of 2011 USENIX Federated Conferences Week. “Back for 2011, USENIX is combining established conferences and new workshops into a week of research, trends, and community interaction.”

June 15–17, USENIX ATC '11, Portland, OR

2011 USENIX Annual Technical Conference: Part of 2011 USENIX Federated Conferences Week. “Back for 2011, USENIX is combining established conferences and new workshops into a week of research, trends, and community interaction.”

Jun 15–16, WebApps '11, Portland, OR

2nd USENIX Conference on Web Application Development: Part of 2011 USENIX Federated Conferences Week. “Back for 2011, USENIX is combining established conferences and new workshops into a week of research, trends, and community interaction.”

Jun 20–21, TaPP '11, Heraklion, Crete, Greece

3rd USENIX Workshop on the Theory and Practice of Provenance: “The workshop may cover any topic related to theoretical or practical aspects of provenance, including but not limited to: provenance in databases, work flows, programming languages, security, software engineering, or systems; provenance on the Web; or real-world applications of or requirements for provenance.”

Jun 28–Jul 1, MobiSys 2011, Washington, DC

The 9th Annual International Conference on Mobile Systems, Applications, and Services: “MobiSys 2011 seeks to present innovative and significant research on the design, implementation, usage, and evaluation of mobile computing and wireless systems, applications, and services. It is jointly sponsored by ACM SIGMOBILE and the USENIX association in cooperation with ACM SIGOPS.”

July 11–12, APSys 2011, Shanghai, China

The 2nd ACM SIGOPS Asia-Pacific Workshop on Systems “will be a forum for systems researchers and practitioners across the world to present their work in computer systems (broadly defined) and for locals in Asian/Pacific region to meet, interact, and collaborate with top researchers in the field.”

Aug 8–12, USENIX Security ’11, San Francisco, CA

The 20th USENIX Security Symposium. “USENIX Security ’11 brings together researchers, practitioners, system administrators, system programmers, and others interested in the latest advances in the security of computer systems and networks.” Not to mention a bunch of collocated conferences: 2011 Electronic Voting Technology Workshop/Workshop on Trustworthy Elections, 4th Workshop on Cyber Security Experimentation and Test, USENIX Workshop on Free and Open Communications on the Internet, 5th USENIX Workshop on Offensive Technologies, 2nd USENIX Workshop on Health Security and Privacy, 6th USENIX Workshop on Hot Topics in Security, and Sixth Workshop on Security Metrics,

Other Happenings

June

In this month in 2011, Facebook will move into former Sun Microsystems digs in Menlo Park, CA.

June

In this month in 1957, computer science legend Donald Knuth published his first article, “Potrzebie System of Weights and Measures,” in Mad Magazine.

June 1

Tim Paterson, whose operating system made Bill Gates a jillionaire, is 55.

June 3

One year ago today, Toro Iwatani was recognized by Guiness World Records for his game Pac-Man having the most coin-operated arcade machines installed worldwide: 293,822.

June 8

Tim Berners-Lee is 56.

June 23

Vint Cerf is 68.

June 23

Mathematica is 23.

June 28

Firefox co-creator Dave Hyatt is 29.

June 30

Lynne Jolitz is 50.

July 2

Gordon Letwin, one of first dozen Microsoft employees and lead Microsoft architect on OS/2, is 59.

July 5

Linguist Victor Yngve, creator of COMIT, the first string processing language, is 91.

July 6

Adi Shamir, the S of the RSA encryption algorithm, is 59.

July 7

Smalltalk co-creator Adele Goldberg is 66.

July 8

Weddings of titled Britons being much in the news recently, we thought we’d mention that on this day in 1835, Ada Augusta Byron, daughter of the poet Lord Byron and his wife, Anne Isabella “Annabella” Milbanke, Baroness Wentworth, married William King, 8th Baron King, later 1st Earl of Lovelace. Later, Ada Lovelace wrote a detailed method for calculating a sequence of Bernoulli numbers with irascible genius inventor Charles Babbage’s Analytical Engine, which Wikipedia assures us “would have run correctly had the Analytical Engine been built.” Which makes Ada the world’s first computer programmer.

July 9

Marc Andreessen is 40.

July 10

Legendary game designer Scott Adams is 59.

July 16

Dan Bricklin is 60.

July 22

Alan Cox, early Linux kernel contributor, is 43.

July 24

Al Lowe, creator of Leisure Suit Larry series of computer games, is 65.

July 26

Hakon Wium Lie, creator of Cascading Style Sheets, is 46.

July 29

James Duncan Davidson is 41.

Aug 9

Alfred Aho, co-creator of AWK language, is 70.

Aug 11

Steve Wozniak is 61.

Aug 20

Game developer John Carmack is 41.

Aug 29

Boy genius Stephen Wolfram is 52.

Shady Illuminations

Easy Targets

by John Shade

John can’t resist the temptation to make fun of dumb laws, short attention spans among technology marketers, and Mark Zuckerberg.

I realize that these are easy targets. But if these fish don’t want me shooting at them, what are they doing in that barrel?

Legal Follies

If in a democracy we get the laws we deserve, what do the laws we get say about us? One thing they say is that we seem particularly interested in where our fellow citizens are putting things. Our State legislatures have passed laws prohibiting putting ice cream cones in your back pocket, coins in your ears, a chicken on your head, a flamingo in a barber shop, a bicycle in a swimming pool, or a sleeping donkey in a bathtub. Personally, a sleeping donkey is the only kind of donkey I’d ever try to put in a bathtub.

Presumably these laws got written and voted on and passed because people were putting these things in these places, and it was causing problems. It’s humiliating to think that I need a law to keep me from putting an ice cream cone in my back pocket, but I have to say I haven’t found it any great hardship to live within that law. At least so far.

On any day of the week you can find a news story about some dumb law that got passed in some jurisdiction, from Washington to Wasilla. Increasingly these laws have to do with the free flow of information, and what can be done to stop it. But whether it’s the USA PATRIOT Act or PROTECT IP or some other law that sounds like Mother and acts like Big Brother, it seems like it’s still just us telling our neighbors where they can put it—and where they can’t.

And the law isn’t just what legislatures and judges say it is. It’s also what anybody with access to a lawyer can get away with saying it is. So if your doctor doesn’t want you blogging about his professional aptitude or bedside manner, he can just assert ownership over your words.

Or if The New York Stock Exchange doesn’t like its image, they can just threaten to sue anyone who uses its image.

Outrageous claims by corporations are nothing new, but I get the sense that in the wake of Citizens United they’re getting more outrageous and more common. Makes sense: when the Supreme Court gives corporate lawyers an inch, they’re going to see how far they can stretch it.

I ran across this somewhere online, but I can’t remember where: “In China, the government owns the corporations. In the US it’s the other way around.” I hope I don’t get sued by the person who said it. Or the corporation.

Reinventing the Wheel

The headline reads, “Solve Mac Startup Problems by Reseating RAM.” The article describes an Apple-documented technique for troubleshooting a seemingly dead Mac.

Well, it worked for the Apple ///, so why not? Back then, having to tell the user to pick up the computer and drop it onto the desk to reseat the RAM chips didn’t do a lot for Apple’s image, but it was an effective troubleshooting technique.

Maybe it still is.

Speaking of the Apple ///, another detail sort of jumps out from this description. That’s right: the chassis was made from one solid block of aluminum. Brilliant!

Looking back on Apple’s golden age, Scott Knaster said, “We all thought that the first time we did something was the first time it had ever been done.”

Maybe they still do.

The Twitter attention span is understandably much shorter. They repeat themselves every two years. Apparently.

It’s often said that humans are the only species to have invented the wheel. Maybe we’re the only species that thinks that inventing the wheel was a good idea. Richard Dawkins once said, “to a horse, a wheel is something that slows you down.” Meme-killing scientists say that it’s not really true, anyway. Other species have invented the wheel, mostly species lacking brains. But we must be the only species that feels the need to keep re-inventing it.

Zuckerberg’s Year of Living Lethally

We all now live in the FaceBook Era, like it or not. And you have to like it, because the FaceBook Era is the Summer of Like. What it means to like someone has been redefined by the central character of The Social Network. There’s a comforting thought.

In the Summer of Like, you don’t really like someone until you’ve pressed their Like Button. Thank you, Mark Zuckerberg. What’s the next great idea you have to brighten our lives?

Oh, right. Killing animals and eating them. He’s certainly found a way to add drama to his tweets. What I killed today.

Since Zuckerberg’s Year of Learning Chinese took him to China, we can only imagine where The Year of Killing What I Eat will lead him. For now he’s just offing barnyard animals, but surely he’ll soon be out in the wilds of Alaska or canoeing down the Cahulawassee in camo dropping ducks and bucks. When the CEO says, “the buck stops here,” it could be a warning to wildlife.

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 the entire year of 2011, he commits to eat only food killed by others. Send the author your feedback or discuss the article in the magazine forum.