PragPub 2011-09: Issue #27

Table of Contents

Features

- Scala for the Intrigued
by Venkat Subramaniam
With this issue we launch a new series on the Scala programming language by Venkat Subramaniam.

- Scala Traits
by Brian Tarbox
Brian shares one reason to consider Scala even if you are not interested in functional programming.

- The Only Agile Tools You’ll Ever Need
by Jeff Langr, Tim Ottinger
The very first value of agile emphasizes “individuals and interactions over processes and tools.” But that doesn’t mean “don’t use tools.”

- When Did That Happen?
by Dan Wohlbruck
Dan takes us back in time again, to the birth of the ATM. That was in this month in 1969.

Departments

- Up Front
by Michael Swaine
This month kicks off a new series on the Scala language and a series of Pragmatic Bookshelf staff profiles.

- Choice Bits
Horror author HP Lovecraft was not cancelled in August, but you can be forgiven for thinking he was.

- Meet the Team
Meet Miles Forrest, Pragmatic Bookshelf’s Screencast Development Editor.

- Shady Illuminations
by John Shade
Why Steve Jobs will be missed and Tim Cook will be fine.

- Calendar
Author sightings, upcoming conferences, and other events of note.

- But Wait, There’s More...
Coming attractions and where to go from here.

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

The Elegance of Scala
by Michael Swaine
This month kicks off a new series on the Scala language and a series of Pragmatic Bookshelf staff profiles.

With this September issue we introduce a new series on the Scala language by Venkat Subramaniam.

Scala has been called the future of the JVM. It’s an inspired blend of object-oriented and functional features. Simple but powerful, it’s the language the developers of Twitter chose to implement the back end of their system. If you don’t know Scala, it’s time to get acquainted. If you’re already acquainted, there are probably some features you’re not all that familiar with.

Either way, Venkat is the guy to make the introduction. He wrote Programming Scala and if you’ve attended many conferences, you’ve probably heard him speak. And you know you’ll enjoy his introduction to this important language.

To kick off this ongoing Scala coverage, we're sharing another Scala article, this one by frequent contributor Brian Tarbox.

But wait, there's more.

Jeff Langr and Tim Ottinger are back with another in their ongoing series of agile insights. Here they reveal the only agile tools you’ll ever need.

We also have another history article by Dan Wohlbruck. This one is about the origin of that familiar cash-dispensing machine, the ATM.

Ours is a small company, but it can still get confusing for readers to know who’s who. Plus, some new people have joined the Pragmatic Bookshelf staff this year. So it seemed like a good time to start cataloguing who does what around here. Our new series of staff profiles kicks off with an introduction to Miles Forrest, who does our screencasts and podcasts. A good man to know.

And of course that’s not all. As usual, we culled the collective wisdom of Twitter for some Choice Bits, and at a time when everyone is insisting that they know the real secret of Steve Jobs’s success, John Shade admits he has no special insight into Steve at all.

Choice Bits

What Is Soylent Green?

Horror author HP Lovecraft was not cancelled in August, but you can be forgiven for thinking he was.

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^

3

CoffeeScript

2

2

The Cucumber Book

3v

1

Designed for Use

4^

NEW

Web Development Recipes

5^

NEW

Mac Kung Fu

6v

4

Agile Web Development with Rails

7v

5

iOS Recipes

8

8

Programming Ruby 1.9

9v

7

The RSpec Book

10^

NEW

Pragmatic Guide to Sass

11v

6

New Programmer's Survival Manual

Dreams and Nightmares and TouchPads

Nobody dreams of being the one competent guy in a team of idiots. Great colleagues are a keen motivator. — @tottinge

Created a new technical keynote in my dreams last night, jotting down details before I forget, dreams should come with autosave. — @venkat_s

Thankfully, unlike the Kafka story his image evoked, the giant cockroach I awoke to this morning wasn’t me. #lsrc — @chadfowler

Seeing “recursive panic on CPU” on a server. I know that feeling. Breathe deeply, poor server. — @priscillaoppy

Believe it or not, The Machine Shed Restaurant just served 135,000 pieces of deep fried butter at the Wisconsin State Fair! — @NoReservations

Time to break out the Arduinos. Halloween is coming soon... — @PragmaticAndy

“Happy Birthday HP Lovecraft” just doesn’t sound right. bit.ly/rrHvKp — @marick

From HP Lovecraft to HP Touchpad: the future today. #eldritchichor — @GreatDismal

HP single-handedly destroys non-iPad tablet market. zd.net/p4V4Q2 — @ZDNet

Looks like all my hard work ignoring WebOS finally paid off. — @joehewitt

Man, HP should stop producing hardware every day! — @jeff_lamarche

Lessons Learned—or Not

Resolved: Next time I’m asked (for the millionth time) who the worst cooks on Food Network are, I’ll just shut up. — @NoReservations

“I don’t have to decide that right now” is a great decision-making skill to learn. — @venkat_s

The zeroth step in creating humane workplaces is to start calling people “people” not “resources.” #mgmt — @estherderby

Most industrialized nations take care of the mentally ill, while in the US they are left to run for President. — @BorowitzReport

Choosing a lang based on TIOBE index is like choosing a country where to live for its population: 1.5 bln Chinese cannot be wrong, isn’t it? — @mariofusco

2 GB of smartphone data on AT&T costs $30. 2 GB of SMS messages on AT&T costs $2,684,354.56. How does this make sense? — @johnolilly

I wonder how many people now have “correct horse battery staple” as their password? xkcd.com/936/ — @marick

Again, claims we released a study about aliens are not true. Here are the facts from the report’s author bit.ly/p5SYDe — @NASA

(Can’t you just hear the sigh in that tweet?)

Aw Shucks

fantastic 40% off at pragpub using AGILEWEEK code results in $40 savings. (also $100 spending. yay, good stuff) — @RonJeffries

I think the “The Pragmatic Bookshelf” account and book notifications over twitter is a brilliant idea. #good #stuff @prag_notifier — @frankvilhelmsen

People are actually building the video game system I have described in the latest PragPub issue: http://bit.ly/ozsihQ #pragpub #arduino — @maik_schmidt

Read PragPub News on paper.li/pragpub/pragpu… it’s cool, nicely organized, gives good technology pieces. Well done PragPub! Stay pragmatic. — @grantontw

I’ve read PragPub Magazines #21-#26 this week-end. PragProg, you rock! pragprog.com/magazines — @vorushin

Finally, a @pragpub title to help all the beleaguered OS X Lion users out there: pragprog.com/book/ktmack/ma… — @gruber

If Corporations Are People

If corporations are people, can they vote in the Iowa straw poll? — @OTOOLEFAN

If corporations are people isn’t owning a company technically slavery? — @Tedgar3

If corporations are people, then acquisitions are cannibalism. — @izs

If corporations are people, are Taco Bells in Arizona required to show their papers with each order? #p2 — @pari_passu

