PragPub 2011-05: Issue #23

Table of Contents

Features

- A CoffeeScript Intervention
by Trevor Burnham
Trevor takes us on a tour of some of the ways this hot new language improves on JavaScript.

- Trench Warfare
by Jared Richardson
Today’s software shops are often run like WWI military operations. It’s time to get out of the trenches.

- Catch the Pig!
by Brian Tarbox
When everything is crashing down around you, sometimes the best thing you can do is to let it crash.

- Agile Reflections
by Jeff Langr, Tim Ottinger
Jeff and Tim take a break from their recent articles on agile practices to reflect on their personal experiences with agile practices, and specifically extreme programming (XP).

- When Did That Happen?
by Dan Wohlbruck
How a hand-written document composed on a train ride drove computer architecture for half a century.

Departments

- Up Front
by Michael Swaine
On CoffeeScript, the illuminating power of a good metaphor, and a Sudoku solution.

- Choice Bits
The CoffeeScript controversy, Arduino feedback, misunderstanding the boiling frog metaphor, and other twittery.

- Guru Meditation
by Andy Hunt
A truly agile project team lives on the edge of chaos.

- Way of the Agile Warrior
by Jonathan Rasmusson
Imagining all the ways the system could fail can blind you to seeing how to make it succeed. Never be afraid to ask, “What if it just worked?”

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

- Shady Illuminations
by John Shade
John casts a jaundiced eye at the recent storm in the realm of cloud computing and introduces a bovine metaphor.

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 Bright Light of Metaphor
by Michael Swaine
Welcome to PragPub for May, 2011. Pull up a chair. We’re polishing metaphors today.

Mark Twain generally gets the credit for that line about the difference between the almost right word and the right word being the difference between the lightning-bug and the lightning. But Twain acknowledged that he got the comparison from Josh Billings. Twain made it his own, though, repeating it often. It’s a figure of speech that bears repeating.

And it’s when we are using figures of speech, particularly metaphor, that the exact right word really shines. I’d like to think that I selected the right word just then, the word “shine.” Because that’s what we use metaphor for: to shine light on some aspect of the subject. Anywhere there is complexity, metaphors are a powerful tool for shining light into the darkness. As people who write or talk about software, we need precise metaphors.

As it happens, several of this month’s writers employed vivid metaphors in their contributions to the issue. So I thought it might be worthwhile to focus a little extra light on their illuminating figures of speech.

Jared Richardson uses the metaphor of WWI trench warfare to shine some light on certain problems in software shops that lead to stagnation. Brian Tarbox uses a very different metaphor involving a pig to offer some enlightening advice on what to do when everything is falling down around your ears. Jeff Langr and Tim Ottinger reflect on over a decade of agile experience, and along the way have some bright things to say about the use of metaphor in XP and BDD (among other things).

John Shade’s essay this month is all about cloud computing, and you can’t talk about cloud computing without getting up to your eyebrows in metaphors. John doesn’t even try to avoid the metaphors. You can decide for yourself whether or not that’s a good thing.

Because metaphors can get you in trouble. “Done badly,” Tim says, “it turns the system into a series of odd puns and confusing turns of phrase.” And as Andy Hunt points out in this month’s “Guru Meditation,” “A model is not reality.”

Also in this issue, Trevor Burnham shows how CoffeeScript, the hot new language that he calls “JavaScript done right,” saves you from some of JavaScript’s nastiest traps.

Plus we have another computer history article by Dan Wohlbruck, Choice Bits, and the events calendar. There’s some nice feedback in Choice Bits on last month’s Arduino issue, and below you’ll find the solution to last month’s Arduino-themed quiz.

I hope you enjoy the issue.

Solution to Last Month’s Quiz

Last month we presented another Sudoku puzzle that used letters instead of digits. In keeping with the theme of that issue, the nine letters were MYARDUINO. Here’s the solution:

A

N

I

M

U

R

Y

D

O

O

R

Y

I

N

D

M

A

U

M

U

D

Y

O

A

I

R

N

I

D

N

U

A

Y

R

O

M

R

O

A

D

I

M

U

N

Y

U

Y

M

O

R

N

A

I

D

D

A

R

N

M

U

O

Y

I

Y

I

U

R

D

O

N

M

A

N

M

O

A

Y

I

D

U

R

Choice Bits

Top 11 books, tweets from the coding life, and the CoffeeScript flamewar...

Who knew that CoffeeScript was so controversial?

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^

2

Agile Web Development with Rails

2v

1

iOS Recipes

3^

5

Crafting Rails Applications

4^

6

Programming Ruby 1.9

5v

3

The RSpec Book

6^

9

Seven Languages in Seven Weeks

7^

NEW

Test Driven Development for Embedded C

8^

NEW

Code in the Cloud

9v

4

Programming Concurrency on the JVM

10^

NEW

The Definitive ANTLR Reference

11^

NEW

Learn to Program

Wake Up and Smell the Flamewar

Rails creator David Heinemeier Hansson (dhh) announces, “Rails 3.1 will ship with CoffeeScript… in the box for use with the new asset pipeline. It’s badass.” CoffeeScript, if you haven’t heard, is JavaScript done right. It civilizes JavaScript, letting you write clean, readable, powerful JavaScript code. Understandably, this announcement is greeted with enthusiasm.

Rails 3.1 moves to Coffeescript. Is Slashdotted. News at 11. — telemachus

Wow... crazy github comment war breaking out on the coffeescript commit in rails. — ajkovar

Freakout on CoffeeScript in Rails 3.1: bit.ly/g6fMEL — rtwomey

88 notifications on Github, apparently the coffeescript flamewar is alive and well. — dfnkt

