When I read Kent Beck’s a few years ago, what struck me was not merely its detailed advice on how to write handsome methods and pick good names for things, but rather a deeper insight that it offers. The central argument of the book is that it is both more difficult and more valuable to write code for humans to understand, rather than machines. Coding a spec is usually easy; reading and understanding somebody else’s code is hard.

Pondering that, I decided to do my most recent Ignite talk on this topic. You’ll note I’ve stretched the Ignite form a little bit—it’s supposed to contain 20 slides, each on a 15-second auto-advance, which I didn’t do. Instead I opted to use video, so there aren’t really any slide boundaries, but I kept the five-minute hard limit intact so I’d have some grounds for calling it an Ignite talk. Here it is in its full 720p glory (you’ll have to go full-screen to get the HD controls):

The text, if you are interested, is here:

When a coder sits down to start banging out code
The first thing to start crowding his cognitive load
Is whether his program will do what it should
Correctness, he says, is what makes my code good

It’s the function that captures the coder’s attention
Behaviors and inputs and outputs are mentioned
As if the one good that a coder can bring
Is to spin the right wheels on some Turing machine

And compiling and linking and running are great
(We need to do these to put food on our plate!)
But the shocker that might leave you scratching your head
Is that actual code is less written than read

We spend more of our time in maintaining our stuff
Than we ever spend writing the simplest of cruft
Which means that unless you’ve got something the matter
You’ll try to learn just a few code style patterns

So coders and countrymen, lend me your ears
As I teach you some lessons won hard through the years
From that Beckian book about implementation
And patterns that derail code suckification

A classical problem is how to name things
(Oh, the anger and fights and dissension this brings!)
Like off-by-one-errors and cache expiration
A permanent answer’s beyond expectation

But a class should be named to describe its intent
Not its implementation, though that’s how were bent
A superclass name should be pithy and short
And the subclass’s name a more detailed retort

When you look at the name of a class you should find
The idea that hatched in the first coder’s mind
And just what is the thing this class wanted to do?
And what should you be thinking when first you call “new?”

When you can’t find a name for a class, it’s a sign
That the metaphor’s actually escaping your mind
A good metaphor helps more than comments or training
To inform other coders just what you are saying

The next thing we’ll consider together is state
(Which wouldn’t be bad if it wouldn’t mutate)
The functional people may think that they profit
But objects we code will change state; we can’t stop it

It’s not just concurrency where it can bite us
Although many suffer from thread-lock-wait-itis
The way that we organize pieces of state
Can make all the difference between good and great

Group similar state close together and see
Just what happens in time to your code quality
If you think of the reason your data is altered
Your sense of the meaning will be less assaulted

The things that are changing together should be
Very close to each other, viewed all on one screen
The data whose purpose is common? Same thing.
If they all work together, keep’em all in one scene

Remember the scopes an imperative language
Gives to you to gather together your baggage
The method, the instance, the class scope are able
To keep you from having too much on the table

The changing of state is a serious problem
And I think that we’re starting to locate the bottom
But as long as assignment is part of our ken
We’ve got try hard to keep data reigned in

See, the coder who’s reading this pile of junk
Is bounded in what he can think of at once
Don’t make him scroll all up and down every file
To find and recall every identifier

Now the methods we write can get out of control
When we make the one reading them scroll, scroll, scroll, scroll
A method that’s long and meandering is bad
But a method that’s short and composed makes us glad

To compose a good method, just think of the scope
Of the things that it does, and with that you can hope
To keep all of its actions around the same level
Or else its abstractions will leave you disheveled

A method composed by a coder who tries
Will read like a story with just one plot line
Each part of the story it tells is the same
As the rest of the method, with all the same aim

To understand just what composing’s about
Imagine a story of when you went out
And started the night by first changing your clothes
Then switching to tell me the distance you drove

Then up and describing the way you shift gears
And a long, pointless tale about your rear-view mirror
Then changing your story to cover the dinner
And how it was cooked and how long the sauce simmered

Then skipping ahead to the movie you saw
But not telling me even one detail at all
Now what would you think of this crazy approach?
My mental disturbance would be hard to broach!

It’s the very same thing when we factor a method
Each one should stay small with its purpose embedded
In a series of readable sub-method calls
And inside those methods go all their details

When people are learning, they sometimes prefer
First to know all the details and from them infer
All the concepts producing the detailed design
Either concept or detail can govern the mind

