PragPub 2012-01: Issue #31

Table of Contents

Features

- Unit Tests Are FIRST
by Tim Ottinger, Jeff Langr
For unit tests to be useful and effective for your programming team you need to remember to make them FIRST.

- The Dude Abides
by Michael Swaine
The Dude behind Cutting an Agile Groove chats about agility, coaching, and whatever else is on his mind.

- Scala for the Intrigued
by Venkat Subramaniam
In this fifth installment of his series on the Scala programming language, Venkat mixes object oriented and functional styles to reveal the power and grace of Scala collections.

- When Did That Happen?
by Dan Wohlbruck
In January of 1972, Hewlett-Packard made a lot of engineers’ pockets happy.

Departments

- Up Front
by Michael Swaine
Scala, the FIRST approach to unit tests, and a breakthrough product from forty years ago.

- Choice Bits
Drinking from the Twitter firehose.

- Meet the Team
Meet Brian Hogan, who writes books as well as acting as development editor for The Pragmatic Bookshelf.

- The Quiz
A monthly diversion at least peripherally related to programming.

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

- Shady Illuminations
by John Shade
John devotes this month’s column to telling you things you already know.

Except where otherwise indicated, entire contents copyright © 2012 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 Dude Abides
by Michael Swaine
Scala, the FIRST approach to unit tests, and a breakthrough product from forty years ago.

In this first issue of 2012, we’d like to make some introductions.

Meet David Hussman, widely known as “The Dude,” who teaches and coaches agility in companies of all sizes, working side by side with designers, developers, tester, leaders, and others. David’s video series Cutting an Agile Groove is a different sort of product from the Pragmatic Bookshelf, and we invited David to chat about his experiences.

Also meet Brian Hogan, writer, editor, software developer. Brian has geen gracious enough to submit to the latest of our Staff Profiles, designed to eventually introduce you to everyone in the bullpen here in Pragville.

Recently, Tim Ottinger and Brett Schuchert devised a concise set of criteria for making unit tests effective. In their latest agile feature, Tim and Jeff Langr explain the mnemonic for these criteria, an overloaded acronym whose very name answers the important question of when to write tests.

Venkat Subramaniam is back with another installment of his series on the Scala language. Dan Wohlbruck highlights another moment in the history of technology. And John Shade tells you things you already know.

But wait, there’s more. We haven’t published a puzzle in a while, so this month we’re offering up a Sudoku puzzle with a twist—it uses letters instead of digits, and hidden within it is a name that any computer scientist should be familiar with.

We hope you enjoy the issue, and that your 2012 is a good one.

Choice Bits

Retweeted

Plumbing the depths of the twitterstream and keeping our feet dry.

What’s Hot

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

1^

NEW

iOS SDK Development

2^

NEW

Seven Databases in Seven Weeks

3^

NEW

Lean from the Trenches

4

4

Agile Web Development with Rails

5

5

Mac Kung Fu

6^

7

The Cucumber Book

7^

9

Programming Ruby 1.9

8^

NEW

Cutting an Agile Groove

9v

2

Rails Recipes

10^

NEW

The RSpec Book

11^

NEW

Pragmatic Guide to Sass

Here at the start of a new year, the twitterati remind us that life can be nice:

Nice! Urban Dictionary is now on @heroku. — @tswicegood

Wow. I had an AA itinerary on hold. Came back to purchase it, and they told me they’d found a lower fare basis in the meantime. Nice service. — @pragdave

I’m also encouraged that @jeg2 is writing docs for TextMate 2. blog.macromates.com/2011/git-style… — @noelrap

Guess our time has come. “Pragmatic” is word of the year: xfinity.comcast.net/articles/news-… — @pragdave

This lovely bottle of single malt perfection are going to have a deep, meaningful conversation with a Scala compiler. — @rit

I have some pretty nice shoes. flickr.com/photos/clarkwa… — @chadfowler

And sometimes not:

I’m starting to wonder if this datacenter is built over a former burial ground... — @lxt

But if we’ve learned one thing over the past year, surely it is that that Twitter is the new goto place for pearls of wisdom:

Working overtime is like shopping with a credit card. And interest is paid in productivity currency. — @staffannoteberg

Facebook is the uncanny valley of social relationships. — @hmason

The journey of a thousand lines of new code begins in readFromURL:ofType:error: — @bdudney

Clever are those who learn to work around impediments, cleverer are those who’re impatient and eliminate those. — @venkat_s

I bought a set of Zen flashcards. They were all blank. — @KentBeck

I think it’s time for velour to make a comeback. — @femmebot

Twitter is where we go for the answers. For example, if you’re a guy, you’ve probably been wondering what women programmers want. Twitter has the answers.

They want it all, but it’s difficult:

I AM SUPPOSED TO BE GETTING SOME WORK DONE PLS DONT REMIND ME I NEED TO FIND A NY DRESS. — @antiheroine

