Agile Java published!

I finally got my copy of Agile Java from the publisher on Tuesday, after some typical production delays. The way things worked out, some other fortunate consumer got to see it before I did! Ahh well. At least he was kind enough to email me some positive words on it.

I’ve spent months waiting for the book to ship. I wouldn’t have guessed that I’d relinquish the joy of opening the first copy from the publisher to my wife Kathy. But she was home when the FedEx guy dropped it off, and I gave her permission to go ahead and rip it open. I even let her open the boxes of additional copies sent by the publisher. Jaded? Maybe. Or maybe just detached and disbelieving. When I did open it, I was impressed with how much it looked like a real book, like something I couldn’t have possibly had anything to do with.

But I did, and now that it’s done I don’t even want to think about the countless hours I spent on it. Writing, coding, rewriting, editing, reworking, cleansing. A conservative estimate is perhaps 750 hours over the course of 18 months; maybe one hour per page.

And it’s still not complete. I’ve noticed a number of small problems that should be fixed and several sentences that I’d like to reword. I’m hoping to sell enough copies to warrant at least a second printing. Not so much for the money, but for the opportunity to make it an even better book.

As with code, technical writing is never perfect, and there’s always a way to improve on it. I hope I get the chance.

Agile Java

Agile Java draft complete! After a mind-numbing few weeks of frantic scrambling to code the exercises and incorporate all the feedback, I topped it off last night by spending an hour as a blithering idiot, saving it from Open Office ( format to both Word and PDF format, and then posting it to my site. 40 sections overall made for a tedious exercise. I’m sure there’s an easier way to do this using macros or something but I was too brain dead to think.

Writing is an exercise in many frustrations and rewards. Even after spending a year and a half on this book (off and on–I had several spots of three months or so of inactivity), it’s nowhere near as clean as I’d like. But at some point you learn what is “good enough,” and you learn how to let it go. Much like software. Ship it!

Once your material is shipped, the reality of “good enough” sets in. Inevitably there are defects. One of my wonderful reviewers already spotted two such problems in the exercises (which were specified by Jeff Bay of ThoughtWorks, who did a great job) that I hastily coded.

You learn to build a thick skin. Tempering the excitement of waiting to see something published is the trepidation about things like savage Amazon and Slashdot reviews. Recommendation: don’t publish unless you can handle it. “This is the stupidest thing I’ve ever read,” “don’t waste your money,” and so on. It only takes one bad review out of 20 to ruin your day and make you wish you had Amazon censorship privileges.

But ultimately it’s an extremely satisfying and exciting adventure: from opening the box of copies sent to you and smelling the fresh ink, to watching Amazon ranks go up (and down!) and getting a 5-star review. Now if I could only make a true living of it.

Herbert’s Homework

Yard sales can be a treasure trove for used books. If you like carbon-copy suspense or trashy romance novels, you’ll find plenty for sale at fifty cents or even a quarter apiece. Occasionally I’ll come across some good literature (this weekend: The Fountainhead) or computer books.

This past weekend a beat-up hardback, Herbert’s Homework by Hazel Wilson, caught my eye. I had read the book while in early grade school and remembered it well. In fact, I had only remembered the story but not the title, character’s name, or author. Upon spotting the book, I immediately recognized all three.

(It’s interesting how your mind stores things that you later have a tough time retrieving. And then something presents you with a reminder that jogs the details out of your memory. The experience reminds me of saving a document from Microsoft Word, or Excel, or whatever, and then trying to remember where you saved it a few weeks later.)

Herbert’s Homework was interesting to me because I remember that the author had been a bit prescient. The basic plot was that Herbert was a lazy 7th grade punk who did whatever he could to get out of homework. His uncle sent him a gift to help out. He call it a “portable electronic brain.” The brain looked a lot like a clunky television set.

The brain provided answers to encyclopedic questions, such as the average rainfall in South America. It was able to do math quite well. What it failed at were things for which it didn’t have enough information, such as how Herbert had enjoyed his summer vacation. When presented with this sort of challenge, the brain sat there with a blank screen.

Oddly, the author gave the brain the ability to juggle (poorly) balls above a steel rod. Otherwise, the portable electronic brain was the equivalent of a modern PC. Seemingly smart, but truly stupid until someone properly programmed it.

The book was written in 1960. Unfortunately the author presented few additional details or insights into the portable brain, which breaks down when Herbert tasks it a bit too hard. Worse, the manufacturer goes out of business, so Herbert can’t get it fixed.

I’m curious as to what other visions for the personal computing future looked like at this time. I thought it was insightful for the author to implicitly express the limitations of computing.


I loved all the Herbert books as a kid, and now have repurchased them online so that my son, too can enjoy his antics and adventures.
# posted by Anonymous Aneil Mishra : 3/07/2006 03:53:00 PM

I used to enjoy the Herbert books too. Fond memories.
# posted by Anonymous Anonymous : 12/02/2007 05:00:00 PM

Old Age

I recently turned 40. I don’t feel a day over 20, at least from my mentality. Sure, I’m a cranky curmudgeon, but I think I’ve always been that way. In fact, I think I’m far more mellow now.

Some people are 40 the day they turn 20. And they stay that way. So certain of their viewpoints and knowledge, anything else someone suggests to them is a quickly-dismissed challenge.

If there’s one thing that’s most frustrating about the software development industry, it’s that there are so many people that just “know everything.” The mentality needed to build software often suits a sharp, independent, but stubborn mind. Once something works for them, no matter how well it works, developers often have a tough time accepting the fact that something else could work equally as well or better.

Building a successful software team is about finding the right mix of people, and the people with the right attitude. If the team members learn to question themselves as often as they question each other, you’ll probably be fine. If you have “questioning strata,” success will be difficult–it’s hard to get the self-assured down from that upper rock.

When hiring, get rid of your three-and-four-letter acronym laundry lists. Instead, you’re looking for an equal balance of smarts and humility. As far as the “smarts” side of things, check out Joel on Software’s “The Guerilla Guide to Interviewing” for some interesting ideas on how to interview candidates.

As far as the humility measure? It’s tough to ferret it out in an interview, for the goal of an interviewee is to promote self-confidence and success. I like to first ask questions about the things that people enjoy doing, and what gets them riled up. Try pushing a few buttons–it’s not too hard to get the superego to emerge. But the best way to find out is to sit down and try solving a few coding or design problems together. See how enthusiastic your candidate is about explaining things to you. The more important thing than them knowing everything is for them to be able to patiently explain the things they do know.

“You can’t teach an old dog new tricks” is an absolutely true phrase–just remember that old dogs often come in new stripes.