Three Book Reviews

Updated: Fixed the title which referenced two books when I’m actually reviewing three. Would have caught that off by one error had I written a test first…

Three long-overdue book reviews!

Debug It!

Debug It!: Find, Repair, and Prevent Bugs in Your Code by Paul Butcher, published by Pragmatic Press. ISBN 193435628X. This, coupled with David Agans’ Debugging, is a must-have on a programmer’s bookshelf.

Code goes wrong, systems get tetchy, and you need a logical approach to dealing with problems. Butcher’s book lays out lots of great tips and practices for finding, fixing, and preventing bugs in your software. I love his emphasis on empirical, measured approaches to troubleshooting, and I also like that he draws a clear border between finding and fixing bugs. You really do need to step back and take a breath after you’ve found a pesky bug, because you’ll want a different approach for fixing it and preventing other similar bugs.

“Debug It!” puts a great emphasis on controlling the environment and isolating one thing at a time as you work through finding bugs. Butcher’s sections making nondeterministic bugs deterministic and his logical steps for approaching bugs are wonderful. I also LOVE that he emphasizes, strongly, that the debugger is a tool of last resort. An important tool, but one to use only after you’ve exhausted other avenues. (I’m a firm believer the debugger is a time sink. Manually stepping through code is a horrible use of your time.)

Butcher covers a great many topics from the team’s culture to methodologies. Along the way he offers insight on tracking your bugs, practical tooling advice around assertions, and finishes up with a great section on Anti-Patterns. Here you’ll find some great reading around culture (had to work with a Prima Donna, anyone?), methodologies, and team culture (Code Ownership, FTW!).

This really was a tremendous book, and I highly recommend it!

The Manga Guide to the Universe

The Manga Guide to the Universe by Kenji Ishikawa, et. al. Published by No Starch Press. ISBN 1593272677.

I’ve gotten several Manga Guide to… books and they’ve all been wonderful. The Universe guide is no exception! The book’s comic-style is entertaining, although I could do without the weird females-as-sex-objects undertone, and the authors have done a great job bringing some really arcane, difficult topics to an understandable level.

The book weaves its education of the reader around a central plot where three girls are trying to write and create a school play. Their attempts to flesh out their storyline bring them in to contact with a number of other characters, each giving different insights into astrophysics, astronomy, and the historical evolution of science and theory in these domains.

I greatly enjoyed the historical aspect of the book – learning how scientists like Kepler, Galileo, and Copernicus made their discoveries is really fascinating. The book’s main storyline is interspersed with a lot of great sidebars on these practical matters in both historical and current contexts. You’ll read about how ancients attempted to measure distances of solar bodies, what dark matter is, how the universe was formed, and what scientists are working on currently.

This is another great addition to the Manga series, and I’m very happy to have gotten it!

The Agile Samurai

The Agile Samurai: How Agile Masters Deliver Great Software by Jonathan Rasmusson, Pragmatic Press. ISBN 1934356581.

I get many free books for review – this is one I paid for out of my own pocket and it was worth every penny. Clear, well-written, and extremely useful. This book stays very focused on what matters in building a successful agile practice without being preachy or vague.

Rasmusson doesn’t pull punches on silliness around “agile” being some silver bullet. He’s pragmatic and practical – and blunt when discussing schizophrenias like management by miracle (an unrealistic plan has a miracle event which results in working software. Yeah, that happens often!).

He’s also hard-nosed (in a gentle way) about the fundamental problem in any software project: poor communication. Consider this beauty from Chapter 3:

Q: What kills most projects?

A: The assumption of consensus where none exists.

Much of his book (well, so much of “agile,” really) is about ensuring clarity of communication.

Rasmusson walks you through a Project Inception workshop to “Get Everyone On the Bus” then moves on to the other standard agile topics. He does a wonderful job explaining user stories and estimation—one of the better jobs around points I’ve ever read—and he lays out a nice clear picture of why and how you should set up a visual workspace.