When composing your methods, keep this fact in mind
And please think of the coder who’s struggling to find
The whole shape of the picture zoomed all the way out
Or the flipping of bits when that’s what it’s about

I think if you’ve listened a little to me
You might start to catch what I want you to see
It’s good when we write code that passes its tests
But mere functionality isn’t our best

It’s the human who sits down to work with our code
Our ideas we want to this one to be showed
So remember this saying, to the best that you’re able
The reason you write code is to love your neighbor

A week ago I had the privilege of speaking at the 2011 Scandinavian Developer Conference. This was my second year at the show. The Friday before the conference, Matthew McCullough and I put on a one-day public Git training workshop in Gothenburg, which was very well received. It’s always fun sharing the stage with Matthew.

My wife also came along with me this time. Gothenburg isn’t known as a tourist town, but it’s still got a lot to offer a couple of Americans who tend to enjoy just about any European city. We enjoyed walking around town and getting outside town a little bit. She took a few hundred beautiful pictures as usual.

I gave three talks: NoSQL Smackdown, Database Refactoring with Liquibase, and HTML5: The JavaScript Parts. NoSQL Smackdown was standing room only, with probably 150 people in the room, which is always gratifying. It’s a hot topic, and the talk explains the landscape fairly well.

The bad part about attending conferences is that I can’t really attend them. There are paying work and writing projects that demand attention, so I can’t go to all the sessions I want. I did attend one, though, given by Anna Herting. Her talk, essentially an extended urge to remain calm about the awesomeness of Agile and focus instead on pragmatic ways to be successful, was excellent. She made two points about the perils of small teams that resonated with me in particular, mostly because I knew I’ve been guilty of both in the past.

First, Anna explained that a small team can freeload on the efficiencies of being small and get away with low-grade engineering practices while still delivering good results. For instance, the team might never refactor and never write tests, but they all know the code so well that they remain fairly happy and deliver value to customers anyway. This sounds a lot like Joel Spolsky’s Duct Tape Programming, which I was never convinced was a good idea. To be fair, meeting human needs (or “creating business value” as we often prefer to say) is the proximate goal of our vocation, and code craft is a close second, but this kind of entrenched sloppiness remains an accrued liability that will move disastrously from the balance sheet to the cash flow statement some sad day when the team grows or undergoes turnover. I’ve been there before, so Anna’s words stung a bit. In a good way.

Second, she talked about how a small team with lots of direct customer contact is in danger of becoming more aligned with the customer than the business. If customers constantly present critical issues directly to a small team of developers—with the customer-developer contact presented as high-touch service, or some such soothing excuse—then those developers may begin to make decisions that benefit the customer first and the business second. Again, this might not seem so bad, and to be fair, one might come to the conclusion that the customer’s benefit is always the business’s benefit. However, I’m pretty sure one would be wrong in that case.

There were great insights, and deserve to be spread wider. There was more to the talk than that, of course, but this is what hit me the most. I hope Anna keeps looking for opportunities to speak, even if she isn’t going to become an insane globe-trotting conference monger like Some People I Know.

In summary, the show was great, the food was great, the city was great, the people were great. It’s always a treat to catch up with old friends (although I definitely didn’t get to spend enough time with certain people) and make new ones. I certainly hope to be back in Gothenburg next year.

This past Tuesday, I gave an Ignite-style talk at DOSUG. I recorded the audio and combined it with the slides (with their prescribed timing) and uploaded the finished product to Vimeo. (It turns out 20 slides of 15-second auto advance works out to be more like 5:06 than 5:00, but who’s counting?)

The talk is an exploration of the hero culture in software development, with lessons drawn from the epic poem Beowulf. Beowulf is, the consensus of medieval scholars notwithstanding, a parable about software teams gone bad. We ignore its lessons at our personal and collective peril.

from on .

The typical conference session is a 50- or 60-minute lecture backed by slides. No Fluff Just Stuff, where I do most of my speaking, extends that to 90 minutes. Some creative speakers think of group activities to supplement the otherwise-non-stop bloviating, but those are generally limited to soft skills and process-oriented sessions. If you want to talk about code, getting people to get their hands on a keyboard at a conference is a tough problem. I’ve been wanting to solve it.

Two weeks ago in Raleigh, I retooled my open source business intelligence talks to include a hands-on workshop. The talks had been two 90-minute lecture sessions covering the basics of ETL, reporting, and analytics on a conceptual basis with a brief demo of relevant tooling, including some elaboration on using the Pentaho Analytics Platform. The retooled version is comprised of one part lecture covering the basic concepts, plus a 90-minute, hands-on training session building an ETL job in Talend Open Studio.

