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

I never sleep well on the road. Going to the other side of the planet doesn’t help, but sometimes there are more important things to do than sleep.

The Great India Developer Summit provides plenty of them. It’s a four-day show, held this year at the National Science Seminar Complex in Bangalore, India. At the generous invitation of Saltmarch Media, I spoke on all four days of the conference, in the .NET, Web, Java, and Workshop tracks. I gave talks on Decision Making, Complexity Theory, Gaelyk, Open Source Business Intelligence, and Liquibase. I also gave three-hour workshops on Gaelyk and Liquibase.

This was my first time at an Indian conference and my first time in India. Sadly, a tight schedule and responsibilities from the office back home kept me from being able to enjoy Bangalore outside of the hotel and conference venue. However, just the conference experience was different enough from my normal to make it interesting all by itself.

The expo hall and speakers’ lounge were open-air, which made for a few warm afternoons, but made the tropical rain on Thursday and Friday that much more beautiful. Most remarkable to an American speaker are the huge posters placed outside of each lecture hall bearing the speakers’ names and session titles. This functions as a handy guide to the day’s activity in any given room—and an embarrassing one to boot. American conference speakers love being the center of attention (why else would we be conference speakers?), but we’re shocked and surprised when people actually treat us that way. There is an irony here.

Attendees at any conference tend to assign more honor and privilege to speakers than any of us deserves, but the delegates at GIDS took this to a new level. They really seemed like they were deeply honored to have us there, and were not at all shy about approaching speakers after a session to ask questions on any subject. They acted as if we were the sort of people whose faces you’d put on giant posters! This is probably just a difference of degree from the attention speakers get in US and European conferences, but it’s a remarkable difference nonetheless.

GIDS treats its speakers very well, having put us up in the beautiful ITC Windsor. I am a well-known sucker for a breakfast buffet, but a breakfast buffet with vada and coriander chutney makes that much more a fool of me. (There were some Western comfort breakfast foods in there too, like French toast and sausage. These were not ignored.) The staff was polite and helpful in the extreme, the wireless Internet functional, and the room beautiful. It was a fine home away from home for the week.

I’m glad to be home and back to a conference-free life for a couple of months (No Fluff notwithstanding, of course), but the experience was invaluable, and I hope I can repeat it in future years.

As an important aside, the name Saltmarch, which meant nothing to me before my trip, turns out to be something like the Indian Boston Tea Party. Thanks to my friend Venkat Subramaniam for that explanation.

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.

Intel is talking about a radically scalable processor design that can do 48 cores today, and lots more tomorrow.

The architecture for the Intel 48-core Single Chip Cloud Computer (SCC) processor is “arbitrarily scalable,” said Intel researcher Timothy Mattson, during a talk at the Supercomputer 2010 conference being held this week in New Orleans.

“This is an architecture that could, in principle, scale to 1,000 cores,” he said. ” I can just keep adding, adding, adding cores.”

…

For simplicity’s sake, the team used an off-the-shelf 1994-era Pentium processor design for the cores themselves. “Performance on this chip is not interesting,” Mattson said. It uses a standard x86 instruction set.

And so the message of the prophets of functional programming is ratified in part. It’s been a meme in the past several years that radically multicore processors were coming, and that the received models of concurrent programming were unlikely to do a good job utilizing the new hardware. That hardware would be slower (or at best no faster) per processor, but would instead grow the number of processors to deliver more computing power over time. And now that radical multicore is appearing, what of the claim that threading and synchronized mutable data is a dead letter? Well, ask a hardware guy:

As more cores are added to chips, [cache coherency] becomes problematic insofar as “the protocol overhead per core grows with the number of cores, leading to a ‘coherency wall’ beyond which the overhead exceeds the value of adding cores,” the paper accompanying [Intel researcher Timothy] Mattson’s talk noted.

Mattson has argued that a better approach would be to eliminate cache coherency and instead allow cores to pass messages among one another.

Interesting that hardware designers have made the same discovery that we have: to wit, that managing concurrent access to mutable state is simply not possible at scale. We often make the argument as a cognitive one—that programmers simply can’t reason effectively about heavily threaded and synchronized code—but there turns out to be a performance boundary as well.

A 1,000-core part is an automatic win if you’re writing server software whose unit of work is a computationally mundane request. You parse some text, you do some disk or socket I/O, you sort some lists, you process strings into an output buffer, and nobody gets hurt. But if your computational task is less mundane and actually requires thoughtful coordination of computing resources that doesn’t delegate well to infrastructure like an app server, then trying to manage mutable state by hand will wreck you on the same rocks as Intel’s hardware designers.

Which is not to endorse, say, actors over STM, simply because the hardware in question looks more like one than the other. But it is to say that the prophets of mutability doom are not to be ignored, and you should probably start learning new languages as if you believed them.

I’ve put together a screen cast showing how to configure Tomcat and VisualVM for a secure JMX connection using self-signed certificates and a password. You can download it as a Quicktime video here:

Managing Tomcat with JMX (43.4MB, 1024×768)

This is a slightly cleaned-up version of some video in a talk I gave at SpringOne 2GX last week entitled Grails in the Real World. The talk was a summary of my experiences as a Grails developer and trainer, including a few tools and techniques I think are helpful when using Grails successfully in the wild. I talked a lot about Liquibase, some common GORM pitfalls, how to approach training and advocacy of Grails, and of course, how to use JMX.

Even though JMX is a very mature technology, getting this kind of thing to work is a perennial pain for users of any application container and web framework. I hope this quick video helps you out. Let me know how I could have improved it!

I’ve been using Gradle for my Groovy builds recently. I consider myself a Build Diletteante, having done complex builds in days of yore using Ant, and having done the bulk of my recent builds in Grails, which is to say I haven’t really done a lot of complex builds in a while. Anyway, from my vantage point, Gradle seems to do everything right, and I’m excited to be seeing its rise to prominence.

It has just about everything it needs, but what it lacks is a convenient and well-documented means of executing a Groovy script inside a task with the project’s classes and compile-time JARs on the script’s CLASSPATH. Because, I mean, who doesn’t want that? Well, I do; I frequently find myself developing a small collection of classes which I want to exercise both through unit tests and through an integration-test-like script. I don’t want to push all of the script code into the build file, but I want the script to run as a first-class citizen of the build. “groovy -cp build/classes/main:foo.jar:monkey.jar… script.groovy” is only tolerable for so long.

And we need tolerate it no longer! Herewith my solution, entirely in the build file:

The classname passed to the Java task is simply the script’s package followed by the name of the script. In this example, we would want a file called script.groovy in the Groovy source tree that looks like this:

I have to believe this is a slightly unconventional need of mine, but I keep bumping into it, so I’m pretty happy to have solved it. Hope this helps! Thanks go to Adam Murdoch on the Gradle User list for pointing me to sourceSets.main.runtimeClasspath, which helped me find classesDir and a whole lot more.

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.

A few weeks ago, I had the very enjoyable experience of chatting with my friend, Andy Glover, on the phone for a little while. We talked about open source business intelligence, including a few popular tools and a few key concepts that are well known to database professionals but not so well known to developers. Or as Andy put it, “Tools techniques, and sardonic wit.” That’s me! Give it a listen today:

http://www.ibm.com/developerworks/java/library/j-gloverpodcast/