Missing an Opportunity

Last month, I gave a talk to a company about Selenium testing. The talk was about some of the basics of starting to use Selenium, and some of the lessons I’ve learned about using it (see my previous two entries about some of my opinions). However, I got a question during the Q&A session, “Why do I need to refactor the tests and create all of those helper methods when I can just use grep and change things as needed?”, which I did not do a good job of answering. I keep replaying my answer in my head and wish that I had said more.

My answer was basically, that it is a real pain to just use grep, and how do you know that you’re changing the correct instances of the code? Their response, which is most likely accurate, is that they know and are comfortable with grep, and it solves their need.

My regret was that I should have stressed that the reader and maintainer of the tests should be able to look at the tests and understand what it’s trying to do and validate. If you have a set of Selenium steps that are 20 or 30 (I’ve seen 50) lines long, how is the maintainer of that code supposed to know what’s going on? How do they know which time in that sequence of steps, especially if there is duplicate Selenium, they should edit?

If I were asked that question again, I would focus more on the readability and maintainability of the code rather than getting into semantics of the use of grep. I would also refer the questioner to Clean Code: A Handbook of Agile Software Craftsmanship by Rob Martin and his story about how a team he consulted for which treated test code as a subclass and didn’t maintain the code. Soon their tests were no longer useful and had to be discarded because they were not held to the same standards as their production code.

Another solution for this problem, which I did not cover in the talk (out of scope for this discussion), would be to introduce the page pattern from Selenium 2. Even though I have not used it in production, I have found the idea very intriguing and think it can be helpful to teams starting up their web UI’s automated testing. There are several frameworks that have sprouted up using this pattern, most notably using Spok and Geb together.

My Favorite Technical Books

Over the years, my family has given me a lot of grief for reading technical books on the beach, during the holidays, or pretty much anytime. I read a lot of these books, and find them to be helpful in my everyday job as a developer or manager.

The most important characteristics of a good technical book include:

·      Well Written. I’ll freely admit that I’m not the world’s best writer. However, there are some books that need a good editor. There are typos and sentences where after the fourth or fifth reading I still don’t understand. My mother was an editor and writer for technical manuals, I just wish more authors would team up with a good writer more frequently. One example of a really well written book is The Well-Grounded Rubyist. It is a bit out of date now (pretty much any Ruby book is out of date by the time it’s printed), but the way David Black is able to express what he’s teaching should be duplicated in other books.

·      Concise.  I felt that the message, and lessons, in Domain Driven Design: Tackling Complexity in the Heart of Software by Eric Evans, are extremely important, but the verboseness of the book made it difficult to find those lessons. I find that the books, which give examples of their points in a clean and concise manner to demonstrate their points, tend to resonate with me.

·      Reusable. Don’t get me wrong, I like reading about a specific technology and doing a deep dive with it (I have version 2 and 3 of Spring in Action by Craig Walls and like them a lot), but a truly transformative book should be able to be used regardless of the specific technology.

Of all of the books that I’ve read, I would place the following three atop of the list:

1.     Refactoring: Improving the Design of Existing Code by Martin Fowler. This was the first technical book that was not about a specific technology, but rather about a mindset. This book is the one that made me start reading more technology books, not so much for the specific technology, but rather for the patterns I can use to go across different technologies. Even to this day, I have this book on my desk at work and will often open it, or refer to it. It is by far the most dog-eared book in my collection.

2.     Practices of an Agile Developer by Venkat Subramaniam and Andy Hunt. This is a very easy read, but probably has more lessons and topics covered per page than any book I’ve ever read. It is not a deep dive on any one topic, but covers many topics in an easy to follow and easily reference able manner. I liked this book as a kick off for other topics like TDD, pair programming and many other topics that interest me. While I was a manager, I gave this book to each of my new employees during their first week as homework. Each person learned something new and helped frame our discussions about how we work. On a side note, I often got the comment, “hey we’re doing a lot of the things in this book”, to which I just replied, “yup”.

3.     Clean Code: A Handbook of Agile Software Craftsmanship by Rob Martin. I only just recently read this book, but I wish I had read it sooner (like my first job out of college sooner). This book covers a wide range of topics, but the number one I came away with is, take pride of your work. Write your code in a way that when you look back at it in six months later, you still understand what’s going on because your code speaks to you. I have a suspicion that this book will soon be as dog-eared as Refactoring. If you’re a developer (in any technology), pick up this book and read through it, become a craftsman of your technology, and make the lives easier on those who must maintain your code after you’ve moved on.

Some other of my favorite books: Succeeding with Agile: Software Development Using Scrum by Mike Cohn, Dreaming in Code by Scott Rosenberg, Continuous Delivery by Jez Humble and David Farley, Driving Technical Change by Terrence Ryan, The Paradox of Choice: Why More is Less by Barry Schwartz, Domain Driven Design: Tackling Complexity in the Heart of Software by Eric Evans, Art of Agile Development by James Shore and Chromatic, Agile Retrospectives: Making Good Teams Great by Esther Derby and Diana Larsen, Design Patterns by the Gang of Four, and Career 2.0: Take Control of Your Life by Jared Richardson.

If you have some favorites, I would love to know what they are as I’m always looking for more to read. I just started Working Effectively with Legacy Code by Michael Feathers, and have Growing Object Oriented Software, Guided by Tests by Nat Pryce in my queue.