A working Talend installation has a few moving parts: a Java runtime, a database, sample application data, a sample data warehouse schema, and Talend itself. Asking 15 or 20 people to install all these things by themselves and get them talking is at least an hour of work by itself, and my goal is to provide a valuable workshop experience in 90 minutes. I tried the install-your-own approach at ÜberConf in June, and it wasn’t a terrible experience, but it was clear that it could be improved.

My new approach is to create a VM and distribute it to attendees before the session. So far this is working much, much better. There are some frustrations in the first few minutes of the session, but I’m able to get people’s hands on a tool that requires a fairly complex runtime environment. Here are some lessons I’ve learned and problems I’m still working on:

• Try to keep the VM as small as possible. Right now I’ve got one that takes just over 8GB while running, but zips up to just under 2GB. This seems like an easily achievable minimum.
• When creating the VM (using VMWare), be sure to check the box that splits the disk image files into 2GB chunks. Chunks greater than 2GB will not unzip on Windows machines, seemingly no matter what client you use. Windows users will not remember you in song (at least not the kind of songs you want).
• Find some way to distribute the VM image ahead of time. Otherwise it will take several minutes to copy and unzip, burning up valuable workshop time. In my case, the workshop follows a 90-minute lecture session which is but required as a prerequisite, so I pass around thumb drives during that session. Attendees can copy the image and unzip it while they listen to the dulcet tones of my voice. It’s a win-win.
• Note that your more enterprisey attendees may have laptops whose thumb drive capability has been crippled by their corporate masters. I have yet to devise a fallback plan for this. Perhaps I could burn a DVD with the requisite files on it; I will be thinking about this and other options. (I’ve chosen thumb drives to make it easy to update the image and other support files on a regular basis, as the talk evolves.)
• Distribute a player with the VM image. No, seriously. Twice now I’ve asked attendees to download the VMware player at the start of the session, since I’m not formally allowed to distribute it myself. This is a big fail. I may switch to VirtualBox to get around this problem.
• When distributing an operating system image with a database installed on it, be sure to document the usernames and passwords of all OS and database accounts. I’ve made the decision to use a single, simple password for all accounts, favoring user experience over security in this sandbox OS.
• When providing instruction on a visual tool like Talend, distribute screenshots of each step of the procedure you want attendees to do. That way, if someone gets behind, he or she has a shot at getting caught up by following the slides.

So far I’m getting positive feedback on the session. People really enjoy getting their hands on a tool and are mostly ending up with the satisfied feeling of having learned and done something new. I’m still working out the kinks, but I think this is going to become a staple of my stable of talks. I’d love to hear your ideas on how to improve it.

I was privileged to present at JavaZone in Oslo, Norway this week. JavaZone is Norway’s major Java-centered conference, and drew around 2,500 people this year. It’s a high-energy show with well-known and impressive marketing. There were seven tracks of presentations from regional and international speakers and a busy exhibition floor, mostly populated (in my extremely unscientific sample) with Norwegian consulting and technology companies.

I gave one lightning talk in the first session of the day on Wednesday. It was a ten-minute variant of my now well-rehearsed Then Our Buildings Shape Us: Form And Content in Software Development. JavaZone lightning talks are ten minutes in length, so I had to expand on the Ignite-style format the talk currently has. Turns out I expanded too much, and I didn’t quite finish in time, despite the fact that my rehearsals indicated that I’d finish 10-15 seconds early. I think being in front of a live audience encourages a speaker to elaborate on the script just a bit, which this very constrained form doesn’t really allow. Lesson learned.

Around lunchtime on Thursday, I gave Decision Making in Software Teams. The talk was well-received, eliciting good feedback on Twitter and—better yet—in person. JavaZone, showing their class as a conference, rewarded me with a bottle of red wine, which will be shared with Mrs. Berglund later in the week.

Oslo offers no shortage of incredible opportunities for tourists, and fortunately I was able to take two days before the show and enjoy some of those sites. On Monday we visited the Viking Museum, which is a collection of first millennium Viking artifcats centered around a few more or less complete longboats.

Later that day, we walked around the National Palace, a beautiful building surrounded by some first-class gardens.

Our hotel, which wasn’t situated in a particularly historic part of town, still offered beautiful views from the window.

