I’ve recently been teaching Java programming at a large, enterprise-y software company. Its an ongoing series of Intro Java, Advanced Java and Struts in rotation. The students have been uniformly wonderfuly; engaged, interested in learning, excited about the possibilities of Java.

This company also offers a series of, essentially, lunch-n-learn symposia whereby speakers from inside the company and out are invited to present on a topic for an hour. The presentations are filmed and distributed internally as webcasts for those who couldn’t make the presentation. In the past, I’d done a few of these (focusing on unit testing and exploration testing). Each time I did, the turnout was roughly 10-12 students.

This week, during my Intro Java course, I gave a new presentation: Ruby on Rails. I told my Intro Java students that I’d be spending the lunch hour one floor up, presenting on a new, dynamic web app framework written in Ruby, and that they were welcome to come upstairs and have a look. Only one of them took me up on my offer. However, that wasn’t too bad, as ~40-50 others came. The room was packed to the gills, with folks sitting on the floor against the walls at the edges of the room. The person who handles the series later told me that it was the best attended session in the (multi-year) history of the program; I’ve since talked to a lot of folks who watched the webcast as well.

After the presentation, a group of attendees gathered around, and their comments all were of a single theme. I’ll quote one of them: “Thanks for bringing Rails here; its a dose of fresh air just to see some alternatives to what we normally do around here.” I was, to be honest, trepedatious leading up to the presentation. I didn’t know if anybody would show up at all. I’m stunned, really, at the turnout and the reception the topic received. It wasn’t due to the presenter, that’s for sure; it was the framework the brought them and the framework that hooked them.

Does this mean that Rails is suddenly going to replace this company’s product line? Not in a million years. The primary software solutions they sell aren’t really suited for Rails or even Ruby. But as a large company who themselves have to build and support a software infrastructure, they have tons of need for a framework that allows them to quickly build robust web apps to serve internal, and even external, customers. And Rails is a great tool for that job. Judging by the response it got at this one session, and the conversations I had with the attendees there, it will be quickly and widely adopted at at least one major software company this year. I bet it isn’t the only one.

David Heinemeier Hansson recently wrote about his experience with Dave Thomas and the Beta Book version of Agile Web Development with Rails. DHH talks about learning that readers won’t hate the author over a few mistakes; that, essentially, they are much more interested in new knowledge, and a few mistakes here or there don’t matter to readers, only to publishers who want to make perfect books. As such, DHH claims, Dave Thomas’ original fears of releasing the book early were unfounded.

I’m here to tell you, they were far from unfounded. They were entirely right on. Readers demand that the book that they take back to their office, or bookshelf, or the trunk of their car, is perfect down to the last detail. Especially when we’re talking about errors in code. Typos in text? Not really a big deal. Typo in the code? The world has ended. And they are right. If I pay $29.99-$54.99 for a book about a technology, I expect that the technology inside it is clean, checked and ready to go.

However, I don’t think DHH’s overall point is invalid; readers LOVE the beta book program, for a very specific reason. They can get their hands on an early, malleable, updateable ELECTRONIC copy of the book. If there are errors, they report them. Then they get a new copy with the fixes in it. More importantly, they are constantly given copies with fixes that other people have found, saving them the expense. And the book that they receive at the end, the physical copy, is clean. Perhaps cleaner than any other book they’ve ever purchases.

The key is permanence. If readers get one crack at a book, that last 20% is vitally important. Errata lists don’t help. Reprintings don’t help. The time it takes to integrate fixes to a print book is extremely counterproductive to a relationship built on trust and expectation of quality. A beta book, on the other hand, is ephemeral, fixable, bi-directional. The first and only model of publishing books where, to quote my English professors from college, the “reader can engage in a conversation with the author”. And with all the other readers.

So, yeah, when you are using the beta book model, nobody cares about the last 20%, UNTIL the last 20%. When you have a traditional print model, everybody has to care about the last 20%, from the guy writing the book to the guy sticking it in the box at the printer. Because that’s the only chance you have to get it right.

UPDATE: So, I guess what I’m saying is, Agile Development works for books as well as for software. Get the product in front of readers early and often, and they’ll work with you to make the perfect product. Deliver once, at the end, and there are bound to be problems, and lots of unhappy customers who, rightfully, can’t understand why the problems existed in the first place.