Burk on Books: Growing Object-Oriented Software, Guided by Tests

If you want the short version, here it is: Developers should get this book and spend some time absorbing the ideas in it. It’s well written and easy to read, but grokking it all will take time and practice. I recommend doing it as a team, book club style; read a bit then discuss it so you can bounce ideas off each other and get the benefit of other viewpoint. I also recommend starting now so you can write better code sooner!

Note to those who care: ‘Grok’ is a real word now, it’s in the Oxford English Dictionary, though I prefer the definition in Merriam Webster’s.

Still here? Well then, I think it’s safe to assume one or more of the following; you weren’t convinced by my four sentence review, you want more details about the book, or maybe you’ve just got some time to kill and like my writing style. Hey, stop laughing, it’s possible...

According to the authors, “Growing Object-Oriented Software, Guided by Tests” is the results of a couple of decades of experience, including almost ten years of Test-Driven Development (TDD) on a wide range of projects. While the authors state that the goal of the book is to teach you TDD, don’t believe them. From what I read, the goal is to teach you TDD the way it should be done. Just as having 100% code coverage doesn’t mean there are no bugs, writing unit tests first doesn’t guarantee a working system.

The authors expand upon the traditional approach to TDD by adding acceptance tests to the mix. Acceptance tests, sometimes called end-to-end tests, begin at the user level (UI or public API) and exercise all parts of the system to ensure the system performs correctly.

Their approach adds an outer loop to the standard Red-Green-Refactor cycle. The loop starts with writing a failing acceptance test then writing all the unit tests needed to make it pass. While it may seem to be a small thing, I think adding the outer loop gives needed direction to the developers’ efforts by highlighting what should be built next.

The book starts with a quick introduction to the authors’ view of TDD, the tools that will be used in the examples throughout the book (JUnit 4, the Hamcrest matching framework, and the jMock2 Framework).

In Part II, the authors go deeper into how they start a project using their acceptance test/unit tests approach. In it, they introduce the concept of a “walking skeleton” which forms the basic structure the rest of the system is built upon.

Part III, a “Worked Example” is the longest section of the book, and it’s where we get to look over the authors’ shoulders as they build a nontrivial application that includes a Swing-based user interface and third-party services in the back-end. Even so, it’s not a realistic application, which is good because at the level of detail they’re giving us, the book would be too big to lift.

One of the most important things this book does is prove that you can test-drive a functional user interface. Yes, it’s a Swing-base UI, but I suspect you could follow the same approach using Seleium or Geb and test-drive a web-based UI too.

Part IV is titled “Sustainable Test-Driven Development” and it the authors present some useful guidelines intended to help you keep your sanity while maintaining a test-driven approach.

Part V covers “Advanced Topics” like how to test persistence, dealing with mult-threading, and how to test asynchronous code.

There’s more after that, including “A Brief History of Mock Objects” and two useful Appendices.

I said it before, and I’ll say it again. Developers should get this book and spend time absorbing the ideas in it; preferably with other team members for the most benefit, Go solo if you must, the time invested will be well spent.

Disclosure: I received a free copy of the book from the publisher, with the understanding that I would read it and write a review of it. For more information read my Full Disclosure post.

Here's the publishing details:

Title: Growing Software , Guided by Tests

Authors: Steve Freeman and Nat Pryce

Published: 2009 by Addison-Wesley

ISBN-10: 0321503627

ISBN-13: 978-0321503626

Full Disclosure on Book Reviews

It seems I may have some housekeeping to do so please read this posting so you'll know what to expect from my book reviews.

Some time in 2009, the FTC published guides governing endorsements and testimonials that may apply to me. While I do buy some books and review them, most of the reviews I post are for books I have received from the publisher with the expectation that I would read the book and post a review. Please note that I said "a review" and not "a positive review".

If you read my reviews, you'll notice that they're all pretty positive. There are multiple reasons for that, but I want to make it clear that other than the book being reviewed, I do not receive any kind of compensation from any of the publishers, or anyone associated with them, in exchange for a positive review. Note that I have, on occasion, asked for copies of a book to give away when doing a presentation at a developer conference. I don't see that as compensation because it doesn't benefit me so much as the people who get the free books.

There are two main reason my books reviews are positive is simple. The first is that I'm not vain enough to believe that if I don't like a book then it must be a bad book. The second reason is because before I ask for a review copy, I do some research. I'll look for the book on Amazon or Safari, or even in a real book store, and read a bit. If it looks interesting and I like the style then I'll ask the publisher for a review copy.