If corporations are people, I’m gonna marry Apple. I like their style—plus they’re rich!!! — @dgulbran

So, if corporations are people, then people are corporations. No more taxes for me! I’m off to poo in the town well with impunity. — @AndyCobb

If corporations are people, then what is Soylent Green? — @alwen_lost_arts

Who Are Those Guys?

First, they’re not all guys, OK? This month we followed Alwen, Anthony Bordain, Andy Borowitz, Casey, Andy Cobb, Esther Derby, Chad Fowler, Mario Fusco, William Gibson, Jon Gruber, David Gulbransen, Joe Hewitt, Andy Hunt, Ron Jeffries, Jeff LaMarche, John Lilly, Brian Marick, Ted Meredith, Don Millard, NASA, Priscilla Oppenheimer, Tim Ottinger, Grant Sayer, Isaac Z. Schlueter, Maik Schmidt, Venkat Subramaniam, Frank Vilhelmsen, Roman Vorushin, and ZDNet. You can follow us at www.twitter.com/pragpub.

Meet the Team

Miles Forrest

Each month we profile a member of the Pragmatic Bookshelf team. This month it’s Miles Forrest, our Screencast Development Editor. Miles would love to have you follow him on Twitter, and if you happen to be in southwestern British Columbia, he invites you to come visit his club, the Fraser Valley Ruby Brigade. They meet every Wednesday night to hack on projects and talk about code. But most of all he wants you to check out our screencasts and podcasts.

Miles Forrest, Screencast Development Editor

Miles had just finished interviewing Prags Development Editor and author Brian Hogan for his CoderPath.com podcast. “Hey Brian,” he asked, just out of curiosity, “whatever happened to the Pragmatic Podcast? I loved that show.” Brian introduced Miles to Andy Hunt, and a few weeks later he was the new host of the PragCast.

“Being the host of such a popular and influential podcast has been a humbling experience. The Pragmatic Bookshelf attracts the best and brightest in the software world, so preparing for each show is a bit intimidating. Thankfully we have a great audience. Before each recording, I tweet out the name of the guest and a link to a shared EtherPad to collect questions. If you’d like to help with the show, just follow me on twitter.

“I left a secure government job to produce Screencasts with the Prags, and I haven’t regretted the decision for a minute. As the Screencast Development Editor, I work with great authors to produce content for the Pragmatic Screencasts library. It’s both challenging and exciting, and I think people are really going to like the content we have in the works.”

Website: coderpath.com

Email: miles@pragprog.com

Twitter: @milesforrest

G+: Miles Forrest

Scala for the Intrigued

The Elegance of Scala
by Venkat Subramaniam
With this issue we launch a new series on the Scala programming language by Venkat Subramaniam.

Greetings, and welcome to this new series on Scala. Over the next several issues of PragPub we’ll learn quite a bit about this powerful language on the JVM. And why would we want to do this?

First, it’s fun. If programming is your passion, you don’t need any further reason.

Let’s say you’ve been programming in Java for several years, and you’ve gotten really good at it. By now you wake up each morning with the entire code for the day’s task already written in your head. All that’s left is to type that in and get it compiled. You’re such a pro that you don’t even get any compilation errors any more.

Passionate programmers thrive to learn and continuously figure out ways to improve their craft. If programming has turned into a chore, Scala can help.

Scala will add spice to your programming life. In Scala you will write less code to do the same work. You can get more real programming done while spending less time battling the ceremonies imposed by languages or their compilers. Scala gets you directly to where you want to be, so you can be expressive, concise, and productive at writing code.

Let’s be fair—Java has evolved over the years, and has really come a long way. But the good parts of Java are in the layers below the language—the Java virtual Machine and the ubiquitous library. The Java language itself is showing its age.

I see languages as vehicles that allow us to navigate the terrain of the platform. It is time to trade in that clunky gas guzzler for a more efficient vehicle that will allow you to get around faster and more efficiently. Scala is one of the languages on the JVM that can provide exactly that.

In writing Scala, Martin Odersky set out to marry two powerful paradigms: the object oriented and functional styles of programming. Scala is fully object oriented. But it is really a hybrid—a functional object-oriented language with sensible static typing with a good dose of type inference.

One of the key strengths of Scala is in its conciseness.

Let’s compare Scala’s conciseness with Java’s. As an experienced Java programmer, suppose you have volunteered to teach Java to a captive audience who were told that Java is simple (and we know it is, because so many books on Java have told us so). You decide to start with a simple “hello world” example. So, you type:

public

A hand goes up: “What’s public?”

You say: “Eh, you don’t need to know that right now. Let’s proceed.”

public class

A hand goes up again: “What’s a class?”

You say again: “You don’t need to know that right now either, hang in there.”