The coffeescript-rails discussion (http://bit.ly/gKI5Vi) almost makes me jealous. Haven't seen such passion in .NET land for a while. — martijnboland

That Rails Coffeescript thread is out of control. I can't view the thread without Firefox causing my machine to hit swap: http://j.mp/g6fMEL — damncabbage

I’M JUST HERE FOR THE VIOLENCE! #rails31 #coffeescript #github #comments — ziromr

I don’t even know what coffeescript is. What are you kids fighting about now? — kch

The Cons

So... CoffeeScript. I don’t get it. — jlecker

Are people weary of using #coffeescript for js, #haml for html and #sass for css in #rails? All cool stuff, but nearly too meta for me. — danistheremix

I’m not really into all this meta stuff; SCSS, Coffeescript, HAML. Just do the real thing, and do it good. #Rails3.1 — rienswagerman

Rails 3.1 coming with CoffeeScript and Sass? Cool. Making them the defaults? Kind of crazy. (And what about LessCSS?) — lof

Making SASS and Coffeescript default in Rails 3.1 is a horrible decision! This is how/why merb was born… stupid & rushed decisions. #rails — Mephux

#CoffeeScript—write in one language, debug in another! #thejoysofcodegeneration — twitinsin

The news of Rails 3.1 supporting CoffeeScript reminds me how angry CoffeeScript makes me... I can’t understand how people would prefer it. — enormego

The Pros

I for one welcome my new CoffeeScript overlords. — joshpeek

Love that Rails 3.1 is pushing the envelope with CoffeeScript. Please continue this and ignore the haters. — mperham

Seems obvious to me. Javascript usually becomes an unintelligible mess, and CoffeeScript is JS turned into Ruby. Perfect fit. — enormego

Also missing from the conversation is that Firebug + other tools have plans to support tracebacks to CoffeeScript src. — BrendanEich

CoffeeScript by default in Rails? Bloody brilliant. Does anyone who’s ever (really) used CoffeeScript have a problem with this? I don’t. — darthapo

Seriously playing with coffeescript for the first time. Very impressive, and smoother integration with #nodejs than I expected. — felixge

CoffeeScript is all kinds of awesome! — bitsushi

default != requirement #rails3.1 #coffeescript — vianaweb

@jashkenas Congratulations! Getting CoffeeScript included in Rails is an honor. You should be proud. CoffeeScript is a beautiful language. — gixug

The Final Word

dhh gets the final word, because are you going to tell him otherwise?

I love how most of the arguments against CoffeeScript were the same we faced against Ruby back in the day. It’s “cute,” “toy,” “just syntax.” — dhh

Beyond the Final Word

Fearing irrelevance, Rails drops Ruby, moves to #CoffeeScript and #Node.js for 3.2 release. — FakeHackerNews

This Coding Life

I am. Therefore I tweet. — @unclebobmartin

When @livia wants bagels, I go fetch bagels. That’s how I do. — @biz

Starting to think I need a new business plan.... — @RonJeffries

I’m pleased to announce I’m creating an exploratory committee. What I’m exploring, however, remains a secret. — @hugs

We all thought that the first time we did something was the first time it had ever been done. — @scottknaster

cd / ; sudo ln -s Applications Apps — @cdespinosa

Terrifying deadline looms. Time to redesign my blog! #productiveprocrastination — @ginatrapani

Even though I did get my earring for business reasons (credibility with Ruby hepcats), I manfully refuse to count it as a business expense. — @marick

Why is Twitter recommending a bunch of hockey tweeters for me to follow? Has the machine developed a cruel, surreal sense of humor? — @gvwilson

Hell is other people’s concurrency. http://wp.me/p1gR5-uw — @therealadam

Meaning no disrespect to either tradition, Iroquois dream-guessing might be preferable to SDLC requirements analysis. http://bit.ly/eCuZBl — @marick

“We can’t estimate the time for a task in software development because the nature of the work is creating new knowledge.” blog.patchspace.co.uk/why-cant-devel… — @dalmaer

In 90s, mgr tried to used boiling frog metaphor to explain how team was just fine w/ pressure increase, unaware froggie dies @ story end. — @tottinge

I have the best wife in the world. — @bphogan

@bphogan Let me guess: She tore apart your laptop, soldered a loose connection to fix the issue and overclocked the CPU for you? — @rit

Fan Mail

Cool. PragPub has a whole issue on Arduino. http://bit.ly/gSfMMx — @MilesForrest

This month’s PragPub has 28 pages dedicated to Arduino. It’s like they’re reading my mind. http://www.pragprog.com/magazines — @dlkinney

Best issue yet: Maik Schmidt writes about Advanced Arduino Hacking in the April PragPub. http://cot.ag/i2dfg3 #arduino (via @pragpub) — @jerrykuch

Been trying to tell myself that I don’t have time for Ardiuno hacking, and then @pragpub had to do this: http://j.mp/fdad0m — @squarepegsys

Great April PragPub issue with an Arduino focus! And thanks for using Fritzing. #pragpub #Arduino #FritzingOrg — @gnozicka

John Shade’s #oracle #sun illuminations in @pragpub well worth a read. cot.ag/i2dfg3 — @stevencarrie

Chad’s Japanese has Improved Greatly

Hey look, it’s my @pragpub interview in Japanese! http://bit.ly/eKfXqV — @chadfowler

This month we followed Dion Almaer, Peter Aronoff, Bitsushi, Martijn Boland, Jonathan Buchanan, Steven Carrie, Dan Cruickshank, Brendan Eich, enormego, Chris Espinosa, Miles Forrest, Chad Fowler, Luke Francl, Felix Geisendörfer, GJN, Pawl Grayham, David Heinemeier Hansson, Brian Hogan, Mike Hostetler, Rob Howard, Jason Huggins, Ron Jeffries, Adam Keys, David L. Kinney, Scott Knaster, Alex Kovar, Jerry Kuch, James Lecker Jr., Brendan W. McAdams, M@ McCray, Brian Marick, Uncle Bob Martin, Tim Ottinger, Josh Peek, Mike Perham, Biz Stone, David Stone, Rien Swagerman, Gina Trapani, Ryan Twomey, Evandro Viana, Dustin Webber, Greg Wilson, Caley Woods, and ziromr. You can follow us at www.twitter.com/pragpub.

Guru Meditation

Uncomfortable with Agile
by Andy Hunt
Andy wants you to be uncomfortable.

It’s been ten years since we coined the term agile. Are you finally comfortable with being agile? If you are comfortable, then that’s too bad, because it means you’re doing it wrong.

A truly agile project team lives on the edge of chaos.

Not slipping back into a comfortable, somnambulant stupor, and not pitching forward over the edge and into the dark abyss of chaos. Do too little and you stagnate, too much and you crash.

Instead, you should have that uncomfortable feeling of tipping back in your seat, just before you lose your balance and catch yourself. That’s what agile is. I think the best definition I’ve seen that captures this spirit of agile comes from Dr. Patricia Benner, author of From Novice to Expert. She’s speaking on the nature of expertise; how to train people in real-world practices (clinical nursing in this case), and notes that:

“Practices can never be completely objectified or formalized because they must ever be worked out anew in particular relationships and in real time.”

That is, you can never completely define agile, or its practices, because they are constantly evolving to meet specific needs in specific circumstances. Agile should be ever-shifting, ever-changing, ever-responding to change in context. You need to keep thinking, keep adjusting.

What Is Agile?

In the crush and press of the exigencies of the day, perhaps we’ve forgotten some of the theoretical underpinnings of agile methods. I’d say agile includes ideas from:

- Chaos Theory

- Kaizen

- Systems Thinking

- Risk Management

- Return on Investment

and that we’ve probably lost sight of most of these notions.

Some of the key ideas from chaos theory include the observation that people, teams, and software products are inherently non-linear systems. That means that cause-and-effect can be impossible to isolate and identify. That’s not a flaw in your team or project, it’s a fact of life. So is emergence, that nearly-magical phenomenon where complex systems and patterns spontaneously emerge from simple interactions.

Have you experienced emergence lately? In your architecture or team dynamics?

Then of course there are the well-known ideas from Kaizen, emphasizing using quick feedback to make continuous changes, and so to create an environment of continuous improvement.

Are you using feedback to make continuous changes to your product or process?

From Systems Thinking, we came to the idea of people as First-Order Components of the systems we’re building. We’re not resources, we’re not staffing, we’re people, and we’re as much a part of the system as the database is. We realized that it was up to us; that individual practices, special tools or processes wouldn’t save us.

So are you investing in the people on your team? Buying them books (hint, hint)? Sending them to conferences, or training courses? Are you hosting brown-bag lunches to discuss technology and development practices?

Software development is risky business. There are many different ways to manage risk, and the agile way favors minimalism as a core approach. Timeboxing, whether in an iteration or in a design meeting, is a very effective way of minimizing risk. Another way of minimizing risk is to choose to write less code, or even better, not to write code. After all, the line of code not written is always correct. But you already manage risk this way, right? You’re constantly thinking about minimizing risk, aren’t you? You’re timeboxing everything, from iterative deliveries and meetings to how long a team member can be stuck on a bug without asking for help?

Similarly, in addition to minimizing risk, you want to maximize business value—the stakeholders need to see a positive Return on Investment (ROI). That means delivering small bits of functionality frequently that help the business make money.

Notice that each of these underpinnings of agile demands constant attention and thought. You can’t just run with a set of “standard” practices on autopilot.

Practice on the Edge

What does this mean in practice? What do you do now? I can’t tell you. No one can tell you. Only you can discover the answer for yourself. But I can give you some hints.

It means you should find yourself thinking. Being skeptical. Re-evaluating. You’re doing some set of practices—are they working? Are you getting value for your effort? Is everyone on the team growing and advancing in their career?

There are definite warning signs to watch for:

- Sloganization—Speech becomes so sloganized that it becomes trivial and eventually loses meaning entirely. Watch for all your favorite agile buzzwords and see if they are being used as meaningless jargon.

- Confusion between following rules and exercising judgment—When is it OK to break the rules? All the time? Never? Somewhere in between? How do you know? Some rules probably should never be broken (e.g., check everything into version control, have unit tests, settle on a fixed iteration length) and others may be more flexible (pairing conventions, specifics of customer involvement, etc.).

- Confusing the model with reality—A model is not reality. Thinking that an agile project is “supposed to go this way” might be a trap. The only thing it’s supposed to do is succeed. Everything else is up for grabs.

- Demanding conformity—The same standard may not always apply equally in all situations or with all people. You don’t want a bunch of monkeys banging on typewriters to churn out code. You want thinking, responsible developers. Don’t reward herd behavior or devalue individual creativity.

- Spelling out too much detail too soon—Premature optimization is indeed the root of all evil, whether it’s in your process or your code. Tying things down too early is not agile, and detail can act like instant glue. Patience.

- Oversimplification of complex situations—“Just follow the process.” If it were that easy, anyone could do it. But they can’t. Every project, every situation, is more complex than that. “All you need to do is...” or “Just do this...” are invitations to failure. Don’t fall for it.

Wachet auf

Time to wake up! Time to shake things up. Refactor your process. Refactor your code. Refactor your customers. Refactor your priorities.

If you find yourself going through your project on automatic, without thinking about what you’re doing, then you aren’t thinking. You might want to look to that first.

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

Expecting Failure
by Jonathan Rasmusson
In his latest lesson in agility, Jonathan looks at the balance between imagining how the system might fail and keeping in mind how it should succeed.

When building a system, you can either take the view that things are going to work, or that they are going to fail.

You need to be defensive when building systems, but you want to avoid overdoing it. When you get overly defensive, you get product out the door later and you raise your total cost of ownership by creating an overly complex, difficult-to-maintain system.

In this month’s column I want to tell you the story about how a team I was part of leaned too far in the defensiveness direction, and what we did to bring it back.

A Messaging System

The team had an architecture that looked something like this:

Messages would come in one end, and transformed messages for specific recipients would come out the other. Simple enough.

Not surprisingly the legacy system we were replacing had “issues” (mostly around things blowing up). So when it came to replacing it, there were strong opinions concerning error handling and logging. We started off expecting things to fail.

Well, it didn’t take long before we had so much error handling and logging that it became hard to see (and troubleshoot) what the system was actually doing. We were so afraid of failing that it felt like we forgot what we were building in the first place.

Why were we being so timid? Were we justified in our level of skepticism? Was all this support code and logic really necessary? It felt wrong and it felt strange. Yet we persisted.

Then one day, someone asked:

What if messages came in one end, and the correctly transformed message came out the other? What if we stopped expecting failure? Don’t accept any failures. Just make the bloody thing work. What would that mean to our approach to the system?

What a beautiful, simple, powerful question. Asking ourselves “What if it just worked?” got us looking at the system in a new light.

Instead of it expecting it to fail at every step, we now expected it to succeed.

We realized we could get rid of a lot of errors up front by simply not letting them into the system in the first place.

- What if we tightened up validation on messages coming in?

- What if we rejected all messages that didn’t conform and notified production operations instead of trying to handle it ourselves?

If we coded and tested the system right in the first place, we could fix a lot of the core problems that riddled the legacy system instead of expecting and handling them when they happened.

I know, it seems obvious now. It is obvious. But somehow it wasn’t so obvious at the time. Yet this simple, obvious shift in perspective profoundly changed how we looked at the system.

Instead of expecting failure, we started to expect success. This simplified and lightened our code base, while leaving just enough checking there to let us know if things went wrong.

So what, should we stop thinking about failure and just focus on the happy path?

No, not quite. Our systems are going to fail, and we need to handle those failures. All I am saying is that if we only focus on failure, we can really overengineer and overcomplicate things. That’s expensive, because then we need to carry the baggage of this overengineering around with us forever, making the system harder to maintain and to change.

It’s a balancing act. We do need to expect failure. We just don’t want to overengineer for it to the point where we lose sight of what we’re really doing. Which should be delivering valuable, working software to our customers.

Hardening the System

Not wanting to leave you with just a story, I want to offer you two surefire ways I’ve seen teams harden their systems to ensure that they aren’t overly confident before rolling into production.

Work with Real Data

When you throw real, live production data at your system, good things start to happen.

1. You discover where the holes in your data model are.

2. You discover which of your assumptions are valid, and which are wrong.

3. You see what edge data cases you missed, and discover that French characters don’t always encode the way you’d expect them to.

There are few better things that you can do to see how your system is going to handle going live than to throw some real data at it.

The other thing you can do is to get something into production.

Get Something into Production

You don’t have to flip the switch and really “go live” (though you obviously will at some point). What I am talking about is getting your system into production before it needs to be there.

This does a couple of things for you:

1. You can throw some of that data at it and see how it behaves.

2. You can work all the kinks out of your automated build and deploy scripts.

3. You can work out all the network and infrastructure issues.

But best of all, you get into the habit of releasing. The more you push to production, the less scary it is. Do it enough and it will soon be like breathing.

Context Is Everything

Take what I am saying here with a grain a salt. You still have to judge for yourself what level of error handling and defensiveness is right for your application.

Failed hard drives and cut fiber lines may be uber rare occurrences for you and me, but failed drives happen regularly for Google, and any cable company will tell you fiber lines get cut all the time.

Failures happen. But if you can start by keeping things simple, and build things so that you expect them to work, you can keep your eye focused on what the system really needs to do, and not get lost in all the thousands of things our creative minds can imagine going wrong.

Expect failure, but keep the correctly performing application clearly in mind. Use real data and get something into production. That’s how you’ll find the failures and get to the correctly performing application most efficiently.

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.

A CoffeeScript Intervention

Five Things You Thought You Had to Live with in JavaScript
by Trevor Burnham
Sure, CoffeeScript is as easy as ABC. But Trevor’s prepared to take you all the way to Z.

Like any sane programmer, I was initially wary of CoffeeScript. How could a little syntactic sugar sprinkled over JavaScript possibly justify the extra compilation step?

But after playing with CoffeeScript for just a few days, I knew I’d never go back. The syntactic sugar was only the beginning. I was writing code more quickly and with fewer bugs, because everything was so much clearer. It became much easier to tap into the good parts of JavaScript—and there are many—while steering clear of the bad. I’ve listed a few of those nasty bits below, along with some of the ways CoffeeScript makes it easy to avoid them.

1. Global Leakage

JavaScript newbies naïvely assume that var x means “I hereby declare a variable named x.” In fact, var isn’t so much a welcome mat as it is an electric fence, preventing x from roaming beyond the current scope. If you write

x = 'Hello from the JavaScript Nation!';

and there’s no var x declaration in a surrounding scope, then x is automatically a global. Make the same mistake in two parts of your app, and one global will overwrite the other, creating an infuriatingly hard-to-isolate bug.

Even seasoned pros sometimes make this mistake, especially when chaining variable declarations: var a = 1, b = 2 declares two variables in the current scope, while var a = 1; b = 2 assigns a value to the global b.

The CoffeeScript Way

With CoffeeScript, all variables are automatically scoped. So when you write

x = 'Welcome to CoffeeScriptville!'

you can rest assured that you aren’t messing with any globals. Not only that, but x is automatically limited to the current file thanks to an anonymous function wrapper—a wise practice in JavaScript, automatically provided by the CoffeeScript compiler.

2. this Is Something Else

There may be no more common source of confusion in JavaScript than the this keyword. You do a simple callback

tinman.prototype.loadBrain = function() {

this.brain = 'loading...';

$.get('ajax/brain', function(data) { this.brain = data; });

};

only to find the code silently failing—because this in the callback that receives the data doesn’t point to the same object that it points to outside of it.

The CoffeeScript Way

First off, the this keyword has an alias, @, to make it more visually distinct from ordinary variables that lack its curious contextual shenanigans.

Second, writing a function that’s bound to the current context—meaning that this/@ inside of the function has the same value as outside of it—is as easy as using => (the “fat arrow”) instead of the usual -> symbol to declare the function:

tinman::loadBrain = ->

@brain = 'loading...'

$.get 'ajax/brain', (data) =>

@brain = data

3. Condensed Conditionals

The ternary operator holds a special place in JavaScript: Unlike other conditional structures (if, switch), it returns a result. That means that coders face a choice between the impenetrable terseness of nested ternaries like

closestEdge = x > width / 2 ? 'right' : x < width / 2 ? 'left' : 'center';

or a repetitive logic tree like

if (x > width / 2) {

closestEdge = 'right';

} else if (x < width / 2) {

closestEdge = 'left';

} else {

closestEdge = 'center';

}

The CoffeeScript Way

All conditional statements in CoffeeScript return their result. That gives us the clarity of the second approach, without the mindless repetition:

closestEdge =

if x > width / 2

'right'

else if x < width / 2

'left'

else

'center'

We could make closestEdge a function by simply adding -> after closestEdge =, since CoffeeScript functions automatically return their last expression.

4. Functional Asynchronicity

A popular test of “Do you really understand JavaScript?” goes something like this:

for (var i = 1; i <= 3; i++) {

setTimeout(function() { console.log(i); }, 0);

}

The result:

4

4

4

Why? Well, setTimeout—even when the timeout is set to 0—causes the given function to run only after the loop has run. And when the loop has run, i is 4 (since the loop ended when the condition i <= 3 failed). So there’s only one i, and that i is what the function passed to setTimeout sees.

To capture each value of i, you have to wrap the inside of the loop in a function and pass i to it:

for (var i = 1; i <= 3; i++) {

(function(i) {

setTimeout(function() { console.log(i); }, 0);

})(i);

}

The CoffeeScript Way

While CoffeeScript doesn’t automatically capture the values of variables in loops (as this would break ordinary loop functionality like break, continue, and return), it does provide the do keyword to succinctly create capture functions:

for i in [1..3]

do (i) ->

setTimeout (-> console.log i), 0

Now you get

1

2

3

5. Repetition, Repetition

I’ll let the code speak for itself:

x = sprite.x;

y = sprite.y;

css = {

opacity: opacity,

fontFamily: fontFamily

};

function(request) {

body = request.body;

status = request.status;

// ...

}

The CoffeeScript Way

Each snippet above becomes a one-liner, thanks to pattern-matching:

{x, y} = sprite

css = {opacity, fontFamily}

({body, status}) -> ...

Conclusion

CoffeeScript isn’t just about prettier code. It’s about more agile code. It’s about being more confident that you got it right the first time, while knowing that you could change it all in just a few keystrokes.

If good design patterns and rapid iteration are up your alley (and you are reading PragPub, aren’t you?), you owe it to yourself to give CoffeeScript a shot. Even if you decide it’s not for you, you’ll come away with a better understanding of JavaScript.

(Of course, if you’re upgrading to Rails 3.1, you have no choice in the matter!)

Trevor Burnham is the author of CoffeeScript: Accelerated JavaScript Development from The Pragmatic Bookshelf. He is also a full-stack web developer with a passion for new technologies, and the founder of DataBraid, a startup developing scientific computing tools that support remote collaboration. When on Twitter, he goes by @TrevorBurnham and @CoffeeScript. When offline, he’s usually in Cambridge, MA. Send the author your feedback or discuss the article in the magazine forum.

Trench Warfare

Is Your Software Project in the Trenches?
by Jared Richardson
Today’s software shops are often run like WWI military operations. It’s time to get out of the trenches.

Trench warfare has been used for centuries, but it has become firmly associated with World War I. Although used throughout the ages, sometimes with great success, trenches never became a standard military tactic. Then, in WWI, there was a perfect storm of technological advancements that made trenches an essential front-line military doctrine and a killing field for the average soldier. Sadly, that’s why they’re so similar to today’s software shops.

There were two key factors to the popularity of trenches on the front lines of WWI. The first was the machine gun. The ability to install a gun emplacement that could mow down soldiers required some sort of defense. Trenches were the cheapest way to escape the bullets, and dirt was cheap. There were only two things the front line generals had in abundance: dirt and soldiers. So they dug trenches until they were close enough to a target (such as a machine gun nest), then soldiers poured out of the trench and overran the position. In terms of human life it was a costly maneuver, but effective. It was impossible for a single gun emplacement to shoot that many men.

That leads us to the second advancement that made trenches popular: concertina wire. We’ve all seen this nasty form of barbed wire. It’s a curling, circular wire fence that can be quickly uncoiled to cover a large area. Today we usually see it on the top of a chain link fence at a prison. On the front lines of WWI, it was stretched out on the ground. When soldiers poured out of their trenches, they’d get tangled in the concertina wire and the machine guns would mercilessly mow them down before they could escape.

The machine guns and concertina wire lead to enormous trench systems and an enormous stagnant front. Thousands of men massed within sight of each other, but dared not lift their heads out of the trench. Neither side could make significant progress, so the troops sat in the same trenches for weeks, or even months, at a time. In hindsight, the results were rather obvious: the foul conditions in the trench lead to “trench foot,” lice, dysentery, and an assortment of other nasty side effects. It became a war of attrition and your own trench became the weapon that was beating you into the ground.

In the Trenches

All of which reminds me of so many software shops today. Recently, I was speaking to a Fortune 500 company about a full-time job as a process guru. I’d be helping to change the way their developers worked from top to bottom. We’d be affecting the efficiency and productivity of thousands of developers. This company couldn’t deliver products on time, quality was bad, and morale was low. They needed someone like me. Obviously I wasn’t the only person who could fill the role, but they needed someone to work in that capacity and they needed them quickly.

As we were, I thought, about to close the deal, I was told that they were having trouble justifying my position, but they could start me tomorrow if I had any “web 2.0 coding experience.” In other words, instead of hiring someone who would step back and look around and try to find a way out of the trench, they were only interested in hiring someone else to jump in.

A depressing theme with many of today’s software shops is the need to only make two kinds of hires. The first is a developer. After all, a developer codes, and that makes money! The second hire is an MBA-style manager. This manager is an HR-type who handles budgets, spreadsheets, and politics.

Then someone like me comes along. I’ve got a development background and I’ve managed as well, but today I don’t do either. Instead I work with a team to see where the problems are. I sit with them and look for the areas that have become blind spots, and then find ways to solve those problems. I’ve saved large organizations substantial amounts of money by improving how their teams work. But I’ve usually done this by hiring in as a developer or manager. It’s a rare company that hires someone to improve their process. They’d much rather sit in the trenches and inspire their soldiers to leap out in the face of concertina wire and machine guns, sure that with the right mix of courage and moral fiber, this time they’ll finally ship that product!

As we look around, this attitude seems so… stupid. They seem to think that by trying harder they’ll succeed. How many of our favorite sports teams don’t have coaches, but ask their professional athletes to try harder? Note: I’m not talking about managers, but coaches. Olympic-level track and field athletes have individual coaches. What do they know that software companies don’t?

Companies spend an insane amount of money on software teams. Many spend millions of dollars on their people, then take a thousand steps backwards to a Victorian attitude that their teams are smart enough to solve every problem. It’s quite likely you’ve hired some very smart people, but since you’ve had them heads down in the trenches for the last several years, it’s possible they’ve missed a few trends in software. Buying a book or two, or allowing a senior developer to attend a conference is fine, but it doesn’t equate to training your team—any more than granting shore leave to an officer equated to a better rested platoon.

And before this starts sounding like an ad for my services, I have a full-time job and am not on the market. I’m just trying to address a glaring blind spot I’ve seen in far too many companies, if not the industry as a whole.

The Trench Shop

So let’s step back a bit and think about trenches. What does a trench shop look like? I realize that there’s no real comparison between someone dying in a killing field and burning out at our day job, but we can still draw some meaningful parallels. It’s a metaphor. Let’s see what we can get out of it.

- Trench companies don’t want strategic hires. They want more developers who will work overtime until they burn out. They don’t want to hire anyone who can or will think, they want people who already know technology XZY so they can hit the ground running from day one. (That’s an interesting thought… beware of companies who always have openings. Why do they ~always~ have openings?)

- After spending too much time with your head down in the trenches, you start to notice little problems. Like rotting feet. Your builds are always broken, but that’s okay. You’re not shipping this year anyway.

- You’ve heard about newer, more productive technologies, but don’t have time to learn them. You’re too busy working, so you can’t learn. Hmmmmmm…..

- There’s a local conference, but you can’t go. You’re too busy working that week. And that weekend. Don’t even think about asking to attend a regional or national event. That would just be silly.

- You know that things would run smoother with an automated build and deployment, but that feels like a pipe dream. Something people write about in articles and books, not something people do in real life.

- You know that decent test coverage would save you hours in debugging, but you’re so busy debugging, you don’t have time to write the tests.

I could go on, but the real problem here isn’t the developers; it’s management. They continue to hire trench grunts and smack down anyone who raises their heads. We’re already dealing with constantly shifting operating systems (another service pack anyone?), newer versions of browsers and languages, and customers that constantly change their minds. Do we also have to deal with tactics that our military discarded nearly a hundred years ago?

If you’re happy putting your head down in the sand and being an ostrich coder, then stay in a trench shop. Enable these bad managers to continue squeezing profits out of your blood and ulcers. Or—here’s a thought—get out. The economy is bad, but most software shops I know are still hiring developers. We’re fortunate enough to be in a market segment that’s still growing, and there are jobs available. Until we stand up and get out of the trench, no one will be forced to consider it a bad practice.

As long as it’s winning—I mean profitable—why change?

Jared Richardson is an author, speaker, and developer who lives in North Carolina. He started Agile RTP, now the largest Agile user group in the United States with nearly 700 members. His first book, Ship It! A Practical Guide to Successful Software Projects, is a best seller and is now in seven languages. He spends his time playing with his family and recently, rather by accident, became a backyard chicken farmer. You can find him on the web at AgileArtisans.com. Send the author your feedback or discuss the article in the magazine forum.

Catch the Pig!

A Metaphor for the Beleaguered Developer
by Brian Tarbox
Brian sets out in search of an illuminating metaphor for out-of-control software projects and finds himself offering some wise but contrarian advice.

I’ve been trying for a long time to find a proper metaphor for the kind of perpetual emergency mode that many of us find ourselves in.

I had the feeling that emergency mode had become so pervasive and typical that many people had lost sight of the fact that it was not supposed to be a long-term thing. When everything is an emergency and everything is top priority, the world ought to feel wrong somehow. It should remind you of that scene from The Princess Bride where Inigo says, “I do not think you know what that word means.”

The problem is that we’ve been in that mode for so many years that the strangeness has worn off and we simply accept coding up the hack... perhaps saying that we’ll fix it later (in that mythical tomorrow that is less hectic than today).

So I thought that perhaps if I came up with a good metaphor I could remind us that crisis mode was supposed to be an occasional state. I hoped that this metaphor might remind people that the behavior that got you into the crisis was unlikely to get you out of the crisis!

So here is my metaphor. I hope you like it.

The China Syndrome

Imagine you are in a wedding gift store full of expensive breakable crystal... with a small pig. That pig is running around and crashing into things. Champagne flutes, crystal vases, precious china, and expensive cookware are heading for the floor.

Faced with this situation, most of us are going to do one of two things. Some of us will follow the pig, trying to catch the crystal pieces before they hit the floor and break. We catch each item, if we can, put it gently down, and then dash after the pig to try to catch the next item. Others will sit on the floor amid the chaos with a tube of Super Glue trying to repair the broken items.

Metaphorically.

I’m going to make a crazy suggestion. And I know it’s crazy because decades’ worth of managers and co-workers have assured me that it’s a crazy suggestion. Here is the suggestion:

Forget the crashing items for a moment and catch the pig! That’s right, let the next couple of vases, flutes, or baubles smash on the floor. Chances are that you will not appreciably increase the entropy of the system because it’s probably already pretty chaotic. There is a chance, however, that you will actually catch the pig and prevent the injection of still more chaos!

That’s my suggestion and, as I say, it has met with resistance when I’ve advanced it over the years.

One technique that I’ve found somewhat helpful, though, when people object to this approach, is to ask this simple question: “Do you think that there will be a day any time soon that is less busy than today?” Most people, especially those most inclined to stay in the chaos, will shake their heads and say that they cannot imagine the business ever relenting. So the decision changes from “Shall we do the right thing today or tomorrow?” to the more honest question “Shall we do the right thing today or never?”

This is similar to the advice Joel Spolsky gives about hiring: “After interviewing a candidate the only two answers allowed are ‘Hell yes’ or ‘No.’” When it comes to picking a co-worker, there is no maybe. And when it comes to quality there is no tomorrow.

That level of honesty tends to shake people up and sometimes scares them enough to reconsider even such crazy ideas as letting the baubles break—and catching the pig.

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

Agile Reflections

A Dozen Years or so of Agile Development Practices
by Jeff Langr, Tim Ottinger
Jeff and Tim take a break from their recent articles on agile practices to reflect on their personal experiences with agile practices, and specifically extreme programming (XP).

Recently we’ve been running a series of articles on agile practices by Jeff Langr and Tim Ottinger, the authors of Agile in a Flash. This month, Jeff and Tim shift gears to reflect on their personal experiences with agile practices and specifically extreme programming (XP). In these short reflections, Jeff and Tim share how XP has changed their professional lives.

Jeff: I found out about extreme programming at a developer’s conference in San Jose in 1999, where I attended a talk by Kent Beck, who I’d followed in the Smalltalk world. We had tried spiral at MCI a few years prior. I’d loved its incremental/iterative cycles, but had struggled with how to keep it from degrading over time. XP immediately felt right to me. My first thought was, “Oh, holy crud, this is how you make it work!” A dozen years later, the most enjoyable projects I’ve ever been on have been XP efforts.

Tim: I was a Usenet denizen back when Usenet was the “big thing.” I was on the C++ and object-oriented groups when Kent and company started talking about this wild and crazy new way of developing software called XP. It sounded daft at first blush, but the more we discussed it the more it spoke to me. It was years later when I finally converted to XP. It remains a brilliant and counter-intuitive system that works.

Continuous Integration (CI)

Tim: Before continuous integration, I remember suffering through “hell week”—or “hell month”—when all the developers tried to get their code to work together, and QA tried to find the seams where disparate changes created side-effects and failures. No other single practice improves a software department as much as CI. It smooths the process, adds predictability, and makes continual testing possible. It helps draw a collection of developers together into a team all of the time, not just in the pre-release crunch. It creates the necessary context for the other practices to produce value.

Jeff: From the converse standpoint, CI requires other key practices to make it work. First, it falls flat without the tests—frequent integration causes too many problems without controls to let developers know that their change didn’t integrate with the rest of the code. Also, in settings where I’ve seen teams use a CI server to track a build but had few or no tests, the developers generally ignored it since it told them little about the health of the system. Finally, frequent check-ins create more clashes in poorly designed systems, so we’re driven to build better systems with more cohesive classes. CI is a great way to work, but is even more valuable when combined with these other agile development practices.

Test Driven Development (TDD)

Jeff: Agile or no agile, XP or no XP, TDD is a fantastic practice that continues to teach me endless lessons. Equally thrilling is seeing the light bulbs come on in peoples’ heads as they take up and embrace the practice. A favorite encounter was revisiting a team who’d shipped a 100,000 line Java application. The stats on the wall told one story—monthly product defect counts were 0, 3, 1, 2, 1, 1, 4, 2, 0, 1, 0, 0. More gratifying was my discussions with team members, all very proud of their work, and emphatic that their use of TDD was what had made them successful. I go faster with TDD in the long run, and it’s fun—what’s not to like?

Tim: It’s funny how much experience exists in the world regarding TDD, and yet how controversial it has remained. It is not intuitive that you’ll make better (faster, steadier) progress by writing tests first, but it is so. It is not intuitive that writing tests first is important, yet it produces better tests and more manageable code. TDD is not a substitute for design or algorithm analysis, but it allows us to explore design and algorithms. The act of writing tests first is a powerful boon to developers, nearly equal to the value of having copious tests. Even so, it is one of the points that must be constantly defended, sold, and re-explained—at least to people who have not tried it long enough to get a handle on it. Maybe the biggest lesson I learned from TDD was not to prejudge, but to immerse myself in a practice before judging its value.

Design Improvement

Tim: I have been an object-oriented nutcase for many years. Before I heard Robert Martin explain his first principle, or dug through my first copy of Structured Programming, I knew that we weren’t doing things as well as we could and that the problem was in our daily work instead of our closed-door architecture meetings. We weren’t going wrong from the start, we were steering wrong as we traveled. Just as cruft and crud are emergent, a clean design can be emergent. It’s all in the small steps and paying attention to the shape the code is taking.

Jeff: I think continual design improvement through refactoring is one of the hardest technical practices to get right. Out of the hundred-plus systems I’ve seen where the developers employed TDD, the code was refactored really well in less than a handful. Over time, poor design—lots of duplication, poorly structured and otherwise difficult code—is what will slow you down most from a technical standpoint. It’s easy to see why—who hasn’t spent countless hours wallowing through convoluted code in an attempt to simply figure out what it’s supposed to be doing?

Coding Standard

Jeff: Really, having a standard is agile? It’s foundational to me, but there are plenty of shops where self-absorbed developers take pride in bucking standards at every possible turn. I’ve seen too much pointless waste from lack of standards, coding or otherwise. Wasted time arguing, wasted time understanding each others’ code (little bits of discordance add up to significant irritants over time), wasted time reworking other peoples’ code, wasted pairing sessions, and no end of increased problems due to the silos that insufficient standards create. Before you can be a true team, you have to learn how to agree on a few key things.

Tim: My old naming paper ended up in a lot of coding standards, so it’s unsurprising that I’m in support of standards. The change that agile brought me was an insistence on minimalism. We wrote style guides and programming tutorials and recipes and pontification into our tomes of style, always hoping our effort was not wasted. It always was. Instead, a more agile way of programming proved possible with a one-page guide and a collective understanding of how code should be. Less is more.

Collective Code Ownership

Tim: Collective code ownership is another of those “in the large” improvements. When authorship matters and individuals “own” modules, you would expect programmers to make changes more quickly. And it may be true “in the small.” But a person can work on only one thing at a time. In the large, requests for changes to a given module will pile up and create large-scale delays. Collective ownership also attacks the “culture of blame” because each developer’s work is mingled with the work of all the others. This particular value has been close to my heart even before I heard of “agile” or “XP.” It’s what smart teams have done for ages.

Jeff: Heading out of the 90s, I was coming from an environment where class ownership was commonplace. It had seemed like an OK practice when I was able to control virtually all of a subsystem. But every time I ventured outside of my realm, I got frustrated at having to wait on other developers. And once again, I started recognizing the haphazard results of silo development: some good code, most just passable, and some truly wretched subsystems we “inherited” from long-gone travelers.

Simple Design

Jeff: Most casual readers interpret simple design as “you ain’t gonna need it”—in other words, put into the system the simplest possible set of design elements for the features you are working on currently. That’s a start, but the full meaning is captured in Kent Beck’s four rules, in priority order: code must run all its tests, the system must exhibit minimal duplication, it must express intent clearly, and it must contain a minimum number of classes and methods.

Simple design is the most under-appreciated gem of agile programming. I’ve built some subsystems where I deliberately focused only on these four rules. The emergent designs, which I modeled after completion, were elegant and flexible, about as good as any other outcomes where I’d brought my full design background to bear.

Tim: Oh, the joys of YAGNI and KISS and DRY (you ain’t gonna need it; keep it simple, stupid; and don’t repeat yourself)! XP again taught me to do less, better. I used to engage in a lot of speculative design, and it didn’t always pay off. I hoped to run a net positive, but was too afraid to measure it. My designs often were intricate and overly abstracted. I was well-intentioned, but things got out of hand. With simple design, I have less to worry about, and the supporting XP practices (testing, etc.) allow me to make changes as I need them. It is like a super power that makes my mistakes small and correctable.

System Metaphor

Tim: Metaphor is funny stuff. Of all of the practices, it’s the one that gets the least play. When it’s well used, it really can help you to visualize a design and name the various parts of the solution. Done badly, it turns the system into a series of odd puns and confusing turns of phrase. If it’s not done at all, the system will be a mess of mixed ideas and names drawn from concrete details leaking into abstractions. What has stood the test of time is the principle that we need a shared understanding of how our systems work, and a high-level vocabulary we can use to discuss it.

Jeff: We all struggled initially with finding the value in XP’s metaphor practice. Either you had a convenient metaphor (“shopping cart” being the canonical example), or you were stuck with the “naive metaphor” of naming a rose a Rose. But isn’t Eric Evans’ concept of domain-driven design (DDD) what Beck was really getting at? Both metaphor and DDD promote having a common, ubiquitous language, getting the customer and development team all on the same terminology page. Today’s programmatic embodiment of metaphor and DDD is BDD (behavior-driven development).

Pair Programming

Tim: Pair programming may be the most surprising practice of all. You would expect it to be inefficient, riddled with personality problems, imposing, and expensive. Instead, it is a highly streamlined way to get work done, saving think time, preventing errors, eliminating “stovepipe” specializations and their associated queuing, reinforcing good design practices, and accelerating teams. It is exactly not what you expect it to be. Most of us who started pairing just to improve the code end up loving it and looking forward to our next session. Add pair programming to the other practices, and soon you truly have a proud and competent team.

Jeff: And yet pairing still languishes. It’s probably the hardest XP practice to implement and sustain. Why? Because it requires you to learn how to collaborate closely with every other member of your team. That’s tough! With pairing, programming moves from a solo artistry—subject to the whim of each individual’s capabilities—to a team effort, requiring coordination and concert. It requires strong social spirit and the desire to succeed, but it’s extremely rewarding if you can get pairing clicking in your team.

Conclusions

Tim: Whatever comes next will come on the back of agile practices. It will likely leverage what we are learning about managing teams, managing code bases, new open-source frameworks and libraries, new ways to sell software, and possibly new tools for telepresence. Shops that have not adopted XP values may find a different way into the future, but the smart money is not on them.

Jeff: Agile caught on a lot better than that thing called XP from whence these development practices originally came. But I was and remain greatly concerned: the reality is that it’s hard enough to build out a solid system, even with never-changing business priorities and without short cycles. Agile turns that upside down and can devastate a system’s quality in very short order if you don’t have the controls and disciplines to keep it clean. The teams who really want to be successful are coming back to “XP in all but name.”

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.

When Did That Happen?

The von Neumann Bottleneck
by Dan Wohlbruck
In the latest in his computer history series, Dan shows how a hand-written document composed on a train ride drove computer architecture for half a century.

In May 1945, John von Neumann was traveling by train from Aberdeen, Maryland to Los Alamos, New Mexico. Von Neumann was involved with the Manhattan project and that May, with the first atomic explosion still two months in the future and its success in some doubt, von Neumann had been summoned to provide a bit of last-minute advice.

At Aberdeen, von Neumann was involved in another huge and important project, working with the scientists and engineers who were building the ENIAC computer, in connection with which Johnny (as his friends called him) had been asked to write a memorandum about their effort. The memorandum was to discuss the deficiencies already seen in the ENIAC and to define a new machine that would overcome the problems. The summary that von Neumann finished in long hand, titled, “The First Draft of a Report on the EDVAC” was finished by the time he arrived in Los Alamos. He mailed it to his colleague Herman Goldstine, who typed it up, got it reviewed, and published it the next month.

The EDVAC was to become the world’s first electronic digital computer and von Neumann’s memo defined the architecture for it and for stored-program computers generally. The von Neumann architecture was essentially the only design model used by computer scientists for 50 years.

Johnny

Who was this Johnny von Neumann and how did he find himself at the center of the 20th century’s two most enduring technological advances: the splitting of the atom and the creation of the electronic digital computer?

Almost from the time he was born in Budapest in December 1903, Janos Neumann, the son of the banker Max Neumann, was called Jancsi. In 1913, Emperor Franz Joseph ennobled Max Neumann and the family changed the name to von Neumann. Jancsi was one of three boys born to Max and Margaret, and he was recognized as a genius from the time he was six years old. Jancsi graduated from high school at the age of 11 and he received his PhD from the university in Budapest at the age of 22. For five years, from 1925 to 1929, von Neumann taught at the University of Berlin.

When Max von Neumann died in 1929, Johnny accepted a teaching position at Princeton and he, his mother, and his two brothers emigrated in 1930. In 1933, von Neumann joined Albert Einstein and six others as the initial faculty members of Princeton’s Institute for Advanced Study. At the Institute, von Neumann came to know and work with Einstein, Godel, Church, Veblen, Ulam, Dirac, and Pauli. But it was reported by those who were there that in any gathering, it was Johnny who seemed to be the brightest light.

It is not surprising, then, that von Neumann became a trusted advisor to Robert Oppenheimer and a consultant with the Manhattan Project to build the first atomic bomb. When a problem was too sticky or when the scientists involved in a disagreement were too reluctant to budge, Oppenheimer often called Johnny to provide a solution or to convince the others of the right approach. Such was von Neumann’s reputation that even in the company of Nobel laureates, his recommendations were rarely questioned.

ENIAC and EDVAC

In the spring of 1944, von Neumann was working on the hydrodynamics of the implosion of the atomic bomb. Von Neumann was also involved with work on ballistics at the Aberdeen Proving Ground, and since there was a war to be won and a bomb to be built, Johnny went looking for machines to help with the effort.

During March and April of 1945, a series of meetings were held in Philadelphia at the Moore School, where the ENIAC had been created. The purpose of the meetings was to discuss the deficiencies already seen in the ENIAC and to define a new machine that would overcome the problems. Attending the meetings were Eckert and Mauchly (the ENIAC’s creators), von Neumann, Goldstine, and a few others. The result of those meetings is still felt today through that summary that von Neumann wrote. The EDVAC, built in accordance with that document, was to become the world’s first von Neumann machine.

Along with the von Neumann architecture came what has been called the von Neumann bottleneck. To understand the bottleneck, we must first understand the problem that von Neumann observed with the ENIAC.

The ENIAC was the last of the great electro-mechanical calculators. In other words, it was a grotesque monster. It weighed over thirty tons and it had 19,000 vacuum tubes, 1,500 relays, and hundreds of thousands of resistors, capacitors, and inductors. Although the ENIAC was intended to be as electronic as possible, there remained those 1,500 mechanical relays. Von Neumann’s memo compared processing with vacuum tubes and processing with relays. He showed that in order to accelerate arithmetic operations, the designers of calculators with mechanical relays had to build into the machine the ability for simultaneous calculations, which required multiple adders and accumulators. Von Neumann saw simplicity as the secret to increasing both the reliability and the speed of computation. He wrote:

“Thus it seems worthwhile to consider the following viewpoint: The device should be as simple as possible, that is, contain as few elements as possible. This can be achieved by never performing two operations simultaneously, if this would cause a significant increase in the number of elements required. The result will be that the device will work more reliably and the vacuum tubes can be driven to shorter reaction times than otherwise.”

In other words, computers would process data serially, one fetch, one instruction, and one put at a time. The basic von Neumann machine cycle has the following steps: fetch the instruction from memory, decode the instruction, determine the address for each operand, fetch the data at the operand’s address, execute the operation, and put the result into memory.

The Bottleneck

And right there was the bottleneck: the serial execution of instructions. Despite the fact that multiple programs were resident in memory, no matter the number of active threads, despite the long-standing ability to have more than one processor in a single machine; the von Neumann bottleneck set limits to computing power for generations.

John von Neumann was brilliant but he wasn't a prophet.

In May 2005, sixty years after von Neumann’s train ride, the United States Postal Service issued a stamp with von Neumann’s likeness. The citation read: “One of the preeminent mathematicians of the 20th century, John von Neumann made numerous scientific contributions in both pure and applied mathematics. Among them was a machine that became a model for virtually all modern computers.”

“A First Draft of a Report on the EDVAC” described a design based on the stored-program concept, meaning that operating instructions could be entered into a computer via punched cards and then stored internally. The new machine, completed in 1952, became a prototype for almost every computer built since then. For his part in its development, von Neumann received the Enrico Fermi Award in 1956, the most prestigious science and technology award of the United States of America.

It all started in May 1945—and that’s when it happened.

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

Calendar

Author sightings, partner events, and other notable happenings.

Author Appearances

- May 5, The Skills Matter eXchange, London, England
2-day training course on MongoDB (mainly focused for DBAs and Ops staff)Brendan McAdams, author of the forthcoming MongoDB: A Quick Start Guide

- May 5, Agile New England, Waltham, MA
“Agile Program Management: Is Large Agile an Oxymoron?”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

- May 10–13, XP2011 , Madrid, Spain
“Still No Silver Bullets”Esther Derby, coauthor of Behind Closed Doors and Agile Retrospectives

- May 10–13, XP2011, Madrid, Spain
KeynoteBrian Marick, author of Programming Cocoa with Ruby and Everyday Scripting with Ruby

- May 12, XP2011, Madrid, Spain
Park Bench Discuss: “Grumpy Old Agile Coaches”Rachel Davies, co-author of Agile Coaching

- May 13, XP2011 , Madrid, Spain
hands-on coding workshop, “Extreme Startup,” with Robert ChatleyMatt Wynne

- May 13, GeeCON 2011, Krakow, Poland
“Regex—the Future Programmer’s Best Friend”Staffan Nøteberg, author of Pomodoro Technique Illustrated

- May 13–15, Gateway Software Symposium, St. Louis, MO
“Hello! Groovy,” Apprenticeship Birds of a FeatherDave Klein, author of Grails: A Quick-Start Guide

- May 15–20, Full. Email Johanna for slots in August.
Problem Solving Leadership Workshop with Jerry Weinberg and Esther DerbyJohanna 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

- May 16, RailsConf Baltimore, Baltimore, MD
“Building Bulletproof Views”John M. Athayde and Bruce Williams, who are writing The Rails View for the Pragmatic Bookshelf

- May 16–19, RailsConf, Baltimore, MD
“Test Your Legacy Code”Noel Rappin, author of Rails Test Prescriptions

- May 16–19, RailsConf, Baltimore, MD
TBDChad Fowler, author of The Passionate Programmer

- May 17, RailsConf 2011, Baltimore, MD
“The Holy Grail (of Databases)”Eric Redmond, author of the forthcoming Seven Databases in Seven Weeks

- May 18, DevSum 2011, Stockholm, Sweden
“Regex—the Future Programmer’s Best Friend”Staffan Nøteberg, author of Pomodoro Technique Illustrated

- May 24–27, Tek 2011, Chicago, IL
“Pragmatic Guide to Git,” “Git’s Meat Cleavers: Rebasing, bisecting, and other fun with Git”Travis Swicegood, author of Pragmatic Version Control Using Git

- May 28–29, RubyConf India, Bangalore, India
TBDChad Fowler, author of The Passionate Programmer

- May 28–29, European Ruby Conference, Berlin, Germany
“The Revenge of method_missing()”Paolo Perrotta, the author of Metaprogramming Ruby

- May 28–29, Euroko 2011, Berlin, Germany
“Writing your own Programming Language to Understand Ruby Better”José Valim, author of Crafting Rails Applications

- Jun 5–6, Better Software Conference/Agile Development West, Las Vegas, NV
Agile Architecture workshop with Rebecca Wirfs-BrockJohanna 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
SpeakingPragmatic Programmer Andy Hunt

- Jun 7, Better Software Conference/Agile Development West, Las Vegas, NV
Agile Program Management for Agile and Non-Agile ProjectsJohanna 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
TBDBrendan 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 FeatherDave 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
KeynotePragmatic 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 WorkshopDave 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 FeatherDave Klein, author of Grails: A Quick-Start Guide

- July 25–29, OSCON, Portland, OR
“Projects and Community With Github”Andy Lester, author of Land the Tech Job You Love

O’Reilly Events

- May 16–19, RailsConf, Baltimore, MD
RailsConf: “Co-produced by Ruby Central and O'Reilly Media, RailsConf is the official and largest gathering of the Ruby on Rails community. RailsConf incorporates keynotes, sessions, and tutorials to arm participants with the knowledge and skills they need to capitalize on the wealth of services and opportunities the Rails framework has to offer.”

- May 21–22, Maker Faire 2011, San Mateo, CA
Maker Faire 2011: “A two-day, family-friendly event that celebrates arts, crafts, engineering, and science projects and the Do-It-Yourself (DIY) mindset. It's for creative, resourceful people who like to tinker and love to make things. We call them Makers.”

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

- May 8–10, HotOS XIII, Napa, CA
HotOS XIII: “Three days of active interaction among innovative practitioners and researchers in computing systems, broadly construed. Continuing the HotOS tradition, participants will present and discuss new ideas about computer systems research and how technological advances and new applications are shaping our computational infrastructure.”

- May 26–27, HotPar '11, Berkeley, CA
3rd USENIX Workshop on Hot Topics in Parallelism: “HotPar '11 will bring together researchers and practitioners doing innovative work in the area of parallel computing. HotPar recognizes the broad impact of multicore computing and seeks relevant contributions in all fields, including application design, languages and compilers, systems, and architecture.”

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

Other Happenings

- May 1
2006 MacArthur Fellow Jim Fruchterman is 52.

- May 2
Protoblogger Dave Winer is 56.

- May 3
Simon Tatham, known for playing with PuTTY, is 34.

- May 8
jQuery creator John Resig got to age 27 one day ahead of Mark Zuckerberg.

- May 9
Red Hat founder Marc Ewing is 42.

- May 11
Edsger Dijkstra’s 81st birthday.

- May 14
Zillionaire entrepreneur Mark Zuckerberg is 27.

- May 17
Youthful Alan Kay is 71(!)

- May 19
Today is the tenth anniversary of the opening of the first Apple retail stores. Also, Java daddy James Gosling is 56 today; Theo de Raadt, founding member of NetBSD and founder of OpenBSD and OpenSSH, is 43; SNOBOL creator Ralph Griswold would have turned 77 today; and CP/M inventor Gary Kildall would have turned 69.

- May 26
Ward Cunningham is 62.

- May 27
PEZ was trademarked on this date in 1952.

- May 28
Networking hotshot Adam Dunkels is 33.

- May 29
62nd birthday of shareware co-creator Bob Wallace.

- May 31
John Kemeny was born on this day in 1926.

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

Shady Illuminations

Cloud Strife
by John Shade
John makes a half-hearted effort to replace the cloud metaphor with something that he seems to think is better, but it holds up about as well as an Amazon EC2 instance (did I say that?)

The fifth of May translates into cinco de Mayo in Spanish, and Cinco de Mayo translates into celebration in Middle American. Officially. Six years ago, the Congress of the United States directed the President to issue a proclamation calling upon the people of the United States to observe Cinco de Mayo with “appropriate activities.” No specification of what activities the Congress might consider appropriate was provided.

The President probably had a few ideas. In his younger days, he could have given lessons in how to celebrate Cinco de Mayo, a minor regional holiday in Mexico that has been usurped in the U.S. by celebrants of random ancestry as an excuse to get wasted. Much like St. Patrick’s Day or Oktoberfest, but thankfully nobody feels compelled to put green food coloring in the margaritas. (There’s no guarantee that somebody won’t bring out an accordion, though.)

Those of us not hampered by a pledge of temperance or the public scrutiny of high office are free to celebrate General Ignacio Zaragoza Seguín’s historic defeat of Napoleon III’s forces at Puebla in whatever way we find appropriate. I suggest the cloud drinking game. Take a drink every time some tech pundit uses a phrase like “partly cloudy” or “extended outlook.”

Cow Computing

I wonder if the popularity of cloud computing doesn’t have more to do with this richness of metaphor that the word “cloud” offers than with any actual technological novelty. Not that the metaphors aren’t often highly appropriate: forecast uncertain, foggy concept, dark lining, need to clear the air.

But given the actual level of ho-hum of the idea of putting your data and computations in somebody else’s data center, the metaphors that occur to me all inherit from class Ungulate. Let’s face it, the most exciting thing you can say about Amazon Web Services is that it has nine stomachs: once it swallows your data, you have no idea where in the ruminant beast it’s gone. I think the Ungulate class is at least as rich a source of metaphor as the Cloud class, and I recommend it to you. Cow tipping, cow farts and global warming—go ahead, milk it for all it’s worth.

Until the Ungulate meme catches on, though, I guess I have to stick with the cloudy one. So….

I have to admit I was a little foggy on the basics, like just how you seed the cloud with your data and computations. So I googled cloud formation and extrapolated. Here’s what I came up with:

When the budget for your data center drops below the dew point, there is a net condensation and a cloud forms.

So I figure that’s how it works. Not that it actually works, of course.

Unavailability Zones

“Neither snow, nor rain, nor heat, nor gloom of night stays these courageous couriers from the swift completion of their appointed rounds,” is the unofficial motto of the U.S. Postal Service, and if you buy that, you probably also trusted Amazon to keep your data safe.

On April 21, Amazon’s EC2 cloud service experienced a large service disruption. Well, it was really Amazon’s customers who experienced the service disruption, and it was not a pleasant experience. The outage lasted four days, took down the websites of dozens of high-profile companies, and permanently destroyed many customers’ data. In a 6000-word apology, Amazon said that the outage “was caused by several root causes interacting with one another and therefore gives us many opportunities to protect the service against any similar event reoccurring.”

Yeah, yeah. Looking at a disaster as a learning opportunity may be a nice healthy attitude, but it doesn’t really sit well in the middle of an apology to the people whose businesses you damaged by your screw-up. Here’s a different spin on the same sequence of events: Amazon screwed up, and then missed multiple chances to recover from the screw-up.

I mean, aren’t those “many opportunities to protect the service” in fact many ways that they failed to protect the service? The only way you get those three nines, or whatever Amazon’s acceptable-level-of-disaster target is, is to build in safeguards for low-probability events. It seems like in this case one low-probability event was all it took, because all the gates were down from there on. Oh, and the way I read Amazon’s apology, the primary triggering event was human error. Human error is not a low-probability event.

Last month it was Amazon. Next month it may be Google or some other cloud purveyor. Clouds are untrustworthy. I’m thankful to Tony Hillerman, without whose deep distrust of clouds’ illusions I’d be forced to quote Joni Mitchell. In Skinwalkers, one of Hillerman’s mystery novels of the Southwest, he writes of “the clouds forming over Black Mesa, offering a false promise of rain.” Hillerman’s clouds are always promising what they can’t deliver. I’m with Tony. You’re a fool to entrust your data to someone else’s servers.

Or, for that matter, to your own. It’s the law: your data belongs to Murphy, and one day he’s going to come to collect.

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. Send the author your feedback or discuss the article in the magazine forum.