I’d love to go to this transmediaaction.com/trans-camp/ but I would have to give up a day’s pay. :( — @mfujica

They want what any sensible person wants:

New github classes in Joomla Framework github.com/joomla/joomla-… - Nice. I was JUST LOOKING for a PHP implementation of v 3 of github’s API. — @AmyStephen

Just ordered 30sq ft. worth of whiteboard paint. Super cool, goes on clear over any color. Can’t wait to doodle all over my walls!! #fb — @JBertling

People told me I was crazy when I said this was coming... automatic IE updates on WinXP, Vista & Win7! HOORAY! windowsteamblog.com/ie/b/ie/archiv… — @obiwankimberly

The highlight of my flight is the collapsible spork I got in the snack box. — @irishgirl

Wish my bedroom would magically tidy itself. — @Skud

They want scrollbars.

Okay, Unity has finally gone too far. Eclipse has no scrollbars. Ugh. — @terriko

They want you to stop stalking them:

Facebook’s subscribe model is creepy. I don’t know these people who are commenting on my stuff. — @hmason

They want everyone to understand that no means no:

My quest to close my LinkedIn account continues. The harder they make it for me to leave them, the more pissed off I get at them. — @pamelafox

They want me to stop this right now:

I’ve seen a lot of arbitrary WOMEN IN TECH pieces lately. As if we have four pairs of eyes and breathe fire. — @LauraHelenWinn

OK, I’ll stop.

Who Are Those Guys?

First of all, they’re not all guys. Second, we have to confess that we cleaned up their punctuation and stuff a little. Third, who they are: Kent Beck, Jessica Bertling, Kimberly Blessing, Bill Dudney, Phoebe E, Morena Fiore, Chad Fowler, Pamela Fox, Hilary Mason, Brendan W. McAdams, Jen Myers, Staffan Nöteberg, Terri O, Noel Rappin, Skud, Amy Stephen, Venkat Subramaniam, Travis Swicegood, Dave Thomas, Laura Thomson, Meghan Wilker, and Laura Helen Winn. You can follow us at www.twitter.com/pragpub.

Meet the Team

Development Editor Brian Hogan

Each month we profile a member of the Pragmatic Bookshelf team. This month it’s Brian Hogan, author, web developer, trainer, musician, and Pragmatic Bookshelf development editor.

Brian Hogan, Development Editor and Author

Brian both edits and writes books for The Pragmatic Bookshelf. He’d written a few articles in 2006 on how he was deploying production Rails applications on Windows servers, and the authors of Deploying Rails Applications asked him to contribute a chapter to the book. “I fell in love with everything about the Prags from that point on. I worked with two amazing development editors—Daniel Steinberg and Susannah Pfalzer—who helped me put together some good stuff, and I thought it would be great to be able to do the same thing for other authors.”

For Brian, the author/editor combination works really well. “Since I’ve written some books, I know how the authors feel. I know the kinds of questions they’re going to have and the types of problems they’ll encounter at various stages of their books. And when I go back to a writing project of my own, I have a much greater appreciation of the whole book publishing process.

“I love helping authors develop stories. As a DE, I’m often a sounding board for their ideas, but I also get to suggest things that might help the reader connect the dots. I also love the teaching aspect. It’s very satisfying to see how much an author grows throughout the project and it’s fun to be a small part of that. I like to write code, and so it’s fun to learn about new technologies and try things out. I get to be the author’s first reader sometimes, and that’s a blast.

“A little-known fact about me is that my father, daughter, and I were all born with congenital cataracts. When I was a baby I had surgery to remove the lenses in my eyes. I wear contact lenses and glasses, but have relatively reduced vision and I routinely use assistive technology when I’m writing code or working on books. I’m a somewhat loud advocate of web accessibility, and I’m always looking for ways to help other people understand that accessibility makes things more usable for everyone.”

Website: bphogan.com

Email: brian@pragprog.com

Twitter: @bphogan

Unit Tests Are FIRST

Fast, Isolated, Repeatable, Self-Verifying, and Timely
by Tim Ottinger, Jeff Langr
For unit tests to be useful and effective for your programming team you need to remember to make them FIRST.

A unit test is a small automated test, coded by a programmer, that verifies whether or not a small piece of production code—a unit—works as expected in isolation. The moniker unit test was popularized with the advent of tools such as SUnit (for Smalltalk) and JUnit. The XP crowd used the term to mean tests that were produced as a result of programmers practicing test-driven development (TDD). Some developers balked—the phrase already had a considerably different meaning in some circles.

Mike Hill of Industrial Logic proposed the unique term microtest, along with which he provided a detailed definition to avoid any confusion. Michael Feathers proposed a similar definition that listed five things a unit test is not. Both sets of criteria are great guidelines for building unit tests. But is there a more concise way to capture and remember them?

Tim Ottinger and Brett Schuchert, Object Mentors at the time, devised the FIRST mnemonic for a more concise set of criteria for effective unit tests. The acronym is overloaded: its very name answers the important question of when we write tests: FIRST.

F for Fast

The faster your tests run, the more often you’ll run them. Tests take half a minute to run? You’ll maybe run them every 5 minutes instead of every few seconds. Tests take over two minutes to run? You might run those tests once every half hour, and you can write a lot of questionable code in that time! Tests take ten, fifteen, or more minutes to run? Forget it. You’ll run those a few times per day at best.

Developers cope with long-running test suites by running a subset of the tests. That’s a guessing game that can work reasonably well as long as you run all of the tests before check-in. It is faster in the short term, but far less certain. All it takes is one extensive debugging session to wipe out the time savings. Unit tests save you time by finding errors immediately after you make them.

You can better tolerate slow tests if a Continual Testing (CT) tool runs them whenever code changes. Smart CT tools like Infinitest will calculate which tests to run based on dependencies in the code. Either way, CT makes running tests less painful. But it is better still if your microtests are blazing fast.

The primary goal of the following test is to verify that HasArticles answers true when articles are present in a feed. It takes almost half a second on a beefy Mac with a fast internet connection. How many reasons can you spot?

class testme(unittest.TestCase):

def test_recognizesEntries(self):

url = "http://agileinaflash.com/feeds/posts/default"

content = urllib2.urlopen(url).read()        # 1

self.assertGreater(len(content),0)          # 2

open("localfeed.rss", "w").write(content)        # 3

sut = ArticleRssParser('localfeed.rss')        # 4

self.assertTrue(sut.HasArticles())

Examine the statements at the comment markers.

1. The test goes to the web for data.

2. The test fails if the RSS feed is empty, without testing HasArticles at all.

3. Writing to the file system increases run time. (The untidy test doesn’t delete this file; correcting this defect adds another file system round-trip to the test time.)

4. The RSS parser class reads from a file.

Instead of accessing a web page, you could write a sample RSS document with a couple “faked” entries to a file. A fast file system might bring the cost of that write to perhaps a tenth of a second. But do you need the file handling at all? If you extract the ArticleRssParser’s file handling into a separate class method, you can easily bypass the file system:

class ArticleRssParser(object):

@classmethod

def get_feed_content(cls, filename):

return open(filename).read()

# … the rest of the class elided

(We use a class method because we want to stub out a behavior that exists in the constructor, otherwise we’d extract to a normal instance method.)

To string this all together, we’ll use the mocking library pymox to create a record/playback test:

class basic_feed_parsing(unittest.TestCase):

def test_reports_it_has_articles_from_2_article_feed(self):

mocks = mox.Mox()

mocks.StubOutWithMock(ArticleRssParser, 'get_feed_content')

ArticleRssParser\

.get_feed_content('fakefilename')\

.AndReturn(sample_with_2_entries)

mocks.ReplayAll()

parser = ArticleRssParser("fakefilename")

self.assertTrue(parser.HasArticles())

mocks.VerifyAll()

Running this test requires neither web access nor file access.

The test’s new line count is higher, and its setup more complicated. As you write additional tests, you’ll be able to abstract away more details. Here’s a later, refactored version:

def test_reports_it_has_articles_from_2_article_feed(self):

self.mocks.StubOutWithMock(ArticleRssParser, 'get_feed_content')

ArticleRssParser\

.get_feed_content('fakefilename')\

.AndReturn(sample_rss_with_2_entries)

with replay(self.mocks):

parser = ArticleRssParser("fakefilename")

self.assertTrue(parser.HasArticles())

This test usually runs in under 0.02 seconds on Tim’s machine. Much faster, but still unacceptable if your suite contains thousands of similarly slow tests.

It turns out that this class uses the python feedparser library, which is already well-tested and reliable. Since you don’t need to re-test feedparser, you can speed up the test by stubbing it out.

def test_reports_it_has_articles_from_2_article_feed(self):

result_with_2_entries = {"entries":[1,2]}

self.mocks.StubOutWithMock(ArticleRssParser, 'parse_input')

ArticleRssParser\

.parse_input('fakefilename')\

.AndReturn(result_with_2_entries)

with replay(self.mocks):

parser = ArticleRssParser("fakefilename")

self.assertTrue(parser.HasArticles())

Result? Runtime disappears into the noise. A unit test in python takes 0.012 to 0.015s if it does nothing but assertTrue(True). This version of the test takes no measurable time at all. The test has assumptions about feedparser, but it still shows that you’re handling the results correctly.

Now we can afford to add a large number of similar tests without long automated test cycles sucking the joy out of our day.

I for Isolated

Each unit test should have a single reason to fail. Our prior example fails this criterion: the test would fail if the file system was full or read-only, if the file existed and was not writeable, if the network was down, if there were no articles in the RSS feed, or if it did not recognize entries in the feed.

You must design your tests to be independent not only of external factors, but of each other as well. When tests are interdependent, a change to one test can cause several others to fail in puzzling ways. Ordering unit tests to optimize their execution is a sign that isolation is poor. Each unit test should instead stand on its own as a complete case that documents one discrete behavior.

Dave Astel’s recommendation of one assert per test promotes tests that are I for isolated. Here’s a test that verifies aspects of both checking out and checking in books:

@Test

public void testAvailability() {

theTrialHolding.checkOut(TODAY);

assertFalse(theTrialHolding.isAvailable());

theTrialHolding.checkIn(TOMORROW, BranchTestData.ROCKRIMMON_BRANCH);

assertTrue(theTrialHolding.isAvailable());

}

Many unit testers would leave this test alone, but it’s really testing aspects of two behaviors. Splitting it into two single-assertion tests makes the reason for any failure immediate. A split also allows you to improve the test names:

@Test

public void isNoLongerAvailableAfterCheckout() {

theTrialHolding.checkOut(TODAY);

assertFalse(theTrialHolding.isAvailable());

}

@Test

public void isAvailableAfterCheckin() {

theTrialHolding.checkOut(TODAY);

theTrialHolding.checkIn(TOMORROW, BranchTestData.ROCKRIMMON_BRANCH);

assertTrue(theTrialHolding.isAvailable());

}

Such single-purpose tests make AAA (Arrange-Act-Assert) notation effective.

The sheer size of most systems means that no one knows the entire code base by heart. You must design your test suite names, your test names, and your assert messages to reduce and simplify investigation.

R for Repeatable

You should obtain the same results every time you run a test. Tests can fail intermittently for a few reasons; here are the most common:

1. Static data or other in-memory constructs not cleaned up

2. Volatility of external services (e.g. file system, database, web services, API calls)

3. Non-deterministic behavior due to incorrect use of threads/processes

4. Dependence on an uninitialized (or slow-initializing) local class

5. Over-specification (for example, comparing entire screen images or HTML when only a small part of the result is interesting)

Intermittently-failing tests can be difficult to decipher. If you are uncertain about the current state of things, add precondition assertions. If any precondition is not met, the test will stop before it has a chance to run, and you’ll know exactly why:

@Test

public void addCustomer() {

assertThat(customerStore.retrieve(ACME_ID), is(null));

customerStore.add(new Customer(ACME_ID));

// ...

}

Testing threads is a more difficult challenge. You might figure out how to test multi-threaded code, observe the test passing dozens of times in a row, and then watch it curiously fail. Some developers will say—perhaps unhelpfully—that testing with multiple threads is more of an integration test than a unit test. A discussion on threaded testing at Stack Overflow is a good place to start, and will give you an idea of the kinds of challenges you’re up against.

Increasing isolation tends to enhance repeatability.

S for Self-Verifying

A good unit test fails or passes unambiguously. When all tests run green, you have high confidence that you can ship the code to the next level (likely the acceptance test automated suite). If any of the tests fail, you don’t proceed until they get fixed. The pass/fail nature of the automated testing system makes it viable even for large teams.

When a test suite leaves some results open to human interpretation, validating them becomes a drag on the productivity of all programmers. Ambiguous tests fail to be helpful and fall into disuse.

A classic way to game the code coverage metric is to write a test that exercises a broad swath of code, yet never assert a thing.

@Test

public void createReport() {

Catalog catalog = new Catalog();

catalog.add(new Holding(BookTestData.AGILE_JAVA));

catalog.add(new Holding(BookTestData.JAWS));

catalog.add(new Holding(BookTestData.THE_TRIAL));

InventoryReport report = new InventoryReport(catalog);

System.out.println(report.allBooks());

}

If the system misbehaves, there is a rather dubious hope that a programmer will be monitoring the console output and will know what output to expect.

Coded tests should instead actually verify something in an automated fashion:

@Test

public void createReport() {

Catalog catalog = new Catalog();

// ...

InventoryReport report = new InventoryReport(catalog);

assertThat(report.contains(BookTestData.AGILE_JAVA.getClassification());

// ...

}

Do programmers really write unit tests that test nothing? Sadly, yes. A recent SD Times article related this story: “One organization outsourced its test case implementation with the goal of achieving 80% test coverage. The test coverage went up, but because the tests were calling methods but not validating them, the outcome was useless.” (Morgan, Lisa. “Driving Higher Value from Build Management and Continuous Integration,” SD Times, October 2011.) We’ve both personally witnessed this kind of dysfunction.

Usually a “wide swath” test can be reworked into a series of fast, isolated, repeatable, self-validating tests. In pathological cases, the complicated setup and poor environmental control may make salvage untenable.

When pairing with developers new to TDD, we’ll sometimes gut a method completely, reducing it to merely returning a null value. Our pair partner is either enlightened by reading the failing tests, or else amused as all the automated tests pass. Try this technique for yourself, and see what happens!

Tests that prove nothing have no benefit to your team. Removing them will make your coverage metrics honest and useful.

T for Timely

Should you write tests before writing the production code or after it’s already built?

You should always know what you’re trying to build before you build it. Tests written first specify the behavior that you’re about to build into the code. These “specifications by example” can help everyone more rapidly understand what the code’s doing, particularly down the road when no one remembers what it was supposed to do.

You also want to know when you’re done—that is, when you’ve successfully coded things correctly to that specification. Running tests constantly lets you know when you can integrate your changes into the source repository.

Writing tests before the code encourages you to think of the use of the code before you think of its implementation. The tests are the very first client of the code you’re building. A clean unit test should make it very clear what the client code will look like. Hopefully you’ll do things like improve your function names and design simpler parameter lists as a result.

Can’t you achieve all of these qualities if you write tests after the code, something we refer to as Test-After Development (TAD)? Theoretically, there’s no reason you can’t get the same benefits. But in our experience, it simply doesn’t happen.

TAD programmers want to verify their code, too, but they typically have little interest in treating the tests as “specifications by example.” For them, the usually singular goal of unit testing is to verify whether or not some aspects of the code work. These unit tests typically cover up to two-thirds of the code base (see bullseye, binstock, and stack overflow). Other forms of integration tests can increase effective coverage, but unit tests are the closest reliable documentation for the code you’re modifying.

The choice to cover only a fraction of the code base with unit tests is a judgment call, hopefully one that weighs effort against risk. Our take: we know that defects, sometimes devastating ones, creep up in the strangest places. We’d prefer to spend time creating confidence that all the logic in the system is solid instead of spending it in long debugging sessions.

The real sticking point with TAD is productivity. When you don’t think about how to craft code so it’s testable, you’ll often end up with code that is near-impossible to test. The test-writer has to either rework it or use a lot of finesse to avoid rework. This makes testing feel like a waste of time. No wonder so few programmers have fully embraced unit-testing! We find TAD to be simply less fun, less beneficial, less productive, and more frustrating than TDD.

Studies have shown that TDD incurs an additional, initial development cost of anywhere from 15% to 35% more time. Our experiences doing and coaching TDD back that up, but we’ll be more daring and say that things speed up over time. Our experience with TAD is that it takes more than 35% of development time for far less benefits, and that figure tends to get worse over time.

Coming back to write a unit test for the ReportMailer class, you find that the constructor throws an exception when called. A static call to MailDestination.getEndpoint, apparently made to verify that each MailDestination object passed has a valid endpoint, is the problem.

public ReportMailer(MailDestination[] destinations) {

this.destinations = destinations;

if (destinations.length == 0)

throw new RuntimeException("dests required");

for (int i = 0; i < destinations.length; i++)

if (MailDestination.getEndpoint(destinations[i]) == null)

throw new RuntimeException("invalid endpoint");

}

A bit of digging reveals that getEndpoint requires a live external API call. You consider making the method instance-side, so that the client calls it like this:

if (destinations[i].getEndpoint() == null)

but then you discover that other clients use it statically, and you don’t want to have to touch other code. You could introduce the Feathers’ WELC pattern Extract and Override Call to fix this problem. This testability challenge would have been addressed already had we been test-driving from the start.

Granted, fixing this isolated example doesn’t represent a huge amount of additional effort. Compound it with gobs of other similar code with bad dependency upon bad dependency and long convoluted methods, and it’s enough to make most developers toss up their hands in disgust.

Effective Unit Tests

Whatever you call them and however you define them, the most important thing about unit tests is that they be useful and effective for your programming team. The FIRST mnemonic is a simple mechanism to guide you there.

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.

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

The Dude Abides

An Interview with David Hussman
by Michael Swaine
The Dude behind Cutting an Agile Groove chats about agility, coaching, and whatever else is on his mind.

David Hussman—widely known as “The Dude”—teaches and coaches agility in companies of all sizes, working side by side with designers, developers, tester, leaders, and others. He speaks and writes about the evolution of software product development at conferences around the world. His video series Cutting an Agile Groove was recently released by The Pragmatic Bookshelf. Figuring that he had some free time with the video production out of the way, I talked him into sitting for an interview on agility and coaching and other areas of his expertise.

ms: Hi David. You and I had a lot of conversations, but this will be the first one with the email tape recorder running.

dh: I’m looking forward to it.

ms: Great. While watching a recent interview with Andy Hunt conducted by Mike Floyd at InfoQ, I thought of you. If it’s all right with you, I’d like to leverage off some of the points Andy brought out in that interview, because I think they’re issues that you deal with every day.

dh: Of all the interviews I have done, I think this approach is a first.

ms: Let’s see how it goes. Andy talked about how the agile movement he and Dave Thomas were instrumental in launching has played out. I’m interested in your perspective on that, because you’re dealing with it in the trenches. Ten years after the penning of the Agile Manifesto, what do you see as the biggest benefits and the largest challenges?

dh: I got into the agile movement because it resonated with how I had been successful: plan a little, do a little, learn a little. Like any movement, rebellion was founded in wanting a better way to work. Ten years later, it is no longer a band of rebels and the agile movement is feeling the weight of popularity. The core benefits are still strong: collaborative groups who learn and pivot based on delivery. There are cool new techniques to use like story mapping and continuous deliver. But sadly, as the popularity of agile methods grows, so does the industry around it. There are more people now talking about “doing agile” instead of learning through doing it. Instead of small bands of rebels covertly delivering, I see large companies and huge projects attempting to use agile methods. Popularity is not bad, but it does call for pragmatism.

ms: Meaning?

dh: I am working hard to get people to look at their outcomes first—the evidence—as a guide to validate and modify their process.

ms: Andy pointed out that most of the advice being offered on “going agile” assumes that you’re starting with a clean slate. But as he says, once you write the first line of code, it’s all legacy. You deal every day with companies trying to get products built and launched, and you have to deal with people wherever they are in their process. How do you do that?

dh: Whether projects are in flight or starting from a green field, I always start with short interviews that provide an understanding of how people are currently working, what they do well, what are their challenges, what they want to change and why, and what constraints might lie in their path. The interviews help me to form a suggested coaching plan.

ms: Can you give me an idea what such a plan would look like?

dh: The plans are a set of tools that augment their existing strengths and address their immediate challenges. While the formality of coaching plans varies, all plans share one thing: they are measurable. I avoid a focus on agile and coach people toward ensuring—by measuring—that the tools fit their context. You can think of this as “designing agility” that introduces the least amount of process that provides evidence for learning.

ms: In the real world you have to deal with personalities, you run up against accounting principles and organizational constraints you can't overcome. How do you counsel people to deal with such seemingly intractable issues?

dh: Constraints are the realities that challenge process ideals. Tough personalities, highly distributed teams, legacy code that is spaghetti—those are common constraints. Planning to coach must include considering the constraints in place instead of blindly teaching people a process, like Agile, Scrum, Lean Start Up. I put constraints into three buckets: immovable, mostly moveable—like mostly dead in The Princess Bride—and self-induced. A common self-induced constraint is “we don’t have time to test,” or automated testing, which most often means “we do not know how to get started” or “we really do not value testing yet.” Mostly movable constraints are more difficult and take many forms: large amounts of external pressure due to differed delivery, weak product thinking, and swamplike environments—those are a few examples. Coaching in a company where the makers work in unpredictable environments has little to do with agile methods but everything to do with fostering meaningful agility. Put another way, if you can’t build it, you can’t deploy it. Or if you can deploy it, you can’t test it and you can’t learn. After ten years of coaching software teams, I continue to be convinced that we need to focus on learning supported by process instead of learning to do processes, like big-A agile.

ms: Andy also mentioned the sloganization of agile, the pervasive attitude that “I’m doing the practice, so I’m doing agile.” People who proclaim confidently, “We’re doing story cards,” with no understanding of why they would want to use that tool. It’s a trap that any methodology is prone to. How do you foster lasting agility that matters, helping people to avoid falling into that “follow the process” trap?

dh: I call the process trap the “recipe trap.” Far worse than being stuck on a practice is being stuck on a process. Years of trying to get people to produce software using agile methods, instead of simply “doing agile” motivated me to create my own law as a guide. Like Ohm’s Law (I = V/R) where I is current which is reduces when V (voltage) is constant and R (resistance) goes up, Dude’s Law, in honor of The Big Lebowski, says that value is a measure of why versus how. Or stated as a simple equation, Value = Why/How. To apply Dude’s Law to your question, when people tell me about user stories or story points—both of which are How—I ask them to show me the results, reframing the practice as a tool that has a purpose—Why—which is more than an empty ritual. Specific to user stories, I teach people to use story mapping because this draws on the ideas of stories as delivery tools but also help produce “the big picture” context which is so often missing where people are spending copious amounts of time talking about “doing agile.”

ms: Have you ever had someone say, “Don’t call it agile, we tried that and it failed?”

dh: I do hear this often. It is usually a symptom and not the root cause. Sometimes it means people tried new ideas without learning the skills needed. Other times it means that they tried for force a process on a team instead of introducing meaningful tools. Where people are lacking skills, they may simply need to practice a bit. I taught music for years and my teaching included a mix of practices skills—techniques—that helped people play songs. You have to have some level of skill before you assess the quality of an instrument. If you strum a saxophone and you don’t like the sound, don’t blame the instrument. Likewise, if you “try agile” and fail, it may be that you lack the skills to use the tools. Again, if you focus on outcomes, you can choose the tools that will directly help you with your product in your specific context.

ms: I find it encouraging that there is a growing interest in the idea of “coaching.” But coaching sounds like one of those slippery terms. What’s to keep “coaching” from meaning whatever the coach wants it to mean? What is coaching to you?

dh: Five years ago, there were a small number of people using the coach moniker. It was often so confusing that I added “Software Anthropologist and Coach” to my business card to ensure that people asked me what I did. Today, you can’t throw a rock without hitting someone who is a “coach.” But coaching software teams is just another form of coaching. To me, coaching means helping people produce, helping them learn to produce, and helping them learn to learn. The interviews and coaching plans I develop help me find a balance of work people can do unassisted, pragmatic and focused education, and in the trenches coaching, the coaching being where I focus most of my time. Coaching includes building team bonds and teaching new skills that help people produce and learn. Coaching success is best measured by what is produced and how it is being accepted and used. Process and software that are deemed successful without examining the outcomes is like coaching a team—or producing a band—that plays well but never plays for an audience.

ms: All right. Well, thanks for sharing this, David.

dh: My pleasure.

You can learn more about David’s work at his company site. Send us your feedback or discuss the article in the magazine forum.

Scala for the Intrigued

Working with Collections
by Venkat Subramaniam
In this fifth installment of his series on the Scala programming language, Venkat mixes object oriented and functional styles to reveal the power and grace of Scala collections.

We looked at the object oriented side and the functional side of Scala in the last two articles in this series. These two programming styles interplay powerfully in collections—as we’ll see in this installment of the series.

A direct look at the Scala collections hierarchy can be overwhelming. But when distilled down, each Scala collection can be viewed as belonging to one of two categories: immutable or mutable. Some Scala collections are also lazy (read: efficient).

In both the immutable and mutable flavors, Scala provides implementations of Seq, Set, and Map. Seqs (lists) are ordered collections, sets are unordered, and maps are collections of key-value pairs.

In order to promote programming with no side-effects, Scala imports the immutable collections by default. One of the simplest immutable collections is the Scala list.

val prices = List(10, 20, 15, 30, 45, 25, 82)

Scala allows us to iterate over the collections using an external iterator (where you control the iteration) or an internal iterator (where you only provide the action to perform for each element).

So, to print each of the elements in the list we created, we can use either

for(price <- prices) { println(price) }

or

prices.foreach { price => println(price) }

(or the concise form: prices foreach println)

Collections provide a wealth of functions to work with. Here’s how we can get the first element from the list:

println("The first price is " + prices(0))

In Java we’re used to the array syntax instance[index] to access elements and instance.get(index) to access elements from an ArrayList. In Scala we use instance(index). That’s the syntax, but what’s going on behind the scenes? Recall that Scala does not have operators, and performs operations using methods. Scala has two special methods, apply and update, that can go into stealth mode. So, you are really calling instance.apply(param), but you can simply write instance(param). Similarly, instead of writing instance.update(param) = value, you can write instance(param) = value.

So, to access the fifth element, we can write

println("The fifth element is " + prices.apply(4))

or, in short,

println("The fifth element is " + prices(4))

We could use this approach and imperative style to select elements. However, internal iterators shine for this operation as well. To select the first price greater than 40, we can write

println("First price > 40 is " + prices.find { price => price > 40 })

When we run this, the output will be

First price > 40 is Some(45)

OK, we expected 45, but instead got Some(45). Scala is taking an extra step here to protect us from accidental NullPointerExceptions. If there is no price greater than 40, instead of returning null and expecting us to remember to do the null check, Scala returns an Option type. The option may either be None (non-existent—think of this like DBNull) or a Some value. So, we’re forced to consider the case where there may not be a valid value in response to the function call.

If we’d like all values greater than 40, we can write

println("All prices > 40 are " + prices.filter { price => price > 40 })

While the find picks the first matching element, filter picks all matching elements.

The collection API is quite comprehensive. If we want to know if any element is greater than 90, we’d write

println("Any > 90: " + prices.exists { price => price > 90 })

To know if all the elements are less than 90, we’d write

println("All < 90: " + prices.forall { price => price < 90 })

If the prices above represent prices for some items in another list

val items = List("A", "B", "C", "D", "E", "F", "G")

We can combine these two quite easily

println("items and prices: " + items.zip(prices))

to get

items and prices:

List((A,10), (B,20), (C,15), (D,30), (E,45), (F,25), (G,82))

All the operations on a List (those above and a lot more) leave the list unmodified. If we want a new list, we will have to get a copy. For example, if we want to add a price to the beginning of the list, we’d write

val theNewPricesList = 5 :: prices

println(theNewPricesList)

println(prices)

The new prices list we created will have the element 5 at the beginning, followed by the elements from the old list. The old list, prices, however, is not affected.

Immutability here means we made a copy of the list, so you will naturally wonder, does that mean poor performance? Not necessarily. In the above example, we appended the new element to the head of the list. Scala List is smart enough to share the entire prices list in the creation of the theNewPricesList. Under the covers, the new collection theNewPricesList has one element (5) followed by a reference to the head of the prices list. So, even though it appeared to be a full copy, the List smartly avoided the overhead and reused the existing list in the creation of the new list.

So, the cost of creating a list with a new element in the head position is constant. However, that’s not the cost if we want to insert the new element in any position other than the head. Such simple sharing of the existing list will not work for other positions. Fortunately, Scala collection provides Vector. This is an implementation of Phil Bagwell’s tries, a smartly designed data structure (known as persistent data structures because their contents are immutable or persist over time) that allows efficient partial copying of elements to provide practically constant-time performance.

Tries are tree structures with large branching factors; each node has 32 or more children. So, a tries that’s only four levels deep can hold a million elements. The nodes are referenced using a special convention: the path to the nodes represents the keys. If the keys are numbers, the trie forms a list. For other keys, the trie would represent a hashmap.

Tries make shallow copies and share most of the subbranches when an element is inserted or removed. So, using Vectors, which are immutable, we can insert (or remove) elements at any position, and a copy is made for us with constant-time performance.

Let’s create a vector of prices.

val prices2 = Vector(10, 20, 15, 30, 45, 25, 82)

On this Vector, we can perform pretty much all the iteration, find, filter, and zip operations we did with lists.

To create a new vector with an additional element at the head of the vector, we can write

val theNewPricesList2 = 5 +: prices2

To create a new vector with an additional element at the end of the vector, we can write

val theNewPricesList3 = prices2 :+ 85

If we only want to create new collections with elements added to the head, a List is adequate. However, for inserts or appends, prefer a Vector. For example, to append an element to a list of million elements on my machine it took 0.25 seconds, while it took only 25 micro-seconds for a vector of the same size.

To store a key-value pair or a dictionary, we can use a Map implementation.

val langs = Map("Java" -> "Gosling", "Scala" -> "Odersky")

println("Scala was created by " + langs("Scala"))

The map created this way is immutable. We can create new maps like so:

println(langs + (("Lisp", "McCarthy")))

This new map will contain the key-values in the old map, plus the new key-value pair. Maps provide several convenience functions just like List and Vector.

We’ve only discussed immutable collections so far. As mentioned, we get this capability by default. To create mutable collections, we have to do an explicit import or reference to the class name.

val capitals =

scala.collection.mutable.Map("New York" -> "Albany", "Texas" -> "Austin")

println(capitals)

capitals("Oregon") = "Salem"

println("After change: " + capitals)

The output from the above code is

Map(Texas -> Austin, New York -> Albany)

After change: Map(Oregon -> Salem, Texas -> Austin, New York -> Albany)

Unlike its immutable counterpart, the mutable version of the map provides ways to insert and remove keys from the collection. Likewise, a ListBuffer allows mutation as well.

From the concurrency point of view, immutable collections offer thread safety compared to the mutable versions. We have to select the appropriate implementation based on our need—both in terms of what the collections should do for us and the performance we desire out of them.

Scala also provides lazy collections, which allow us to postpone the creation to just in time or on-demand. This allows us to express some algorithms or logic in very succinct manner. Let’s see how laziness can be useful.

The code below will help us determine if a given number is prime.

def isPrime(number : Int) = {

val sqrtOfNumber = math.sqrt(number).toInt

val hasFactorsOtherThan1AndItself =

(2 to sqrtOfNumber).exists { i => number % i == 0 }

number > 1 && !hasFactorsOtherThan1AndItself

}

Suppose we need to determine a list of prime numbers. We could express it like this:

//Won't work

def primes(number : Int) : List[Int] = {

if(isPrime(number)) number :: primes(number + 1)

else  primes(number + 1)

}

Given a number, we determine if it is a prime number. If it’s prime, we prepend it to the list of all prime numbers greater than that number. Otherwise, we simply exclude that number and return all greater prime numbers. The code is quite expressive, but won’t work. As we ask the primes to be computed, the code will enter into an uncontrolled recursion and fail with a StackOverflowError.

It would be useful if the list of primes could be expressed as above, but the list itself was not computed until we asked for specific number of elements. Enter the lazy collection called Stream. Let’s change the code to use a Stream.

def primes(number : Int) : Stream[Int] = {

if(isPrime(number)) number #:: primes(number + 1) else primes(number + 1)

}

println(primes(1).take(10).toList)

In this version we replaced the List[Int] with Stream[Int] and the prepend operator :: of List with the operator #:: for Stream.

When we invoke the primes function with a parameter of 1, the code runs until it hits the first call to #:: and pauses, deferring the computation of the collection to a later time. When we invoke the take(10), we are asking the first ten elements of the collection to be returned. At this time, the Stream will execute the deferred code enough times to fill the collection to the requested count. The output from the above code is

List(2, 3, 5, 7, 11, 13, 17, 19, 23, 29)

The lazy list gives us two benefits. The code is highly expressive, and we’re deferring computations until needed.

Here we used a special collection Stream instead of List. Streams exist to represent lazy collections, but the Scala API also provides easy ways to make straight collections lazy, using view.

Let’s consider a list of names and a function to determine the length of each name.

val names = List("Steve", "Susan", "Mac", "Brad", "Gill")

def len(n : String) = {

println("Len for " + n)

(n, n.length)

}

Suppose we want to create a tuple with the name and length, but then extract only the first name of certain length. Here’s the code for that, using the len function and the functions of the list.

println(names map len find { e => e._2 == 3 })

The function len returns a tuple and the find function is asked to select a tuple where the second value (length) is 3. The output from the above code is shown next.

Len for Steve

Len for Susan

Len for Mac

Len for Brad

Len for Gill

Some((Mac,3))

The len function was evaluated for each element and then the find function was evaluated for the first three values, until it yielded true.

Using a lazy collection we can eliminate wasted calls to the len function. It hardly takes any effort, as you can see next.

println(names.view map len find { e => e._2 == 3 })

The output from the above code is:

Len for Steve

Len for Susan

Len for Mac

Some((Mac,3))

The call to view turned the names list into a lazy collection. When you called map on the collection, rather than executing the given function, len, it cached away that computation for some later time. When find was invoked on the result, this was a call on a lazy collection that was produced by the call to map. So, rather than executing each function entirely from left to right on all the elements of the collection, the lazy collection executes them left to right entirely on one element, deciding along the way if it has to continue or not. So the computation was short-circuited and no further computation was done once find succeeded, selecting an element.

We’ve merely scratched the surface of the Scala collections API. Familiarize yourself with other classes and functions provided based on what your application may need or where your interests take you.

What’s next? Well, in this and previous article we used functions that accepted other functions. In the next installment we will see how we can create such functions.

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.

When Did That Happen?

The Scientific Pocket Calculator
by Dan Wohlbruck
In January of 1972, Hewlett-Packard made a lot of engineers’ pockets happy.

On January 4, 1972, the first scientific pocket calculator, called the HP-35, was introduced by Hewlett-Packard. It would prove to be an historic debut.

Although a few hand-held calculators were introduced in 1971, the HP-35 could handle higher functions, including logarithms and trigonometric functions. The HP-35 was the first to use a four-register operational memory stack to store and retrieve intermediate answers, the first to provide stack control keys in order to display those intermediate results for further processing, and the first to employ reverse Polish notation for entering data into a calculator. The HP-35 was delivered with an addressable memory register so that constants could be entered and used on demand.

The HP-35 actually outperformed the mainframe computers of its day. Its calculations offered greater mathematical precision and were performed more quickly than calculations on the IBM 360.

HP Gets Giddy

The HP-35 was so successful that in just six months the June 1972 edition of the HP monthly magazine reported the following:

“For a company that has always dealt soberly with the business of its business, albeit with style and invention, Hewlett-Packard has discovered a whole new giddy interface, thanks to the Model 35. For not only is the 35 a runaway best seller (a slight misnomer because as yet, there are no real competitors on the scene), but it is also a novel experience in terms of marketing and selling.

“Consider this situation: When the marketing strategy for the 35 was conceived last year, it was decided that the main tactic would be a direct-mail program. Makes sense. But except for a small test mailing, that program has not been put into effect—because, so far it has not been needed. In fact, from the moment the super slide rule was introduced on January 4, the world has beaten a path to its door.”

Although the article doesn’t mention this fact, the marketing strategy expected that the company would sell 10,000 units in its first year. Instead, for the first time in the company’s history, it had to backorder shipments, as demand was ten times greater than expected. The magazine article goes on to say, however, that:

“What no one could possibly have known in advance was the degree to which the Model 35 has taken on star status. To the realist it may be just a super electronic slide rule; but to others it is a technological status symbol, an instrument with soul, a science-fiction dream come true. In addition, there are evidently far more teachers and students—not to mention business and professional people of all kinds—able and very willing to pay the $395 (plus handling) than anyone had reason to expect.”

In great measure, the HP-35 and its success were a result of the company’s co-founder Bill Hewlett. He and David Packard founded the company in January 1939. From the start, since the two founders were engineering students at Stanford, HP’s products were designed to be used by engineers. Hewlett-Packard began as a partnership, then, after World War II, incorporated, and finally went public in 1957. Hewlett became CEO in 1968.

So why was the HP-35 such a runaway success? The answer is that it truly was a revolutionary product.

In 1970, HP was selling the HP9100, a desktop electronic calculator that weighed over 40 pounds. Hewlett was determined to shrink the 9100 to something that could fit in an engineer’s shirt pocket and offer the same functions as a slide rule. He commissioned a marketing study of this engineer’s dream, and was given an estimate of a total market of 50,000 units selling no more than 10,000 per year. In spite of this lackluster projection, Hewlett challenged his product design and engineering teams to build it. He told them he wanted a calculator that weighed less than 2 pounds and cost less than $500. They did it in less than a year.

We justly celebrate the personal computer pioneers, but the HP-35 was the first product that placed real computing power into the hands of the general public.

William Hewlett died in January 2001. The February 2001 edition of IT World concluded its eulogy to him by saying:

“Silicon Valley has since spawned wealthier people, with higher profiles and greater fame. Hewlett never showed much interest in being a celebrity. Throughout his life he remained, at heart, an engineer.

“An engineer in the best sense of the word.”

It began forty years ago—and that’s when it happened.

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

The Quiz

This Month: If you thought Sudoku was the evil Count's sister…

We haven’t done one of these in quite a while. So to refresh your memory, this is a Sudoku puzzle with a twist—it uses letters instead of digits, and hidden within it is a name that any computer scientist should be familiar with.

N

J

T

Y

U

E

O

H

N

K

O

E

U

O

K

J

T

N

E

Y

H

T

J

K

U

E

N

O

Simply fill in the empty cells with the nine letters E, H, J, K, N, O, T, U, and Y, so that each row, column, and small square contains each of the nine letters once.

Solution next month.

Calendar

Author sightings, partner events, and other notable happenings.

The Garage

Seventy-three years ago this month, on January 1, 1939, Bill Hewlett and Dave Packard signed the papers to create their historic partnership, flipping a coin to decide whose name would go first. The year before they had rented rooms at 367 Addison Avenue in Palo Alto. Dave and Lucille had the downstairs apartment, the landlady lived upstairs, Bill moved into the shed in back, and the garage became the first home of Hewlett-Packard and the “Birthplace of Silicon Valley.”

And so a legend was born.

Here’s what’s coming up in the next three months:

Author Appearances

Who’s where, and what for.

- Jan 11, CodeMash, Sandusky, OH
PreCompiler: Mac OS X for iOS DevelopersDaniel H Steinberg, Dim Sum Thinking

- Jan 11-13, CodeMash, Sandusky, OH
“Developing With iOS 5” and “iOS Networking: Bonjour, iCloud!”Chris Adamson, co-author of iPhone SDK Development

- Jan 13, CodeMash, Sandusky, OH
Session: Storyboarding in iOS 5Daniel H Steinberg, Dim Sum Thinking

- Jan 18, London Scala Users’ Group, London, UK
ScalaMock: “Power” Mocking for ScalaPaul Butcher, author of Debug It!: Find, Repair, and Prevent Bugs in Your Code

- Jan 19, APLN Houston, Houston, TX
talk on RefactoringVenkat Subramaniam, the author of .NET Gotchas, the coauthor of 2007 Jolt Productivity Award winning Practices of an Agile Developer, the author of Programming Groovy, Programming Scala and Programming Concurrency on the JVM

- Jan 20, University of Wisconsin-Milwaukee Lubar School of Business, Milwaukee, WI
iOS 5 QuickstartDaniel H Steinberg, Dim Sum Thinking

- Jan 21, Colorado Code Retreat, Denver, CO
topic TBDVenkat Subramaniam, the author of .NET Gotchas, the coauthor of 2007 Jolt Productivity Award winning Practices of an Agile Developer, the author of Programming Groovy, Programming Scala and Programming Concurrency on the JVM

- Jan 23-26, Pragmatic Studio, Denver, CO
iPhone/iPad ProgrammingDaniel H Steinberg, Dim Sum Thinking

- Jan 23–27, OOP 2012, Munich, Germany
Tutorial: “Influence and Authority: Using Your Personal Power to Get Things Done,” Talk: “Six Behaviors to Consider When Hiring for an Agile Team”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

- Jan 24, By the best from DevSum, Stockholm, Sweden
“Advanced Regex in .NET”Staffan Nöteberg, author of Pomodoro Technique Illustrated

- Feb 13–15, Jfokus, Stockholm, Sweden
“Regex Applied—when regex is a winner”Staffan Nöteberg, author of Pomodoro Technique Illustrated

- Feb 17–19, Agile India 2012
topic TBDVenkat Subramaniam, the author of .NET Gotchas, the coauthor of 2007 Jolt Productivity Award winning Practices of an Agile Developer, the author of Programming Groovy, Programming Scala and Programming Concurrency on the JVM

- Feb 24–25, NFJS Madison, Madison, WI
topic TBDVenkat Subramaniam, the author of .NET Gotchas, the coauthor of 2007 Jolt Productivity Award winning Practices of an Agile Developer, the author of Programming Groovy, Programming Scala and Programming Concurrency on the JVM

- Feb 28, Manchester Java User Group, Manchester, England
topic TBDVenkat Subramaniam, the author of .NET Gotchas, the coauthor of 2007 Jolt Productivity Award winning Practices of an Agile Developer, the author of Programming Groovy, Programming Scala and Programming Concurrency on the JVM

- Feb 28, Softdevon III, Crakow, Poland
“Pomodoro Technique—can you focus for 25 minutes?”Staffan Nöteberg, author of Pomodoro Technique Illustrated

- Mar 2–4, NFJS Minneapolis, Minneapolis, MN
topic TBDVenkat Subramaniam, the author of .NET Gotchas, the coauthor of 2007 Jolt Productivity Award winning Practices of an Agile Developer, the author of Programming Groovy, Programming Scala and Programming Concurrency on the JVM

- March 6-9, Pragmatic Studio, Denver, CO
iPhone/iPad ProgrammingDaniel H Steinberg, Dim Sum Thinking

- Mar 8, Scandinavian Agile Conference, Helsinki, Finland
topic TBDVenkat Subramaniam, the author of .NET Gotchas, the coauthor of 2007 Jolt Productivity Award winning Practices of an Agile Developer, the author of Programming Groovy, Programming Scala and Programming Concurrency on the JVM

- Mar 9–11, NFJS Boston, Boston, MA
topic TBDVenkat Subramaniam, the author of .NET Gotchas, the coauthor of 2007 Jolt Productivity Award winning Practices of an Agile Developer, the author of Programming Groovy, Programming Scala and Programming Concurrency on the JVM

- Mar 12-14, 2012, Belgium Testing Days, Brussels, Belgium
Tutorial: “Influence and Authority: Using Your Personal Power to Get Things Done,” Keynote: “QA or Test? Does it Matter? You Bet it Does!”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

- March 16-17, CocoaConf, Chicago, IL
Storyboarding, Testing, and a KeynoteDaniel H Steinberg, Dim Sum Thinking

- Mar 19–20, Software Passion Summit 2012, Gothenburg, Sweden
“Advanced Regex”Staffan Nöteberg, author of Pomodoro Technique Illustrated

- Mar 19–21, 33degree, Krakow, Poland
various topics related to JVMVenkat Subramaniam, the author of .NET Gotchas, the coauthor of 2007 Jolt Productivity Award winning Practices of an Agile Developer, the author of Programming Groovy, Programming Scala and Programming Concurrency on the JVM

O’Reilly Events

Upcoming events from our friends at O’Reilly.

- Jan 25, Strata Online Conference
Strata Online Conference: “In this online conference, we’ll look at hot topics, brewing controversies, and cutting-edge technologies that promise to change how we live, work, play, learn, and love. Hear from some of Strata’s marquee speakers about what’s consuming them in the Big Data world in this web-based event.”

- Feb 13–15, TOC, New York, NY
O’Reilly Tools of Change for Publishing Conference 2012: “O’Reilly’s TOC Conference is where the publishing and tech industries converge, as practitioners and executives from both camps share what they’ve learned from their successes and failures, explore ideas, and join together to navigate publishing’s ongoing transformation.”

- Feb 28–Mar 1, Strata Conference, Santa Clara, CA
O’Reilly Strata Conference: “Strata brings together practitioners, researchers, IT leaders and entrepreneurs to discuss big data, Hadoop, analytics, visualization, and data markets.”

- Mar 18, TOC Bologna, Bologna, Italy
Tools of Change Bologna: “TOC and the Bologna Children’s Book Fair will team up once again, this time producing an unparalleled event featuring sessions, demos, workshops, and keynotes covering the art, craft, and business of storytelling in the digital age.”

USENIX Events

What’s coming from our USENIX friends.

- Feb 5–8, NDSS 2012, San Diego, CA
19th Annual Network & Distributed System Security Symposium: “The Network and Distributed System Security Symposium fosters information exchange among researchers and practitioners of network and distributed system security.”

- Feb 14–17, FAST ’12, San Jose, CA
10th USENIX Conference on File and Storage Technologies: “FAST ’12 brings together storage system researchers and practitioners to explore new directions in the design, implementation, evaluation, and deployment of storage systems.”

Shady Illuminations

Things You Already Know
by John Shade
John devotes this month’s column to telling you things you already know.

Around this time of year, columnists like to take time off. That’s why you get creampuff retrospectives and best of the year summaries. That’s why I’m devoting this month’s column to telling you things you already know. Like why we read and the trouble with work.

Why We Read

A list is a data structure.

I know you know that, but I think it explains why titles of news stories and blog posts that follow the pattern “20 Great Winter Sports Destinations” or "Top 10 Reasons Bill Gates Should Return to Microsoft” or “The 11 Most Unintentionally Creepy Christmas Ornaments” are so effective. It’s because they promise that the article or post will at least have some kind of structure.

We’re sure not reading “The 11 Most Unintentionally Creepy Christmas Ornaments” for the wisdom it promises to impart, and an article titled “The Reason Bill Gates Should Return to Microsoft” probably wouldn’t rate a click. But 10 reasons, that’s different.

Reading is work, and we’d like some evidence that the author put some work into the writing. That he made a list doesn’t mean much, but it does mean that.

Everything you know is wrong.

I know that’s not news to you, either. But it’s still provocative. If I tell you that everything you know is wrong, you immediately think that I’m about to tell you something you don’t know. It’s a clue that I’m about to offer some contrarian information or advice. We like that. We especially like contrarian advice.

Programmer Patrick McKenzie advises programmers, “Don’t Call Yourself a Programmer,” and the post goes viral. Contrarian advice. He must be going to tell us something we don’t know.

Contrarian advice is effective advice, because it’s the kind of advice we’re open to. We want to believe that we’re independent thinkers, so we’re resistant to doing what someone else says unless they’re telling us not to do what someone else says. “Be independent,” is how the contrarian advice begins and, “just follow these simple steps” is how it ends.

Because contrarian advice is what we want to hear, we’re more likely to pay attention to it and understand it and follow it. So it’s effective, whether or not it’s good.

The Trouble with Work

Them that’s got shall get.

I’m sure you know that. But then I would have thought that my friend Dave did, too. Dave’s an engineer who recently decided he’d retired too soon and told me he had applied for work at the new HomeDepot. I asked, “What position?” and he said, “All 74 of them.” He’s a pretty capable guy. He might get them. Surely getting one would raise the odds on his getting the other 73.

Not only is it easier for the rich to get richer, but most of the gigs get offered to people who already have work. So the Bible says. While the old get older, scrolling to the bottom of Year-of-Birth form popups. God bless the child.

I want the job of making up jobs. I keep seeing ads for “Senior User Experience Designers.” Is that something like a Senior Moment Event Planner? That would be an easy job. You could say, “Anyone for shuffleboard?” and five minutes later say, “Did everyone enjoy the shuffleboard? Who’s up for Bingo?” So what would a Senior User Experience Designer do? Eliminate the “Save As” command?

Jobs are owned by the company, you own your career.

I know, I know: You know that. But it’s easy to overlook the fact that the sentence, “I want to work for myself” means two things. Yes, it means that you don’t want to work for someone else. But it also means that you think you would be a good person to work for. One does not imply the other. It could be that you are just about the last person any sensible person would want to work for.

I know I am.

Be careful what you wish for.

Oh, yeah: happy new year.

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. He has managed to get people to do his job for him on occasion. It was Earl Nightingale who said, “Jobs are owned by the company, you own your career.” “God Bless the Child” was written by Billie Holiday and Arthur Herzog, Jr. Send the author your feedback or discuss the article in the magazine forum.