public class HelloWorld {

Right there a glimpse of hope comes into in the eyes of your audience. You finally got to “HelloWorld”... but that hope comes down crashing when you proceeded to the next line:

public class HelloWorld {

public static

Another hand goes up: “So, we’re not supposed to worry about what static is right now either?!” You know the pain.

Let’s try that in Scala. Open a command prompt and simply type the following:

println("hello world")

In context, that looks like this:

> scala

Welcome to Scala version 2.9.1.final

(Java HotSpot(TM) 64-Bit Server VM, Java 1.6.0_26).

Type in expressions to have them evaluated.

Type :help for more information.

scala> println("hello world")

hello world

scala>

You opened the Scala REPL (Read Evaluate Print Loop), or interactive shell, and simply typed println("hello world") and it printed it. If you want to put that into a file, it is not much different. Create a file named helloworld.scala and type the following in it and save.

println("hello world")

Now, to run it, type:

scala helloworld.scala

and you will see the output:

hello world

You can run Scala code as a script or go through the compilation steps as in Java (more about these later).

Let’s write a program in Java that greets our user and after a delay of one second prints a goodbye message.

public class Greet {

public static void main(String[] args) {

final String name = args.length == 1 ? args[0] : "world";

System.out.println("Hello " + name);

try {

Thread.sleep(1000);

} catch(InterruptedException ex) {

//spend sleepless nights about what to do with this exception

//we're forced to handle

}

System.out.println("good bye!");

}

}

The Java compiler forces you to handle the exception from the sleep method. You have to either catch it or propagate it up the chain by explicitly placing a throws clause. Let’s try that example in Scala:

val name = if(args.length == 1) args(0) else "world"

println("Hello " + name)

Thread.sleep(1000)

println("good bye")

Save that into greet.scala and run it:

scala greet.scala Joe

The Scala code is concise, but there’s more:

1. The Scala compiler did not force you to handle the exception. If you don’t handle the exception it’s automatically propagated up the call chain. You have seen what programmers do when they’re forced to handle exceptions—they show who’s powerful to the compiler by putting in empty catch blocks. Scala expects us to be responsible and do the right thing rather than forcing it on us.

When you program in Java, you feel like you’re working for the compiler. When you program in Scala, the compiler works for you.

2. We used the ternary operator ?: in Java to decide the name. Java provides if statements and then the ternary operator in addition. Scala does not have the ternary operator, because if is not a statement in Scala. It is an expression that can return values. This is a common theme you will find in Scala. It provides fewer but more powerful constructs. Programming in Scala is like playing with the Lego toys: the small building blocks can be configured in endless ways to form bigger structures.

3. Scala did not require you to create a class. As we will see later, you can create classes in Scala, but you do so only if you want to, not because you’re forced to. In Scala, simple things are simple and complex things require marginally more effort.

We’ve merely scratched the surface of Scala (hey, this is the first article in the series). But, I hope to have whetted your appetite for the language. So far I have painted a good picture of Scala. To be objective, the syntax of Scala can be quite intimidating to beginners. Scala is not for the faint at heart. You have to get used to the syntax and some of the quirks of the language. I have heard many programmers new to Scala complain, so now I believe

You Don’t Pick Scala, Scala Has to Pick You.

In a sense, Scala is like the dragon in Avatar. It will try to kill you, but if you master it, you can fly great distances with it and have a wonderful time.

My objective is not to show you everything you can do with Scala. Instead, we will walk through how effectively we can apply this language to do common operations we do in day-to-day programming.

I hope you’re excited about this series as much as I am. Until next time, program responsibly. Cheers.

Dr. Venkat Subramaniam is an award-winning author, founder of Agile Developer, Inc., and an adjunct faculty at the University of Houston. He has trained and mentored thousands of software developers in the US, Canada, Europe, and Asia, and is a regularly-invited speaker at several international conferences. Venkat helps his clients effectively apply and succeed with agile practices on their software projects. Venkat is the author of .NET Gotchas, the coauthor of 2007 Jolt Productivity Award winning Practices of an Agile Developer, the author of Programming Groovy: Dynamic Productivity for the Java Developer and Programming Scala: Tackle Multi-Core Complexity on the Java Virtual Machine. His latest book is Programming Concurrency on the JVM: Mastering synchronization, STM, and Actors. Send the author your feedback or discuss the article in the magazine forum.

Scala Traits

A Guide for the Non-Functional Java Programmer
by Brian Tarbox
Scala let you mix-in different related traits.

By “non-functional,” I mean of course the programmer who is not looking to jump into the world of functional programming. ;-)

Scala is often portrayed as a solution for the multi-core scalability problems that come with Java’s approach to multithreading, but it offers so much more.

The Usual Reason to Consider Scala

Java multithreading requires you to protect any variables that might be accessed from multiple threads. This is often referred to as “synchronize and suffer” because you must manually add synchronization to protect your variables—and then suffer because it’s so easy to get it wrong. And there are lots of ways to get it wrong:

- assuming you only have to synchronize setters and ignoring getters

- forgetting that synchronized methods exhibit fairness while synchronized blocks do not

- forgetting to protect related variables, exposing the code to data corruption and/or deadlock

Scala has certainly made a name for itself in offering ways to avoid these problems via immutable variables, functional programming, actors, and libraries like Akka. But there is a whole other side to the language. So even if you’re not ready to drink the mutability-is-bad Koolaid, Scala still has lots to offer.

This article discusses one of those “non-functional” features: traits.

The Java [Anti]Pattern

One of the common development patterns in Java is to create an interface, then create an abstract base class that implements that interface and provides some base implementation, and then create several concrete classes derived from the base class. Some might call this an antipattern because of the number of files it creates. On the other hand, Java doesn’t give you much choice. Interfaces cannot have implementations, so there is no place to put common method instantiations except in classes.

interface ContentSelector {

public Content selectContentByType(ContentType contentType);

public Boolean contentIsLocal(Content content);

}

public abstract class AbstractContentSelector implements ContentSelector {

public Boolean contentIsLocal (Content content) {

// some implementation

}

}

public class LocalContentSelector extends AbstractContentSelector {

public Content selectContentByType(ContentType contentType) {

...

}

}

public class RemoteContentSelector extends AbstractContentSelector {

public Content selectContentByType(ContentType contentType) {

...

}

}

Listing 1: The Java [Anti]Pattern

Traits

Scala, on the other hand, offers traits, which are like interfaces with a little implementation thrown in. (A trait can also be like a mini-strategy pattern, as you can mix-in one of several different related traits depending on your need). A class can use a single trait, multiple traits, and/or can extend another class.

Here’s all the syntax you should need to be able to read the Scala in this article:

- def starts a method,

- variables are started with var or val,

- variables are defined with [name] [type] rather than Java style [type] [name], and

- semicolons are not required.

That covered, let’s look at some Scala:

Trait ContentSelector {

val url: String

def selectByType(contentType: String) : String

// abstract method, interface

def isLocal() : Boolean = { url.indexOf("file:///") != -1 }

// concrete method

}

class LocalContentSelector(val url: String)

extends ContentSelector {

def selectByType(contentType: String) =

"some impl returning a string")

}

class RemoteContentSelector(val url: String)

extends ContentSelector {

def selectByType(contentType: String) =

"some other impl returning a string")

}

Scala does not have an interface keyword, so traits do double duty. An abstract method in a trait is just like a Java interface method in that all classes using the trait must define it. Trait methods with an implementation do not need to be implemented by classes using them.

This may seem like a small saving but it’s just the tip of the iceberg with traits.

While java interfaces are applied on an all-or-nothing basis—your class either implements the interface or it does not—Scala lets you use traits on a per-instance basis. So you can say “this instance of class Foo that normally does not extend trait Bar, does in fact extend it!”

MySpecialContent defined here is an instance of the Content class, but for this particular instance object we mix in the OtherTrait:

val mySpecialContent = new Content("special") with OtherTrait

This capability may not be universally viewed as a Good Thing by all Java programmers, as it is a step towards dynamic languages where classes can be modified after the fact. While it is true that Traits and Open Classes are different parts of the language, they do accomplish the same thing: they change the behavior of an existing class, and that is something odd to many traditional Java programmers.

While many view open classes as a boon it is also true that they add complexity. An instance of the class created without the trait can be assigned an instance of the class with the trait, but not the reverse. On the other hand, you still have the option to mark a class as final which prevents instance-based trait mixing. On the other other hand, marking a class as final also means you cannot derive other classes from it, so it’s at best an imperfect solution.

final class Foo {

}

scala> val thisFoo = new Foo with ContentSelector

<console>:7: error: illegal inheritance from final classFoo

Given all this, why would you want to use instance-specific trait mix-ins?

There’s a Pattern for That

Think strategy pattern. The strategy pattern says that a class performs a type of action where there can be several related implementations of that action.

An example from my field of Video On Demand might be obtainTheContent. We might have a class called Movie that corresponds to playing a movie on a customer device. In order to do so it would presumably have to get the bits to play; i.e., it would obtainTheContent. It might do that differently if the customer device was a plasma TV, a tablet, or a smartphone.