If I'm reviewing a book that's just come out then it's likely I've either read a previous book by the author, it's part of a series (like Head First) that's earned my trust, or it's a topic (like automated testing) that I'm deeply interested in and am willing to take a chance on the unknown.

In case you're wondering, I tend to like books that are technical without being dry. The author should present the information in a way that doesn't make me feel like they're looking down on me because I don't already understand whatever they've spent a decade mastering. Good examples include Presentation Zen, PragProg books like Pragmatic Thinking and Learning, and anything in the Head First series published by O'Reilly.

By the way, Addison Wesley sent me some books that are definitely top notch. I just posted a review for "Essential Skills for the Agile Developer", I'm writing the review for "Growing Object-Oriented Software, Guided by Tests", and I'm reading "12 Essential Skills for Software Architects".

Setting up all those links reminds me, while I often provide links to Amazon, or a publisher's site, so you can easily buy the book being reviewed. They are for your convenience only. I don't get credited or compensated for purchases made by folks using those links.

In the spirit of full disclosure let me say that I once requested a book from a publisher and, after reading it, realized I couldn't give it a positive review. The book was a certification guide, but there were so many factual problems that I knew I could not recommend it to anyone. Instead I emailed the publisher a rather long list of the errors I found, let them know I could not publish a positive review, and offered to send the book back.

So, that's the story. Many of the books I review are sent to me at no cost, but with the expectation that I will read them and post my honest opinion. Some of them are books I bought and wanted to share with you. In either case the opinions I post are mine and are as objective as any opinion can be.

Burk on Books - Essential Skills for the Agile Developer: A Guide to Better Programming and Design

“Essential Skills" is a part of Net Objectives' Lean-Agile series. The authors’ intent is to teach the "minimal set of skills developers need on the journey toward becoming adept at incremental development.” In my opinion they’ve more than met that goal.

Note that while the title says "Agile Developer", almost all the examples are in Java, and the skills are just as useful to Java developers as to any other kind.

Due to its focus on the fundamentals of good software development, “Essential Skills” is one of those rare books that is valuable to both beginners and experienced developers.

Beginners will learn to develop high quality software, while experienced developers will be reminded of valuable practices they may have dropped while attempting to meet aggressive deadlines. But there's more.

The authors also describe the benefits gained, which is quite useful if you're often asked to "cut corners" and deliver something sooner. (Imagine flashes of lightning and ominous music here.) Once business people see how rushing things out the door leads to lower code quality, and eventually results in longer deliver times, they tend to back off a bit.

You've no doubt heard that moving a team that produces so-so software to an agile process won't improve the quality. They'll just produce it faster. However, using the skills you learn from this book will increase the quality of your software. And, over time, you may notice that it's sped things up too - whether you go agile or not.

In short, I strongly recommend this book for both beginning and experienced developers, no matter what methodology you follow. I found myself nodding in agreement more than a few times as I read, and I think you will too.

Oh, yes. One more thing. If you do nothing else, find someplace to read the Preface. Yes, that's right, the Preface. It's only two pages, but there's something worth learning right there. If you're not sitting in a bookstore, you can get it straight from the publisher at InformIT. If the link doesn't work, just go to http://safari.informit.com/9780321700469 then click the link for the Preface and enjoy.

“Essential Skills for the Agile Developer: A Guide to Better Programming and Design”
Authors: Alan Shalloway, Scott Bain, Ken Pugh, Amir Kolsky
Publisher: Addison-Wesley Professional; 1st edition (August 29, 2011)
ISBN-10: 0321543734 ISBN-13: 978-0321543738

Burk on Books - 97 Things Every Programmer Should Know

A little less than a year ago I told you about "97 Things Every Software Architect Should Know," a ground-breaking book O'Reilly had just published. I was very excited about the book for two reasons. The first is that the contents were contributed by experts from around the world under the Creative Commons Attribution 3.0 license, which means it's kind of an open source book. The second thing is that I wrote two of the 97 things chosen to be in the book.

If you read that post then you might share my feeling of deja-vu when I tell you that in a couple of weeks O'Reilly will publish a new "97 Things" book. This one is titled "97 Things Every Programmer Should Know" and once again I wrote two of the 97 things appearing in the book.