No tourist visit to Oslo could possibly be complete without a visit to the Sculpture Park, a sprawling garden on the west end of the city build around a number of stone sculptures depicting various kinds of human relationships in various phases of development. I won’t elaborate on it here, except to say that if you take your time and pay attention to the art, it’s a deeply moving experience.

There was more to the show and to the trip, but the best travelogue is the shortest. Schedule permitting, I’ll certainly be sending proposals to JavaZone in 2011. If you’re a speaker, I encourage you to do the same.

I had the immense pleasure of traveling to New York City last week to speak at the NYC Java SIG to promote the upcoming No Fluff Just Stuff show in Jersey City. The Java SIG is what most people call a JUG, but in world class cities, they have a bit more flexibility in setting their own conventions. You’re going to call it a SIG, and you know what? You’re still going to love it.

I’ve driven through and around Manhattan before, but I’ve never really been in the city. I had a scant 20 hours to enjoy the place, which I did with some abandon. I’m fundamentally a man of the suburbs, but I love the city, and lovers of the city are truly bound to enjoy Midtown. I will certainly be back at my earliest opportunity.

The JUG—or rather, the SIG—is led by the redoubtable Frank Greco, CEO of Crossroads Technologies (no relation). I gave my talk on Gaelyk, shown here:

There was lively discussion about Gaelyk’s very lightweight structure as a framework, and the limitations imposed by that structure. Many of the SIG attendees are Enterprise developers in the classical sense, so a product like this was understandably strange to them. And to be sure, I would never commend it for use in anything of even moderate complexity. However, for sites so simple you don’t want to incur the cognitive cost of dealing with a larger framework, and for which any kind of sophisticated hosting would be overkill, Gaelyk is a perfect fit. Interaction with the audience moved delightfully to a discussion of the way our tools shape the way we solve problems, and even the kinds of problems we consider tractable. Winston Churchill was quoted. Neal Postman was referenced. was commended. Win, win, and win.

All in all, an enjoyable trip and a solid talk with a first-class JUG. Thanks to Jay Zimmerman and the NYC Java SIG for the experience.

I had a great time speaking at DOSUG last night on Talend Open Studio, the eponymous open-source ETL product by the French start-up. I realize ETL doesn’t exactly capture most developers’ imaginations the way cool dynamic languages or cutting-edge web frameworks might, but I think we had fun. The attendees were engaged and had many good comments and questions. I suspect at least a couple of them know the ETL landscape a lot better than I do, but they seemed happy to know there’s a credible open-source product in the marketplace.

I had two main examples to show. The first was a simple (and contrived) transformation of an OPML file into an Excel spreadsheet and a text file. The Excel file contained a list of the names and URLs of all my feeds in a human-readable format. The text file was supposed to contain a list of the unique link types (hint: they were all “rss”), but that part of the demo actually didn’t work properly due to some fault of mine. This being an occupational hazard in live coding not to be dwelt upon when your audience is patiently waiting, I dropped it and moved on.

After the first demo, I talked about basic data warehousing principles a little bit as outlined in by Kimball and Caserta. This kind of thing is tricky with a diverse audience, because the speaker runs the dual risks of insulting the informed and not informing those new to the subject. Brevity is usually the best policy.

The second demo showed a real-life transactional schema from a start-up I had been involved with a few years back. (The present custodians of the data were kind enough to share a sanitized copy of it with me for this demo.) I showed a few transformations of transactional data of varying levels of complexity into the relevant fact and dimension tables, including some look-ups from external text files and one or two interesting joins on the transactional inputs. Mind you, I didn’t proceed to show any neat analytical tools running on the newly minted warehouse, but the OLAP world is your oyster once the ETL job runs to completion. Relatively speaking.

I was frank about Talend’s weaknesses. There are a few tutorial screencasts on the web site, but other than that I don’t consider the getting-started documentation to be particularly smooth. The Business Modeler is a confusing addition to the product—a third-rate drawing program that distracts the newcomer and adds no discernable value to the suite. The lack of credible Mac support is as disappointing as it is surprising, given that the tool is entierly Eclipse-based. However, I still see the tool as an option very much worth evaluating if you have needs in the space.

All in all, I’m happy with how the talk went, and I’d like to put the tool to use in a production environment at some point soon. I hope to be able to make a few upgrades to the talk and give it at some other local groups as the opportunity arises. I’ll update with a link to Slideshare as soon as I get the deck upgraded.

Another thing: as , I did wear all black to the talk. And yes, Matthew McCullough did play a Johnny Cash song just before the meeting got started. See his post on the event for another account of how it went.