In Java we might declare an obtainTheContent method that accepted a device type parameter and performed different actions based on it. Or, we could declare a set of related classes that each implemented an obtainTheContent interface. We could then instantiate the appropriate class and call the method on it. Or we could use Spring (or Guice) and declare the interface as a required bean and create the correct type on the fly.

In Scala we could simply say:

val myMovie = new Movie with TabletContent.

This would create a movie that exposes methods from the TableContent trait. We could also create an object new Movie with BitPlasmaContent.

I hope this brief exposure to one of the the non-functional aspects of Scala has piqued your curiosity. To learn more you can explore Programming Scala by Venkat Subramaniam or Programming in Scala2 by Martin Odersky, Lex Spoon, and Bill Venners, all of whom know far more about Scala than I ever will.

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

The Only Agile Tools You’ll Ever Need

A Sanity Check on the Use of Tools
by Jeff Langr, Tim Ottinger
The very first value of agile emphasizes “individuals and interactions over processes and tools.” But that doesn’t mean “don’t use tools.”

Good value systems change little over time. Ten years on, and the core values of agile haven’t changed one bit. At Agile 2011, the agile manifesto signatories reaffirmed their belief that these values represent the foundation for “better ways of developing software.” Agile’s underlying value system will be championed far longer than the buzzword agile itself.

Of course, values must translate into practices that accommodate the realities of modern software development. Many larger companies (and even some smaller ones) have a couple of oft-legitimate goals that can present challenges to agile adoption:

- They want to hire individuals in remote locations.

- They want to standardize on processes and tools across the enterprise.

A fairly natural response to these goals is to introduce or standardize on a single agile PM (project management) tool (some which are referred to as agile application lifecycle management, or ALM, tools). The thought is that a tool will provide them with immediate visibility across their entire portfolio, and will also help ensure that remote team members have roughly the same experience and level of challenge as local members. So what’s the challenge to agile?

The very first value of agile emphasizes “individuals and interactions over processes and tools.” This value is bolstered by at least two principles:

- “Business people and developers must work together daily throughout the project.”

- “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”

We’re quick to point out that the agile values and principles do not say “don’t use tools!” They instead say we must emphasize “individuals and interactions” before we consider tools. The two quoted principles remind us that we want team members to work closely, to converse continually, to collaborate. This value is practical as well as appealing on the personal level, since misunderstanding is a frequently expensive kind of error. Face-to-face communication allows us to iterate and elaborate on our understandings in a way that written text does not.

What about agile teams that want to have distributed team members? If you believe the face-to-face principle, distributed teams are immediately less efficient and effective. So does the notion of “distributed agile” make any sense? That’s a great question, one that we’ll answer in a forthcoming PragPub article.

Not All Tools Are Created Equal

We love great tools! We love tools like Hudson/Jenkins that help bring a team together, coordinating and tracking things that absolutely must be done with software. We love tools like Skype that help us communicate cheaply and effectively when we are forced to be remote. We love how Google docs allows the two of us to collaborate effectively as we write this article. We love how Git allows us to safely and effectively distribute and coordinate a source repository across a team of developers. We have favorite test frameworks and text editors and IDEs. We even love measurement tools. Notice, however, that these are not “agile” tools but collaboration and software development tools—the kinds of tools that provide immediate value.

We love whiteboards and large easel pads, which allow us to capture important bits of conversations and broadcast them so anyone can see. We love index cards, which let us capture important bits of conversations no matter where we are, then effectively use them as collaboration and planning tools (and as broadcast tools when tacked onto a corkboard). These tools are high-touch and low-tech. It is trivial to tailor their use to a team’s needs.

We love the non-software tools so much that we created an Agile in a Flash card:

The blog entry for the card stirred a bit of controversy (and also provoked this article). It’s a bit tongue-in-cheek—despite the card’s title, you will absolutely require additional software-based tools to succeed. We stand by our core point, however: Seek low-tech and immediate tools before you insist on using complex software tools.

The Cost of Using the Tool

There is a famous legend of a sacred white elephant owned by a Siamese ruler. The ruler had a nephew whose wealth and influence posed a threat to the king. The canny king placed the nephew in charge of the royal white elephant. The elephant could not be allowed to come to harm, as it would be seen as scandalous and a bad omen for the kingdom, but the care and feeding of the elephant was amazingly expensive. The honorable custodianship of the realm’s most sacred symbol eroded the nephew’s power and wealth so that he was no longer a threat to the king.

A management tool can be of great help, or it can be much like the white elephant: impoverishing the team with many troublesome tasks to distract them from daily work, while having such an organizational emphasis that team members dare not neglect those tedious tasks.

We seek immediacy with our tools. As long as we collaborate in the same room, direct conversation is the most immediate tool possible; whiteboards and index cards are a close second. They are instantly accessible, requiring minimal training, navigation time, maintenance, and cost.

A story from Jeff illustrates how tools can sometimes get in the way of collaboration:

“I attended a team’s story-gathering session for a new project. The team had a couple remote members, so they opened a phone conference bridge. They initiated a desktop-sharing session using WebEx to share their project information, which was held within an open-source agile project management tool. For the local attendees, they presented the tool using an LCD projector.

“The team would discuss a story, and the project manager (PM) would attempt to enter it in the tool. As the team moved on to other potential stories, discussions arose around its relationship to already-entered stories. These discussions resulted in changes to other stories—we updated scope or granularity for some, and ended up deleting others.

“The meeting quickly degraded into all of us watching the PM as she struggled to keep up with the discussions. She struggled with the tool itself—‘How do I filter the list of stories?’ ‘How do I make it not require an estimate?’—and we struggled to follow what she was doing. The essence of the stories we were trying to brainstorm was lost in the tool and the constraints of a lower-resolution display. The tool, not the stories, become the focus of attention.

“Twenty minutes in, we had perhaps three stories entered and still tentative, and a couple dozen more to peruse. At this pace, we projected that the meeting would last at least another hour.

“Interestingly, I noted that no one was on the teleconference bridge; for whatever reason, the remote invitees were not in attendance. I asked the PM to dispense with both the bridge and desktop sharing. The remaining team—everyone in the room—moved to a whiteboard, where everyone could see and contribute to the scribbling of candidate stories. Once we were happy, we ended the meeting, and the PM typed them into her tool.

“We were done in less than twenty minutes. We would have wasted significantly more time had we not sought a more collaborative, immediate tool. Granted, more experience with the tool would have helped, but ultimately all acknowledged that the tool was at best a distraction during the meeting.”

Tools like Mingle have some ability to support story-related meetings. However, they still pale in the face of non-software tools that have more immediacy and collaboration support. It’s not just us: Jon Archer relates that his manager “rarely looks at [their software tool] now, rather prefers the big visible status on the wall some teams have.”

Our recommendation: Any tool you use for collaboration should eliminate any potential distractions to focus. Perhaps the best software tool is an empty text or spreadsheet document, each providing a blank slate and a way to quickly move around, change, or highlight pieces of information.