The book finishes up with a nicely done section on building the software. Rasmusson walks through the standard fare of test driven development, refactoring, technical debt, and continuous integration. If you’ve read much about agile you’ll likely not learn anything in this section, but its tone and content is every bit well done as the other sections.

I’ve read plenty of books on Agile. This one’s definitely in the top three.

Join NW Ohio .NET User Group for Their 10th Anniversary!

The great Northwest Ohio .NET User Group in Toledo is celebrating their 10th anniversary on Tuesday, 9/20. Richard Campbell will be presenting at their meeting, and rumor has it they’re having BBQ to top things off!

If you’re in the area I encourage you to head over and join them in celebrating their great milestone. Register at Eventbrite to help them keep an accurate headcount.

Maintainable Tests: Keeping Your Test Cases Focused

Maintainable and performant test suites are somewhat my addiction right now – simply because I’m finding more and more and more folks in every domain running in to the same sorts of problems: brittle, long-running test suites that end up sucking the life and morale out of teams.

Before you dive into a new project, or as you’re rethinking an approach to an existing one, take some time to consider what your test suite will evolve to look like. I’m not talking just unit tests, I’m talking your full stack of tests: unit, integration, functional, and perhaps even performance.

I’ve got a number of topics I’ll be writing on over a few posts, but this particular post centers on an easy win: keeping your test cases focused on what you really need to test. This means you need to cut out any unnecessary steps or UI goo that don’t pertain exactly to the functionality you’re testing.

In my Surviving Growing from Zero to 9,000 Selenium Tests talk at Rocky Mountain Ruby, I used an example of testing that User B can reply to a forum post from User A.

“As a user, I want to reply to another user’s forum post, so that I can create a conversation”

There are any number of things which don’t pertain to that test, including things like:

• Can User B log on to the system?
• Does User B’s name show up when she’s logged in?
• Can User B browse to User A’s forum post?
• Can User B properly format bold, italic, and hyperlink text in the reply?

Logging in to the system and browsing to User A’s original forum post might take you ten seconds, plus you need validation checks that User B actually did log on. If you have 800 test fixtures, and logging on and navigating to a point in your system takes 10 seconds for each test fixture, then you’re looking at 8,000 seconds just for that effort. 8,000 seconds / 60 seconds per minute gives 133-ish minutes.

That’s two hours of time spent just getting to the place where you need to actually do your test. Worse yet, if you have any problems with your logon or navigation functionality then you’re going to have false failures for those areas which masks potential failures in your post-a-reply functionality.

Look carefully at your system and see how you might be able to bypass those particular authentication and navigation issues. Maybe you can store a generated cookie for User B, enabling you to completely skip the logon process. Perhaps you can figure out how to navigate directly to User A’s forum post instead of using your system’s browse/search/whatever navigation.

Taking these steps can greatly reduce the brittle and slow nature of your tests.

Next let’s consider how you actually enter the text for that reply. Are you using a rich text or some other fancy editor? How does that editor render on your page? Is it locked in some iframe or other odd element that’s difficult to point your automation framework at?

Perhaps your system has an alternative editor that’s simpler to deal with.  If that’s the case, look to use that simpler editor instead–you’ll find your tests for interacting with content become much cleaner and easier to maintain.

I’ve talked with developers who’ve created completely different configurations for their automated testing runs where entire slices of functionality get cut out in order to simplify testing of other discrete, controlled areas.

These sorts of concepts—cutting out unnecessary steps and eliminating irrelevant functionality—pay off in spades as you continue evolving your test suites. Look very hard at each test case as you’re fleshing it out and ensure you’re not biting off automation of steps you don’t need to.

Please note I’m not telling you to skip testing your logon and browsing functionality. (Or whatever it is you decide to cut out.) You’ll definitely need to test those bits and pieces, but you can do them in isolation instead of throughout the rest of your test suite.

Keep your test suites running as smoothly as possible by staying focused on exactly what you’re trying to test. Figure out ways to cut out all the remaining cruft. You’ll be much happier.

Slides From Effective Distributed Teams Talk (Philly Day of Agile)

