One week, one character

Tracked down a tricky error over the past week. No, I'm not that slow, but I had to get a whole new database sandbox created and populated and then fix my data source definition before I could even get to the point of investigating the problem. Once, the data was flowing into the program, I discovered that I had a broken domain object. I had had trouble getting anyone to be excited about me retro-fitting unit tests into the web application that I'm porting from WebSphere to JBoss and so I'd done a few (about three dozen) of what I thought were the main objects. Wouldn't you know that one of the ones not tested had an error in it! At my hourly billing rate, that's several thousand dollars tracking a problem that would not have existed if I had been free to unit test all of the domain objects. The fix? A single exclamation mark to reverse a wrong boolean statement.

The Joys of Writing a Book

I have previously posted JUnit information on this blog. The entries are now in the process of becoming chapters in a book.

I don't have a contract with a publisher, but at this point I'm not worried. From previous experience with the world of computer book publishing, I know that the publishers prefer to start looking at a manuscript after you've written a quarter to a third of the material. This helps reassure them that you're serious and not just wishing to write a book, but have actually invested some sweat equity in the project.

I may not even bother talking to any publishers. The wonders of modern technology mean that on-demand publishing through the likes of lulu.com combines nicely with the ability to produce professional-quality typesetting using the LaTeX application. As the newsletter editor for the state for our church organization I'm used to layout and typesetting (using Adobe InDesign), but LaTeX continues to amaze me every time I see it render my documents.

As I come towards the end of the fifth chapter, I am planning to print what I have so far through the services of Lulu.com and see how it looks when I've done everything myself. If it looks good, then I may just finish the book and plan to sell it myself. If my self-promotion efforts fall flat, then I can still fall back on talking to the publishers. At the worst, it should be good fun.

The process of writing has been fun. As a young fellow, I never enjoyed writing, but these days I quite enjoy it and only lack of time slows me down. Previous years of blogging helped me to find my writing voice. I'm sure professors of English Literature could pick my style apart, but I like it and feel no need to change. While I'm quite happy editing my own writing and even get ruthless with myself, I don't enjoy huge changes. One of my co-workers read an early draft of the first five chapters and suggested a big change. It made sense, and I'm in the process of finishing the edit, but I haven't enjoyed it.

I started the book using a plain text editor, then I tried using Microsoft Word and one of the free templates from Lulu, but a couple of months ago I switched to LaTeX to get the professional layouts. While it takes time to get used to not using a WYSIWYG editor, I find it actually speeds me up as I no longer worry about the layout when I'm working on the text. The LaTeX application and the selection of document class will take care of most of that for me. It feels very liberating.

For those who have never used LaTeX, it is powerful, but complex. Simple documents are not too bat to produce, but here I'm using lots of included packages, non-standard page sizes and specifying lots of layout details. Thank goodness for Internet search engines and bloggers who describe the details of how they've published their own works. Once I get this figured to my own satisfaction, I shall add to their efforts and write my own "How to write and publish a book using LateX" post.

My all-time favorite Ron Jeffries quote

From the NeverIsNeverNever page on the C2 wiki:

I know that if you agree NEVER to let the unit tests drop below 100%, you'll only do it that one time when you just couldn't figure out an incremental way to change all the deductions from negative to positive. If you agree NEVER to keep a task open for two weeks, you have a better chance of finding the way to do it incrementally, and that one time you'll make sure you've sucked every idea out of the universe before giving in.

When I say something should never be done, it should mean that you'll never do it unless you really have to.

And if you really have to, you'll ask everyone you know first so you still won't have to.

And if you still have to, you'll be looking over your shoulder scared to death that I'm going to materialize there and say "why didn't you just ..." and be RIGHT, and EVERYONE will know you're an idiot.

When you're sure that you'll be able to say "because X" and I'll quietly lower my eyes and say "oh" and de-rez back to wherever I come from ... then break the rule.

Then do one more thing. When it's over, and you've suffered - as you will - for breaking the rule, think back and figure out what you could have done, and learn the deeper meaning of NEVER.

Last time, I poked a little fun at the Architects. In the interest of fairness, it's the turn of the programmers who don't test.


The image was made over at diy.despair.com using an image from Wikipedia.

Unit Testing

Unit Testing or, as J.B. Rainsberger likes to refer to it, Programmer Testing is a seriously undervalued and underused technique within the I.S. industry. I just read a post by Andrew Binstock over at his personal blog asking "Is the popularity of unit tests waning?" This is an interesting question.

I also found interesting, his observation that TestNG is effectively invisible. For the record, I had not only heard of it, but was previously asked to be one of the pre-press technical reviewers for the book. But, it is true that when you speak of unit testing these days you are, by default, referring to JUnit.

But back to the question. As I ponder this, I am drawn to the conclusion that it never was popular. Unit testing is pretty much the programming equivalent of flossing your teeth. You know you should do it and you understand the health benefits that will come from it, but you just never quite manage to get yourself to do it.

I think that unit testing has been promoted by the alpha geeks and early adopters of tools and techniques. I have been using it more on than off for over five years now, so I can honestly tell you that getting programmers to write unit tests is seriously hard work. I have had the most success with my JUnit evangelism with teams that I am personally leading. As a technical lead, I try to lead my teams by example and show how unit tests help me be certain that my code does what I think it does and how it is safe to refactor because I can prove it works with a simple run of an ant build.

I have had a moderate amount of success with management. Most managers now recognize the term unit test and they will generally agree that they are good things and that programmers should indeed write them. The problem comes when the deadlines get short, because so do their memories and they "forget" that they agreed that unit tests should be written no matter what, even if that means an overrun on the targeted due date. All hail the great god Deadlines!

I have had so little success convincing fellow programmers to use unit testing that I'm almost embarrassed. I was even the "JUnit sheriff" at a previous location and I still didn't get much traction. I think that the problem comes from the lack of positive feedback. Knowing that you get more of the behavior that is rewarded, the lack of unit testing must be because of the lack of seeing unit testing produce positive results.

On previous projects of mine, thinking especially of a big one a couple of employers back, I have insisted on unit tests (writing them myself where necessary) and the positive feedback loop starts to kick in and the others on the project start writing them as well. At the current employer, there were zero unit tests in the house when I walked through the door just over a year ago. I was involved in a couple of projects where I wrote unit tests, but after they got canceled, the positive feedback loop was short-circuited and we are still having an awful job getting folks to write tests.

If you haven't seen a suite of unit tests working its magic and saving you from certain crashing, then it's hard to internalize why you would want them.

So, one of life's great dilemmas. Unit tests are good for you, but until you see them work, it's hard to see that they could work.