Charts and kanban walls are so visible, immediate, and meaningful that they inspire action. A team may see that they are not tracking well to the sprint’s goals and proactively start rescoping the work or reorganizing the team. Graphs of quality trends urge teams to improve their testing and refactoring. In this way, the physical artifacts have a coercive immediacy. Software-based agile tools tend to require a browser and/or login and some navigation to reach the same information, which robs them of coercive immediacy. Sometimes teams reproduce the tool’s graphs in poster form and hang them on the wall in their team space to improve their influence.

Software tool learning curves can be steep. The high-end tools generally attempt to be highly configurable, end-all solutions for agile project and portfolio management. The increased flexibility comes with increased complexity, requiring significant training.

But We Already Paid For It

If your organization has invested significant money in an agile PM tool, we’re not telling you to discard it (not yet, at least). Before you proceed, however, you must determine what benefits you expect to derive from use of the tool. Here is a partial list of legitimate goals for organizational investment in a single tool:

- get quick visibility into status for each project

- understand dependencies between projects

- expose and manage constraints that impact projects

- eliminate the cost of multiple tools

- promote common terminology and share valuable information between projects

- roll up meaningful statistics across teams

- realize a price advantage compared to individual purchases of desired tools

Avoid agile tool abuse! Some goals you may have for tools can actually hurt your efforts. Primarily, don’t use a tool to help pit one project against another. There is no consistent cross-team measurement of productivity. Due to the endless variables—team composition, skill set, project constraints, technology impacts, and so on—it is not possible to compare a team’s productivity to another in a meaningful way. Comparisons provide little value and may actually create resentment within your organization.

Don’t allow tools to substitute for collaboration and leadership. No tool is as valuable as maintaining contact with your customers and development team members. No manager will be a leader who visits their team primarily through management tool reports. A manager must know his team.

Avoid having anyone other than project managers (or individuals acting in that role) do data entry in the tool. Most of the tools provide a simplified interface that allows team members to quickly get in and track their progress during an iteration. But if you’re doing agile well, project management is not a full-time job on a single project. In order of desirability:

- The team takes on the responsibility.

- The project manager is simply another team member and contributes in other ways to the project on a daily basis.

- The project manager tackles multiple projects.

In any case, we’re suggesting that a good project manager can manage the tool, saving the team members from the effort of re-capturing information that the project manager should already know.

Avoid tracking too much in the tool. The need to track a significant amount of day-to-day activity in a tool is a process smell. On a given day in a typical agile team doing short iterations, one or two significant things should happen: the team completes a story or tackles a new story. The effort required to track these events in a tool should take seconds only. (A very good team might start and finish a couple stories in a day, doubling the number of seconds required from the PM.) If stories are started and completed in such short order, tracking task breakdowns for the story in a tool becomes a complete waste of effort.

“But we usually have four or five stories open at a time, each spanning the bulk of the iteration.” Don’t do that. It’s not collaborative, and simply compounds all the challenges of waterfall in a short one-or-two-week space. Too much work in process also compels you to track more information in the tool—information that is almost never useful outside that iteration.

Don’t allow the tool to dictate your work system. If you can make stories small and digestable, you don’t need task tracking. It makes no sense for collaborative teams to assign work to individuals. It is absurd to track activity (rather than accomplishment) to the 15-minute interval in the chaotic world of collaboration. Finally, don’t escalate. If the tool doesn’t tell you what you want to know, don’t beef up the tool. Demanding more governance information will not accelerate delivery or improve quality or provide you with any of the other features that drove you to choose an agile work style.

Wrap-up

Our criteria for tools are that they:

- aid the team (hence the emphasis on development and testing tools)

- add no unnecessary burden to the team

- do not substitute for leadership and management

- provide coercive immediacy to aid the team

- are given their rightful place as aids, not drivers

The first purchase you make for an agile team should not be an agile management tool, and the choice to bring an agile management tool into your practice should be informed and guided by people who are practicing “agile” by the principles and values that define the practice. Do not allow agile novices to be swayed by salesmen and brochures, but carefully pick the tools that will support your practice and your company if you pick any at all.

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

Tim Ottinger is the originator and co-author of Agile in a Flash, a contributor to Clean Code, and a 30-year (plus) software developer. Tim is a senior consultant with Industrial Logic where he helps transform teams and organizations through education, process consulting, and technical practices coaching. He is an incessant blogger and incorrigible punster. He still writes code, and he likes it. Send the authors your feedback or discuss the article in the magazine forum.

When Did That Happen?

The Bank That Will Not Close
by Dan Wohlbruck
Dan takes us back in time again, to the birth of the ATM. That was in this month in 1969.

“On September 3, 1969,” Chemical Bank advertised at the time, “our branch will open its doors at 9:00 and we will never close again!” On that day, the Automatic Teller Machine was born. Although there were earlier attempts, the ATM with its ubiquitous magnetic strip was made available to the public forty-two years ago this month.

Hoodlums and Prostitutes

Technically, the Chemical Bank ATM was an electronic off-line cash dispensing machine, manufactured by the DocuTel Corporation. You inserted your card into the slot and the machine read the card’s magnetic strip containing your account information, and dispensed the cash. How the first ATM came into being and the way it evolved makes for an interesting story about technology and its adoption.

The idea for a mechanical device to perform financial transactions really dates back another 30 years, and was the inspiration of Luther George Simjian. Simjian was an inventor par excellence. His inventions included, according to the MIT website, the self-focusing camera, a flight speed indicator for airplanes, an automatic postage metering machine, teleprompter, Range Estimation Trainer, and “...contributions to the evolution of the Bankmatic automatic teller machine (ATM).” In 1939, Simjian received multiple patents for his machine and convinced a New York bank to give it a try.

It was a flop. The machine was discontinued after six months because of lack of use. Simjian recalled that it was accessed primarily after hours by a few hoodlums and prostitutes. An ignominious beginning.

The next early adopter was the Barclays Bank in 1967, and their machine was the inspiration of inventor John Shepherd-Barron. In an interview with ATM Industry Association Chief Executive Mike Lee published on the association’s website, Barron recalled “being infuriated that I could not always get access to my money when I needed it, especially over weekends when banks were closed.... I started thinking of a way of getting money around the clock.”

Shepherd-Barron’s machine was more successful. Barclays ordered six of the machines, and upon their successful installation, they ordered fifty more. But this machine was mechanical, not electronic, so it was not going to be able to lead to what we today think of when we say ATM. Despite its earlier introduction and the insistence by the British press that Shepherd-Barrons’s machine was the first ATM, this DACS (De La Rue Automatic Cash System), as it was called, was really just another precursor to the machine that can fairly be called the first ATM.

That first ATM, though, had to wait for DocuTel, and DocuTel didn’t even exist yet.

The First ATM

It wasn’t until 1967 that DocuTel was created as a spinoff of Recognition Equipment Inc., which produced baggage handling equipment for airline terminals. An ATM Marketplace article reports:

“Legend has it that REI employee Don Wetzel had seen similar cash dispensing machines in Europe and believed a version of them would work in the U.S. Wire magazine reported in 1993 that Wetzel was waiting in a long line at a Texas bank when he got the inspiration to develop an electronic banking machine.

“Whatever the case, DocuTel researched the possibilities and found that, despite bankers’ beliefs to the contrary, people preferred speed, convenience and confidentiality over personal, face-to-face service.

“Therefore, Wetzel, along with engineers Tom Barnes and George Chastain, set about creating such a machine—which cost more than $4 million to develop.”

As well as the electronics, the Docuteller’s components were a MICR printer to record the transaction in such a way that it could be understood by the bank’s other equipment, and the magnetic strip to hold the appropriate account number to store the amount that the customer had received, the routing and transit number of the bank, and the date.

The capabilities of the ATM advanced rapidly. DocuTel’s Total Teller machine also accepted deposits and made cash transfers from one account to another. It was unveiled in 1971. In four years since the company had come into existence, DocuTel owned the American market for ATMs. But this success was not to last. Before the decade was out, competition and complacency doomed the company. Before the end of the 1980s, DocuTel, the innovator of the electronic ATM, was no more. The company from Irving, Texas, was overtaken and undone by their better-known competitors IBM, NCR, and Diebold.

Today there are almost 2 million ATMs worldwide installed from McMurdo Sound in Antarctica to North of the Artic Circle in Norway.

It began over 40 years ago in New York—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? Send the author your feedback or discuss the article in the magazine forum.

Shady Illuminations

Whose Product Line Is It Anyway?
by John Shade
Why Steve Jobs will be missed and Tim Cook will be fine.

First of all, no, you are not the first person to notice that Apple’s new CEO Tim Cook looks like Ryan Styles of “Whose Line Is It Anyway?” (Both the original British series with the wonderful Clive Anderson as host and the American version with the execrable Drew Carey.)

It’s mostly in his official photo, I think; in person Cook looks less like a 6'6" former fish processor and Carol Channing impersonator. I bring all this up to head off what I see as possible embarassments in Cook’s future: Ryan Styles showing up at the next MacWorld Expo impersonating Cook, Cook delivering his keynote in a style suggested by audience members, or anything involving Drew Carey.

Second, no, Apple isn’t going to flop like a food cart in a hurricane with the departure of Steve Jobs as CEO.

The Tim Cook Era Wasn’t Born Yesterday

My second thought when I read that Jobs was resigning was, “Who’s replacing Tim Cook as COO?” (My first thought was about Steve, and I’ll reserve that. Even if I can occasionally get sentimental, I don’t do sentimental.)

Apple’s success isn’t all about product design and strategy. Apple also happens to be a remarkably efficient operation. That efficiency is every bit as important to Apple’s success, and it is the work of Apple’s new CEO. Tim Cook’s been running the operation for years as COO, with an occasional stint as stand-in CEO, with remarkable efficiency, and there’s no reason for the wheels to suddenly fall off the locomotive he built.

Apple’s near-term future is in Tim Cook’s immediate past. Apple’s suppliers don’t think Steve’s departure will make much difference. You have to assume that’s because of their time horizon. Apple’s suppliers are in a position to know what’s coming down the pipeline in the next year and to have an idea what may be coming a couple of years out, and both Jobs and Cook have their fingerprints on all of that. So it’ll be some time before the product line starts to reflect Tim Cook exclusively rather than Steve Jobs.

So, near-term, no problem. Assuming that Cook doesn’t screw up.

If your cash and cred determine how much slack you get when you screw up, Apple under Tim Cook is slack-rich. More so than, say, Microsoft under Steve Ballmer, a CEO who has taken all the rope Microsoft’s cash and cred has given him. And you know what they say about giving him enough rope. Apple can make a lot of mistakes so long as it corrects them quickly. As it did under Steve Jobs.

Strategically, Apple can coast. A company’s culture and strategy is most likely to change when the company is in trouble. Think HP. That’s when companies tinker with the basics: when they aren’t working. Companies that are on top of the world with tons of cash and a market valuation above the clouds don’t mess with the formula. Apple can coast for years, milking the current products and their obvious upgrades and the new products already in the pipeline.

And given what’s probably in the pipeline, Apple’s coasting will look like another company’s bold ventures.

And beyond that? What happens when Apple moves beyond Jobs-influenced products and strategies?

Interesting question, to which the Magic Eight Ball says, “Ask again later.” Several years from now, we will be able to see what post-Jobs Apple looks like. But anybody trying to predict that far out in this industry is just guessing. Which is a well-paid job in tech journalism.

The Thrill Is Gone

So am I saying that Steve Jobs leaving isn’t important? No, I’m not that ignorant. Here’s how ignorant I am: I don’t know the secret of Steve Jobs’s success. This apparently makes me unique among commentators on technology.

Every B-school graduate and tech pundit knows that there’s a secret to what makes Jobs tick, and that only they understand it. Well, I don’t know much, but I do know stupid. Not one of them knows what makes Jobs tick. Only one person knows what makes Steve Jobs tick, and that’s Steve. And if he were even remotely secretive about it, all you could do would be to guess.

But Jobs has been telling us for years. He’s spelled out his philosophy in detail, and anybody who wants to emulate him has only to embrace that philosophy. He’s told his competitors all they need to know to do as he does, for crying out loud, and they don’t. He’s told the pundits all they need to know to understand his success, and they still flounder about trying to guess.

Mostly, I think, because they don’t believe him.

They don’t believe him when he says he doesn’t care about money. But it’s clearly true. During the whole stock options embarassment, Jobs’s defense was that he didn’t know anything about that stuff. I believed it.

It may be the fact that he actually doesn’t care about money that makes it so hard for people to understand what he does. To a lot of people in business, the phrase “doesn’t care about money” is not a meaningful string of words.

They don’t believe him when he says he doesn’t care what users think they want. The idea of going with your gut and your own sense of what works without ratifying it with focus group data or social media feedback or something just seems so wildly risky that they can’t grasp that Steve doesn’t see it as risky. For him, it isn’t a strategy, it’s a value.

Maybe the biggest thing they don’t get is the concept of design as Steve Jobs embraces it. This pontification is typical of the pundits saying, “you don’t understand what has made Apple great, but I do.” All the “reality” points this guy offers up as his brilliant insights are what Steve Jobs has always said, and they’re all about design.

I couldn’t teach a course in Jobs-style product design, but I can spot somebody who doesn’t get it a mile away: they talk about eye candy and putting a pretty face on it. Even I know that for Jobs, design goes clear to the bone. I know this not because I’m in on the secret, but because that’s what he’s been saying forever.

They don’t believe him when he says it’s all about saying “no.” Jobs is the master of saying no. He doesn’t design or invent or dream up products. The people at Apple who do those things are still doing those things. Jobs approves other people’s projects. By which, of course, I mean that he rejects them. The few projects that survive a long series of rejections become products. By then they’ve had almost all the rough edges beaten off them.