I'm hoping that programmers of all stripes will find the contents useful and interesting enough that it outsells the first book. If you'd like to take a sneak peek at the articles, they're available at the O'Reilly web site's 97 Things wiki.

If you like what you find there, please consider buying the book. No, I'm not suggesting you buy the book because I'm looking for a big royalty check. Remember the Creative Commons License I told you about? The only "payment" a contributing author gets is a free copy of the book. I want to boost sales for three reasons:

1. I think most developers will find it a valuable resource.
2. I think that good book sales will encourage O'Reilly to keep adding books to the series
3. I've got an idea for a 97 Things book I want to see in print.

If you do read the articles, please leave a comment here or send me an email. I'd love to hear from you.

Thanks for your time and attention,

Burk Hufnagel

Burk on Books - Groovy Recipes by Scott Davis

Almost a year ago I read "Groovy Recipes" and posted my review on DZone in early November. I also wrote up a posting for this blog but it never got published. The good news is that the book is still relevant and worth picking up if you're interested in getting things done in Groovy.

I would like to say that I actually held off posting this note so that I could create a second wave of interest after the initial one faded, but that would be misleading so instead I'll just hope it works out that way.

Burk

P.S. Scott, if you're reading this, the fact that I'm finally posting this mere hours before you're speaking at the No Fluff Just Stuff conference I'm attending later today is a complete coincidence. Really.

Burk on Books - Switching to the Mac, Designing Web Interfaces, and Essential JavaFX

Its been a while, but I've recently posted three new book reviews on DZone; Switching to the Mac and Designing Web Interfaces, and Essential JavaFX. While they cover very different topics, all of them are worth reading.

Essential JavaFX is a great introduction to JavaFX. You get a good feel for working with JavaFX without having to devote too many hours to it. The only thing I didn't like is that the images are gray-scale instead of color. I know it ups the printing cost, but when you're dealing with graphical user interfaces I think having color is important.

Switching to the Mac is a great book for those of us who have spent many years on Windows and finally move to a Macintosh. I bought mine almost a year ago and found that my previous training didn't help me on my Mac so I did what I often do. I went looking for a book to help me. After reading reviews of several books and leafing through a few at Borders, I decided on Switching to the Mac, and I'm glad I did. It's not the kind of book I read cover to cover, but it's stuffed with useful information. If you moving like I did, I think you'll find if useful to keep the book near your Mac for a while.

Designing Web Interfaces is an excellent book for anyone designing web applications. It's well written with plenty of color diagrams and screen shots (Yes!) so you can see how various interactions play out. I am a little disappointed though because there's no sample code even though the authors say they targeted the book for designers and developers. Even so, I think this is a great book for designers and a good one for developers who enjoy a challenge.

That's it for today. I've got three more reviews to write up, one book to read and review, and I think I'll be caught up.

BTW, I'll be at the the No Fluff Just Stuff software symposium here in Atlanta this weekend so if you're there and want to talk about the books, or any aspect of software development, feel free to introduce yourself.

One more thing before I sign off, this blog isn't intended to be a one way signal. If you want to ask a question or share a thought (preferably one that is relevant to the posting), please leave a comment.

Burk on Books - Pragmatic Thinking and Learning

Last year, Andy Hunt (co-author of the Pragmatic Programmer) authored a new book titled “Pragmatic Thinking and Learning: Refactor Your Wetware”, and I’d like to tell you a bit about it.

It’s a great book. You should stop reading this blog posting and go buy a copy of the book, then sit down and read it. Now.

OK. That was the short version, which is probably all that some of you needed to hear. The rest of this is for people who are looking for some details.