I’ve posted the slides from my Effective Distributed Teams talk at the Philadelphia Day of Agile up to SpeakerDeck.

Feedback on this session was extremely polarized. A few attendees felt I spent too much time covering forming the teams and what tools to look in to versus walking through specific problems around processes with distributed teams. That’s highly useful feedback and I’m considering how to possibly refactor part of the talk.

The other side of the feedback coin was extremely satisfying – there was a group of ten or so folks in the session who were highly interactive. I love these kinds of sessions where the audience dives in to the discussion with some questions and things they’ve been through. I got some wonderful input from a couple different attendees on how to get past cultural and language barriers, plus folks were great about sharing their own experiences with distributed teams.

I greatly enjoyed the chance to speak with the group, and I hope most folks got something out of it!

Rocky Mountain Ruby Conference Wrapup

Where to start? My great bosses at Telerik fully embrace some of my quirky ideas about diving in to different, new communities for us. As a result, I found myself right in the midst of a crowd of passionate Rubyists at the Rocky Mountain Ruby conference in Boulder, Colorado.

I was fortunate enough to get picked up for a session – I spoke in front of the crowd about my experiences being part of a team growing a Selenium test suite from zero to 9,000 tests. I also participated in a follow-on panel discussing testing as well as a panel discussing diversity in the software engineering industry.

I loved the format of the conference: a mix of Unconference, lightning talks, and sessions of either 20 or 30 minutes in duration. The overall conference is also single-track, so you’re able to avoid stressing about running around and deciding what sessions you’re going to miss.

My goal going to RMR was to chat up folks around long-running test suites and brittle tests. I had good fortune to get great discussions with folks I already knew and folks I’d just met. Here’s a surprise: long-running tests are an issue in the Ruby domain, too.  (Say it quietly, but they’re a problem in every domain…) I didn’t get any magic answers about solving the problem, but then I didn’t really expect to. What I did come away with were contacts to continue more detailed discussions later on.

The rest of the conference was also very rewarding. Every session I sat through was great, but there were several standouts for me.
•    Michael Feathers’ keynote. I’m sure he hears it all the time, but his Legacy Code book was extraordinarily influential for how I think about software. It was great to finally hear him speak.
•    Anthony Eden’s talk on building great APIs was tremendous. Work hard on making your APIs clear, concise, and simple. I’m hoping Anthony will submit this to CodeMash because it’s absolutely applicable to you regardless whether you’re writing Ruby, C#, Java, or Perl. Might not apply to assembly folks.
•    Jeff Casmir’s session on rescue projects hit home for a lot of reasons. The things he brought up rang very true with my own experiences, and I loved how he put out that there are many hidden costs for failed projects beyond just the financial bottom line. Rescuing a project is hard, hard work, but it can bring a set of tremendous personal rewards.
•    Justin Searls and Cory Flanigan’s talk on testing Javascript was really well presented. Paired presentations often fall flat. Justin and Cory had a unique, entertaining style that I enjoyed. (Because as a presenter myself I know how much work they put in to it.)
•    Avdi Grimm’s Exceptions talk re-re-reminded me that your team needs to sit down and hash out an exception handling strategy early on in your project. His talk was more on the mechanics of dealing with Exceptions and it was really need to see some intriguing ways you can deal with Exceptions in Ruby. I also had a great hallway chat with Avdi about development and testing in the embedded world. He corrected some of my misperceptions (based on previous work experience) about automated testing in the embedded world.
•    Mike Gerhard’s meditation talk/exercise was a wonderful way to start off the conference. He encouraged folks to do short meditations during the week and Tweet about them with the hashtag #devmed (which is developer meditation, not developer medication). I’ve used short meditation off and on to help me regain some balance during extremely stressful times in previous jobs. Mike’s session reminded me of other great benefits of meditation – you’ll be seeing #devmed Tweets from me starting next week.

The culture and atmosphere of the conference were extraordinary. I was really upset about being gimped up – I missed a lot of hiking and trail running – but I hope to be back next year and make up for that!

Thanks to the organizers for picking up my talk, and thanks to all with whom I had great discussions!