I know this because it’s there for all to see, and because Steve Jobs has pointed it out repeatedly. There is no secret. He is the person he claims to be.

They don’t believe him when he says he lives each day in the knowledge that it could be his last. That is hard to believe, but Jobs has had more than one opportunity to look death in the face. He means it. Steve Jobs is not an enigma. He’s this guy. He’s this guy.

Roll the Closing Credits

I’m not saying that Apple will keep growing and wowing the rubes. Even with Jobs at the helm, just where do you imagine Apple was going to go next? Is there some bell they could ring that would peal as loudly as the iPod, the iPhone, iTunes, the iPad? Or the numbers picture? Once you’re on top, it’s hard to move up. Once you have a reputation for knocking the customers’s socks off, important but non-sock-knocking innovations look like failures. Apple is going to get boring simply because it’s time to get boring. No matter who’s the CEO.

Plus, they’re still leaving iPhone prototypes in bars, so clearly nothing fundamental has changed.

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. When he realized how boring the computer industry was going to become with Steve Jobs’s departure from the CEO office, he knew that was what he wanted to write about this month. Send the author your feedback or discuss the article in the magazine forum.

Calendar

Author sightings, partner events, and other notable happenings.

We often want to call your attention to a particular event, and this month it’s this Clojure Conference in Raleigh. Lots of good people there and all the Clojure expertise in the world, apparently.

- Nov 10–12, clojure-conj, Raleigh, NC
clojure-conjStuart Halloway and Aaron Bedra, co-authors of Programming Clojure, 2nd Edition (among others)

Author Appearances

Who’s where, and what for.

- Sept 7, JavaZone 2011, Oslo, Norway
“Regex—The Future Programming”Staffan Nöteberg, author of Pomodoro Technique Illustrated

- Sept 7–9, ALE Unconference, Berlin, Germany
Opening KeynoteRachel Davies, author of Agile Coaching

- Sept 8, HDC 11, Omaha, NE
“Unleashing your Inner Hacker”Aaron Bedra, co-author of Programming Clojure, 2nd Edition

- Sept 9, HDC 11, Omaha, NE
“Mo Cores, Mo Problems”Aaron Bedra, co-author of Programming Clojure, 2nd Edition

- Sept 9–11, New England Software Symposium, Boston, MA
“Hello Groovy!,” “Grails: Bringing Radical Productivity to the JVM”Dave Klein, author of Grails: A Quick-Start Guide

- Sept 11–14, SpeakerConf, Rome, Italy
“Seeing the graph through the nodes”David Chelimsky, co-author of Thje RSpec Book and contributor to Advanced Rails Recipes

- Sept 12–13, Agile Program Management, Berlin, Germany
“Agile Program Management”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

- Sept 15, 2011,    Skills Matter, London, UK
MarkLogic User Group London (MUGL)Ron Hitchens, author of    Getting Started With XQuery

- Sept 15–16, Agile On The Beach, Falmouth, UK
“Surfing the Agile Wave”Rachel Davies, author of Agile Coaching

- Sept 15–16, Agile Program Management, Amsterdam, Netherlands
“Agile Program Management”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

- Sept 16, Innovate Virginia, Richmond, VA
“The Art of the Spike”Aaron Bedra, co-author of Programming Clojure, 2nd Edition

- Sept 16, Innovate Virginia, Richmond VA
KeynoteAndrew Hunt, author of Pragmatic Thinking and Learning

- Sept 16, Innovate Virginia, Richmond VA
“Building Analytics with Clojure”Aaron Bedra, co-author of Programming Clojure, Second Edition

- Sept 16, Innovate Virginia, Richmond VA
“Tightening Your Feedback Loop”Jared Richardson, author of Ship It!

- Sept 18, Strangeloop, St. Louis, MO
“Building Analytics with Clojure”Aaron Bedra, co-author of Programming Clojure, 2nd Edition

- Sept 18–20, Strange Loop, St. Louis, MO
“Airplane-Mode HTML5: Is your website mobile-ready?”Scott Davis, author of Groovy Recipes

- Sept 18–20, Strange Loop, St. Louis, MO
“Functional Thinking”Neal Ford, coordinating the forthcoming Thoughtworks Anthology 2

- Sept 19, 2011, Yahoo! Program Management Council, Santa Clara, CA
“Managing for Collaboration”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

- Sept 19, Strangeloop, St. Louis, MO
“Skynet: A Scalable, Distributed Service Mesh in Go”Brian Ketelsen, author of The Go Programming Language

- Sept 27, Agile NYC, New York, NY
“From Preaching and Training to Teaching and Learning”David Hussman, author of Cutting an Agile Groove

- Sept 28, Lean Tribe Gathering, Stockholm, Sweden
“Pomodoro Technique”Staffan Nöteberg, author of Pomodoro Technique Illustrated

- Sept 29, Agile Boston, Boston, MA
“From Preaching and Training to Teaching and Learning”David Hussman, author of Cutting an Agile Groove

- Sept 29–30, Agile Cambridge, Cambridge, UK
“The Role of an Agile Coach”Rachel Davies, author of Agile Coaching

- Oct 2, Oracle OpenWorld, San Francisco, CA
“SQL Injection Myths and Fallacies” and “Maatkit Tools—Like a MySQL Guru in a Box”Bill Karwin, author of SQL Antipatterns: Avoiding the Pitfalls of Database Programming

- Oct 3, Mini SPA, Manchester, UK
“Improving Trust in Teams”Rachel Davies, author of Agile Coaching

- Oct 4–6, Agile Business Conference, London, UK
“Agile Retrospectives”Rachel Davies, author of Agile Coaching

- Oct 5, Java One, San Francisco, CA
Script BowlAaron Bedra, co-author of Programming Clojure, 2nd Edition

- Oct 10, Web 2.0 Expo, New York, New York
“The New Startup Stack”Trevor Burnham, author of CoffeeScript: Accelerated JavaScript Development

- Oct 10–12, Pacific Northwest Software Quality Conference, Portland, OR
“Dirty Tricks in the Name of Quality”Ian Dees, author of Scripted GUI Testing With Ruby and co-author of Using JRuby

- Oct 11–13, Scrum Gathering, London, UK
“Open Space Facilitation”Rachel Davies, author of Agile Coaching

- Oct 14, MagRails, Manchester, UK
“The Quest for Agility”Rachel Davies, author of Agile Coaching

- Oct 17–20, Zend PHP Conference, Santa Clara, CA
“SQL Injection Myths and Fallacies” and “MySQL 5.5 InnoDB Tuning”Bill Karwin, author of SQL Antipatterns: Avoiding the Pitfalls of Database Programming

- Oct 24–27, Pragmatic Studios, Reston, VA
iOS 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