The book is published by the Pragmatic Bookshelf, it was released on October 28th, the ISBN is 1934356050, it retails for $34.95 and is worth every penny. Still not enough?  OK, I’ve got a detailed review posted on DZone in the IT Book Zone (at http://books.dzone.com/reviews/pragmatic-thinking-learning) and you can win yourself a free copy if you read the review, post a comment, and get chosen by the Fickle Finger of Fate.

If you’re still reading this, I’m guessing that you’re looking for some insight that’s not in my other review. OK, here goes: The secret to getting the most out of the book is that you can’t just read it. Andy’s put exercises in the book and you need to do them, and do them the way it’s described, to get the most out of it. This isn’t much of a secret because Andy tells you the same thing early on in the book, and in a podcast (“Andy Hunt on Pragmatic Wetware") which is available on the PragProg.com website or from ITunes. The reason I bring this point up is that it is very easy to know this and somehow still not do it.

The other secret is that reading the book (and doing the exercises) is still not enough. Just like Neal Ford’s book “The Productive Programmer”, you need to actually practice the things you read about. It’s not enough to think, “Cool! I love that idea!” Until you take action, and begin practicing what you’ve read about, you won’t really benefit from knowing it.

As someone more profound than I once said, “Those who do not read are no better off than those who cannot” or, more succinctly, “To know and not do is not to know.”

Thus endeth the day's lesson.

Burk on Books - Practical API Design

Practical API Design: Confessions of a Java Framework Architect

Author: Jaroslav Tulach

Published by: Apress on July, 2008

ISBN: 1430209739

If you write code then you are designing APIs and this book is for you.

Jaroslav Tulach, is the founder and initial architect of NetBeans and in this book he shares with us the lessons he learned during ten years of designing APIs that are used by developers around the world.

If others use your APIs, then the lessons found here are worth far more than the price of the book and the time it takes to read and digest it. Do yourself, and your users, a favor and start studying it today. And if others don’t use your APIs, then it might be that you need this book even more.

“Practical API Design” is divided into three parts: In part one, Jaroslav describes the theories underlying his approach to API design and his reasons for writing “another design book.” This section is reasonably brief and introduces the main concepts underpinning the rest of the book. In part two Jaroslav draws on his decade of experience and expounds on what works and what to avoid when designing frameworks and APIs for public consumption. Part three is where the rubber meets the road and Jaroslav shows how the theories and ideas from part one can be applied in daily life to achieve the practical application of the rules as described in part two.

The information in this book is relevant to every developer, though I will admit that some probably need it more than others. If you write code, you’re creating APIs - even if you’re the only one using them. If you’re creating APIs then knowing how to create and evolve those APIs benefits you and anyone who depends on those APIs to get things done.

For me, the bottom line on this book is that anyone who writes code winds up creating APIs, so it makes sense to learn how to create, evolve, and maintain them without breaking any code that already uses them.

There are some nice resources out there for anyone interested in learning more about this book. Here are just a few:

Jaroslav has created a website at “http://wiki.apidesign.org/wiki/Main_Page” with the intent of building a community around the book and the ideas he’s expressed in it.

Download chapter 1 from Apress at “http://www.apress.com/book/view/9781430209737”.

Check out InfoQ's interview with Jaroslav Tulach at “http://www.infoq.com/articles/tulach-practical-api-design”. In it there's a link to download chapter 3.

If you’re interested in learning more about the book, I have a more detailed review on DZone (and I’m told they may be giving away a copy) at http://books.dzone.com/reviews/practical-api-design.

Happy reading!

Burk Hufnagel

Burk In Books: 97 Things Every Software Architect Should Know

There's a new book available from O'Reilly titled "97 Things Every Software Architect Should Know: Collective Wisdom from the Experts" and though I'm very excited about it, I won't be reviewing it here. Actually, I'd like to post a review, but you probably would not trust it because I'm one of the "experts" who's "wisdom" was collected for the book.

The book is primarily a series of short articles on various topics that software architects deal with in the real world. All of the articles were contributed under the Creative Commons, Attribution 3, license - which means it's essentially an open source book. In fact, the 97 articles in the book are available online for free at the 97 Things web site. O'Reilly also has a preview available on their website so you can see the cover and what the articles look like in the actual book - unfortunately, my articles are toward the end of the book and the preview stops much earlier.

I recommend going to the web site and reading an article or three. If you like it consider buying a copy of the book. I say that not because I get royalties - I don't. Nor did I get paid for the initial writing. I'm suggesting you buy one or more copies because I want the book to succeed so O'Reilly will be encouraged to do more books in the same style; collecting contributions from community members who have something interesting to say and making them available.

The whole process of trying to come up with useful bits of information and explain them in an interesting way - before somebody else beat you to it was fun and challenging and I'd like to do it again. So please go take a look then come back and let me know what you think of it.

{Note to self: Come up with a good sign off line.} <- Yes I meant to leave that there. It's motivational. Burk

Burk on Books: Inside Steve's Brain

Inside Steve’s Brain by Leander Kahney
Published by Portfolio (the Penguin Group) in April 2008
ISBN: 591841984

“Inside Steve’s Brain” by Leander Kahney is a nice little read (7.2 x 5.4 inches and under 300 pages) that is both entertaining and educational. The Steve in the title is, of course, Steve Jobs and the book provides a look into how he thinks about things like leadership, user experience, product design, and teamwork.

The introduction describes parts of Jobs’ career and private life. The next six chapters focus on his personality traits and how they impact the way he (and Apple) works. The last two chapters describe how it all comes together and enables Apple to do things other companies seem to find difficult to emulate.

Each chapter ends with a list of “Lessons from Steve” and while we may not have the ability to follow all of them ( “Partner only with A-players and fire bozos” – who wouldn’t love to do this!) they are still worth remembering. The book includes a case study of how it all came together with the iPod, and ends with a look at why Jobs (and by extension, Apple) keeps producing closed systems (think iPod, or Mac) while the rest of the industry produces open systems that allow the user to plug in third party hardware. While this is controversial, it does make sense from a certain point of view; doing so allows Apple a tighter integration between the hardware and software, which means a more pleasant user experience with both.

The book is interesting and thought-provoking. Whether or not you are a fan of Steve Jobs and Apple, you must admire the loyalty of their customers base; they must be doing something right. Any of us should be thrilled if our customers felt the same about us. So maybe it’s worth spending a little time exploring the territory “Inside Steve’s Brain.”

P.S. You an go to a page on the book's website (http://insidestevesbrain.com/thebook.html) and see a three minute video of the author talking about the book. Or better yet, download the Introduction and see if it appeals to you before you buy the book.

Beating the odds by reading books

In my copious spare time (gained by not watching much TV) I read and review books, technical and otherwise, as a way of keeping up with the rest of the world. (You can read my most recent review here.) Usually I’m working on one or two books at a time (did I mention I love to read?) but I discovered some really interesting books in a short period and now I’ve gotten a little swamped. At this point, I’m reading three books and writing reviews for three others.

I posted one review to DZone.com’s Book Zone last Friday, but you won’t see it in their listing until the zone leader approves it. The other two are not technically technical (they aren’t specifically about programming or software development per se) but they are books I would recommend to developers and architects who need to communicate their ideas with others.

The review I posted is for “Groovy Recipes” by Scott Davis and it is a book I highly recommend for anyone interested in the Groovy programming language. As its title suggests, the book is full of recipes showing you how to get something useful done in Groovy. There’s even a section with recipes for Groovy’s web framework, Grails.

If you’re looking for a new language to learn, or you’d like to improve your skills with Groovy, this is an excellent choice to help you on your way.

“Presentation Zen” is the name of a web site as well as a book, both by Garr Reynolds. I found the web site when I was working on a technical session for JavaOne 2008. While I loved the approach Garr suggested, I was pretty sure I couldn’t pull it off in the time I had left to prepare. I stuck a more traditional approach and swore to myself that I would come back and learn to improve my presentation skills.

This book is full of good information and can point you in the right direction, but you (and I) have to do the work needed to improve - reading alone probably won't cut it. But, if you want to get better at presenting information then this is a great place to start.

The third review I’m writing is for a wonderful little book titled, “The Back of the Napkin” and it’s subtitle “Solving problems and selling ideas with pictures” pretty much lets you know what to expect when you read it. If you’re anything like me and most of the programmers and architects I’ve worked with then you’re probably comfortable sketching a diagram to describe a problem or solution to the people you work with. So why would you want to buy a book about it?

Well, take a look at the website Dan Roam (the author) set up for the book and watch the video on the five focusing questions and the six ways to see and show. That should be enough to get you to place an order for the book today. In case the site’s down or you can’t view the videos, the point is that Dan presents a well reasoned method to figuring out how to visually solve problems and present the solution to other people so they can understand it. From my point of view, getting better at those two things is well worth the price of the book and the time it takes to read it, and you can’t ask for much more than that.

I’ll update this post – or just post a short notice – when the reviews are done and out there. I also post to the Atlanta Java User Groups’ Book Corner so you may see them there first.

Oh yes, the title of this post is my way of thumbing my nose at the "statistic" I've heard concerning the average number of books a programmer reads in a year - which is supposedly zero. I don't know about you, but I'm doing my best to boost that number; and learning a good bit at the same time...

Dang. I just realized I'm going to need a good sign-off phrase to let you know I’m done and didn’t just hit the “post article” button by accident.