Agile Java Rewrite?

I’ve had the idea to write a book on refactoring for some time, and even produced a proposal a couple months ago. The focus would be “refactoring in the context of TDD,” aka continual design. I only got halfway through a sample chapter, which the publisher requests. (Writing the sample also reassures me it’s the book I want to and can write.) This past week I heard that a Big Name is currently working on a refactoring book rewrite. Hmm, maybe this project is not something that I should be doing.

Agile Java has been in print since 2005. It still sells copies–not a lot–and I also still receive thanks for the book from many folks who found it a great way to learn (TDD + OO + Java from the ground up). I feel a bit guilty that people still use a 12+year-old-book featuring a version of Java end-of-lifed for about 8 years! Time for a rewrite, as some have requested?

A dozen years later, what would change?

  • New approach based on new versions of Java: The book was written to coincide with Java 5 and its dramatic language changes, which also made it easier for a simpler, more-OO focus than previously would have been possible. With Java 9 on the horizon (July 2017, maybe?), a new version would find lambdas being introduced fairly early to allow new developers to focus on the value of more-functional approaches to solving problems.
  • Potential new “Additional Lesson” chapters focusing on full-stack considerations (HTTP and JPA, for example)… or maybe this whole notion of covering peripheral technologies gets dropped. Yeah, let’s do that, and keep this to a somewhat-reasonable length.
  • Updated for the latest version of JUnit (5).
  • Use of fluent assertions (probably Hamcrest with mention of other frameworks).
  • Emphasis on one behavior per test, as well as the value of tests-as-documentation.

Otherwise, the tone and general flow would remain the same. Hopefully not the page length: Few folks want to read 750-page books anymore.

I’m the sort to find the stuff I wrote a while back to be lacking, so I might be tempted to rewrite a few things…

Trailing the Way in 2009

I started reading a very recently published book. I don’t want to mention the name of the book, but it is a tome targeted at “application developers.” After reading a small number of paragraphs from the book, I had to check my calendar to see whether this was 2009 or 1995.

Some choice sentences from the book that just grabbed me right off the bat:

  • “Software applications should simulate (model) the real world with close affinity to the problem domain.”
  • “…the average developer should spend 40 to 50 percent of his or her time in design and not writing code.”
  • “Similar to comments and just as important [emphasis added], the design documents a program.”
  • “An artist does not start with a paintbrush and a canvas. There is considerable preparation before painting can begin. … Similarly, developers do not simply start writing code. The requirements analysis must be undertaken, a design drafted, the prototyping [emphasis added] of class operations, and only then, finally, the implementation.”
  • “The goal of TDD is simply to be a framework for addressing customer requirements with software through an iterative approach to testing and coding.”

[ All told, the author uses around 10 paragraphs in the book to describe TDD, not providing a single example. ]

For me, one of the most illuminating benefits of all this up-front emphasis on design seemed to be realized in the brilliant class diagram for a simple retail banking system. It looks something like:

  Employee <|---- Teller  <------  Customer
              |
              |-- Manager

The power of the “real world” comes alive! This ingenious class diagram existed to support building the following code:

static void Main(string[] args)
{
    Customer cust = new Customer();
    cust.Teller = new Teller();
    cust.Deposit();
    cust.Withdrawal();
}

Per the author, this code “validates” the design.

I’m speechless. (Well, no, I’m fingerless, or something. There must be a better word for being so flabbergasted that you can’t start to type a response.) I could rail on this book to no end, but it would only draw attention to the book (and you’ll note that I’m not providing a link to it either).

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 (http://openoffice.org) 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.

Atom