- Oct 30–Nov 4, AYE Conference, Cary, NC
“Project Bloat Doesn't Float,” “Replacing Management Myths with Effective Practices,” “Influence and Authority: Using Your Personal Power to Get Things Done,” “Adapting to Change in Your Life,” and a one-day workshop: “Making Geographically Distributed Projects Work”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

- Nov 6–11, Better Software Conference East, Orlando, FL
Three tutorials: “Tuning and Improving Your Agility,” “Agile Project Design: Building Strong Backlogs,” “Agile Estimation and Planning: Scrum, Kanban, and Beyond”David Hussman, author of Cutting an Agile Groove

- Nov 7–9, Clojure/conj, Raleigh, NC
“(with-training Clojure/conj)”Aaron Bedra, co-author of Programming Clojure, 2nd Edition

- Nov 16, QConSF, San Francisco, CA
“One () to rule them all”Aaron Bedra, co-author of Programming Clojure, 2nd Edition

- Nov 16, Agilis, Reykjavik, Iceland
WorkshopRachel Davies, author of Agile Coaching

- Nov 18, SCNA, Chicago, IL
“Simplicity”Aaron Bedra, co-author of Programming Clojure, 2nd Edition

- Nov 22, Best of DevSum, Stockholm, Sweden
“Regex in .NET”Staffan Nöteberg, author of Pomodoro Technique Illustrated

O’Reilly Events

Upcoming events from our friends at O’Reilly.

- Sept 17–18, World Maker Faire, New York, NY
World Maker Faire

- Sept 19–23, Strata NY, New York, NY
O’Reilly Strata Conference: Making data work: “With hardcore technical sessions on parallel computing, machine learning, and interactive visualizations; case studies from finance, media, healthcare, and technology; and provocative reports from the leading edge, Strata Conference showcases the people, tools, and technologies that make data work.”

- Oct 9–11, Android Open, San Francisco, CA
Android Open Conference: “Android Open is the first conference to cover the entire Android ecosystem. Whether you’re a developer, IT pro, business decision-maker, or marketer, you’ll find the latest and best information for maximizing the power of the Android platform.”

- Oct 11, TOC Frankfurt, Frankfurt, Germany
Tools of Change Frankfort: “Tools of Change Frankfurt returns for a third year on... the eve of the Frankfurt Book Fair (12-16 October)—connecting the people, content, and conversations along the cutting edge of global publishing and technology.”

- Oct 10–13, Web 2.0, New York, New York
Web 2.0 Expo NY: “At the next Web 2.0 Expo, we’ll reveal the key pieces of the digital economy and the ways you can leverage important ideas for your own success. We’ll look specifically at web success stories in the New York startup ecosystem.”

- Oct 17–19, Web 2.0 Summit, San Francisco, CA
Web 2.0 Summit: “Once each year, the Web 2.0 Summit brings together 1,000 senior executives from the worlds of technology, media, finance, telecommunications, entertainment, and the Internet. For 2011, our theme is ‘The Data Frame’—focusing on the impact of data in today’s networked economy.”

- Nov 8–9, Velocity Europe, Berlin, Germany
Velocity Europe: “Velocity Europe is the convergence of performance and site reliability experts and rock stars who share the unique experience that can only be gained by operating at scale. At Velocity, leading experts share their knowledge about how you can make your site scalable, reliable, and fast.”

USENIX Events

What’s coming from our USENIX friends.

- Sept 21, LISA Data Storage Day, Grand Rapids, MI
LISA Data Storage Day: Latest Trends in Storage Networking: “Data Storage Day is a one-day event focused on the current trends in the storage industry. Registration is free as a way of introducing newcomers to the LISA conference.”

- Sept 22, LISA Data Storage Day, Downers Grove, IL
LISA Data Storage Day: Latest Trends in Storage Networking: “The goal of Data Storage Day is to explain the trends and developments in the storage industry in the language spoken by hands-on IT professionals.”

- Oct 23–26, SOSP 2011, Cascais, Portugal
23rd ACM Symposium on Operating Systems Principles: “The biennial ACM Symposium on Operating Systems Principles is the world’s premier forum for researchers, developers, programmers, and teachers of computer systems technology. Academic and industrial participants present research and experience papers that cover the full range of theory and practice of computer systems software.”

Other Happenings

- Sept 5
Freddy Mercury would have been 65 today.

- Sept 9
C creator Dennis Ritchie is 70.

- Sept 10
Space tourist Charles Simonyi is 63.

- Sept 27
Perl creator Larry Wall is 57.

- Oct 2
The Great Quux is 57.

- Oct 4
The Free Software Foundation is 36.

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

- Oct 5
Linux is 20!

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

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

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

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

- Oct 28
Former software executive Bill Gates is 56.

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

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

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

- Nov 1
Mitch Kapor is 61.

- Nov 8
Bill Joy is 57.

- Nov 6
Jerry Yang is 43.

- Nov 10
Bert Bos, co-creator of Cascading Style Sheets, is 48.

- Nov 10
Richard Brodie, creator of Microsoft Word, is 52.

- Nov 18
Pamela Kyle Crossley, historian and creator of SIMPLE, is 56.

- Nov 19
Dries Buytaert, Drupal founder and lead developer, is 33.

- Nov 22
Randall Schwartz is 50.

- Nov 22
PHP creator Rasmus Lerdorf is 43.

- Nov 22
And it’s Charles Simonyi’s wedding anniversary.

But Wait, There’s More...

Coming Attractions

This may be the last page, but that doesn’t mean it’s the end of the conversation. Keep up with what’s going on in the Pragmatic universe by subscribing to our newsletter and drop by the Pub again next month for more Pragmatism. We’ll keep a seat warm and a mug chilled and a candle burning in the window.

Coming Soon in PragPub

As soon as our inside man can talk, we’ll share what’s new in iOS5. We’ll see more installments of Venkat’s new series on Scala programming; an interview with David Hussman about going beyond Scrum, Kanban, and all other brand warfare; and another staff profile. There’s an article by Jonathan Rasmusson on self-inflicted scope creep; one by Adam Goucher on lightsabers, time machines, and other automation heuristics; an essay from Jeff Cohen on developer community values; and there are new articles in the works by Brian Tarbox, Tim Ottinger and Jeff Langr, Dan Wohlbruck, and John Shade.

Coming Soon on the Bookshelf

Venkat’s Programming Concurrency on the JVM: Mastering Synchronization, STM, and Actors is now in print. Agile Web Development with Rails, 4th Ed has been updated for Rails 3.1. And for something completely different: Cutting an Agile Groove, a video series with David Hussman, is about to release.

Right. But to really be in the know, you need to subscribe to our weekly newsletter. It’ll keep you in the loop, it’s a fun read, and it’s free. All you need to do is create an account on pragprog.com (email address and password is all it takes) and select the checkbox to receive newsletters.

While you’re waiting for the next issue of the newsletter or of PragPub to come out, you can follow us on twitter at @pragpub, @PragmaticAndy, or @pragdave. Or on Facebook at facebook.com/PragmaticBookshelf. Or email us at michael@pragprog.com.