gpollice

Archive for the ‘Book Reviews’ Category

Book Review: Lean from the Trenches

In Book Reviews, Software Engineering on January 29, 2013 at 1:53 pm

Agile, Lean, Kanban, SCRUM, … . Will it ever stop? No! Frankly, change is good. However, change doesn’t mean that it’s good for you. In the last decade we’ve seen an increase in the number of “new” approaches to software development and each of these has the fanatics who claim that their approach is THE BEST approach to building software. What’s a practitioner to do? All we really want to do is create great software, and it seems that when we get into a rhythm, someone comes along to tell us how to to it better—and we often find things getting worse. Then we’re told that we’re doing it wrong and we need to bring in an expert to tell us how to do it right.

Ever since I worked for companies that have built software applications and tools, I’ve been amazed at the willingness of people to decide to do something because it’s a best practice. Well, let me say that I think best practice is code for: “We have a way of working and we want you to work that way too. This way of working worked for us, therefore it will work for you.” This is usually delivered by a consultant or salesperson who wants you to buy their services or product. (Full disclosure, I am a consultant at times, and I try to help people work better.)

The problem is that all of these best practices are usually stated as fact, and the context in which they are good choices are often left out. I continually see teams that decide to adopt a process or tool and fail miserably because that method or tool is not right for them. This can lead to another problem, rejecting all of the new way even though there are some good things that will help you work better. Most books on software development process tell you the “right” way of adopting a new process or tool, but they do so in a dogmatic way: “do this and this will happen.” There is a scarcity of books that focus on the experience of adopting and customizing new methods. Lean from the Trenches, by Henrik Kniberg. (Pragmatic Programmers, 2011) is a great stride forward in correcting this.

If you have been hiding for the last decade, you might not know what Agile and Lean methodologies are. If you haven’t been hiding, you’ve heard of them andy may have some idea what they mean. In order to get a clear description of them, start reading this book by going to chapter 17, Agile and Lean in a Nutshell. You’ll find everything you need to know about these two there. Then go back to chapter 1.

What makes this, in my opinion, a great book is that Kniberg describes what was done on a large project for the Swedish Police rather than talk about how to do things in a perfect world on a made up project. As you read the book, you’ll feel like you are getting helpful advice from an experienced practitioner who knows how to fit the process to the project rather than shoe-horning a project into a process. For each part of the project, you will see how a technique is implemented and, more importantly, why that particular technique or adaptation was chosen.

Kniberg covers all aspects of the project in the first part of the book. He describes the daily cycle and the practices that support them. Since they wanted to use a flow model, they adopted Kanban to their project. He describes how they scaled the Kanban boards and how they used the techniques and tools to keep on focus to the main goal of delivering value to the customer. Planning, tracking, scheduling, managing requirements—they’re all in this book, but you get a specific instance of the overall process, not just the description. You see it in action and you get to listen in on the reflections of what worked and why.

If you’re interested in making your team work better, I suggest that you get this book before going out and hiring a consultant. You’ll see that a) it’s not much more than common sense, b) it’s a lot of work, and c) you’ll need to continually adapt. If you understand that, the rest is about the details and they’re unique to your situation.

Book Review: Team Geek by Brian W. Fitzpatrick and Ben Collins-Sussman

In Book Reviews, Software Engineering on January 1, 2013 at 7:37 pm

Yesterday I posted a lukewarm review about Driving Technical Change. I had high hopes for it and it just didn’t resonate with me. Today is a different story and a great way to start off the new year.

The bottom like for this book is: If you’re a software engineer who wants to do great things, enjoy your work, and work on a super team, read this book! I’ve been going through a lot of books on the subject of technical leadership, soft skills for engineers, creating great development teams, and so on. I’ve found a few that I thought were quite good and they either have become or will become part of the material for my software engineering, and other software engineering based courses. But this book trumps them all so far. If you only read one book in the next year on this topic, read this book.

The authors, Ben and Fitz, work at Google. They’ve held several positions with Google and other companies. They have been associated with the Subversion open source project for years. In short, they’re real engineers who know how to build and shop software. They also have a great insight into what it takes to build a great team, how to keep it together and growing, and how individuals can become a part of such teams.

Ben and Fitz have clearly experienced many of the same types of organizations and personalities that I’ve encountered over the course of my industrial career.When I read an early section, “The Contents of this Book are not Taught in School,” I was hooked. They say “At press time, we’re not aware of any curriculum that actually teaches you how to communicate and collaborate in a team or a company. Sure, most students are required to participate in a group project at some point in their academic career, but there’s a big difference between teaching someone how to successfully work with another person and throwing him into a situation of forced collaboration. Most students end up jaded by the experience.” Well, if you’ve been in one of my software engineering classes, you know this isn’t true. That’s exactly what I try to teach and pretty much the way I do it. These two and I share a similar mind set.

The book describes several types of people, and provides stories of how to get these different types working well with a team while maintaining a team’s culture. They have great stories that I was able to identify with. They don’t try to mold these stories into patterns. They just tell it like it is—and it works for me. I finished the book in a few hours of enjoyable reading.

Ben and Fitz have had the opportunity, it seems, to have been able to choose the types of teams they work with as well as the type of companies that they’ve been employed by. Not everyone has that luxury. What the authors think dysfunctional companies and organizations are simply the norm for a lot of folks. Don’t let that put you off if you’re in one of those type of organizations. You’ll find good advice on how to navigate through the bureaucracies and get things done.

If you are a software engineer—whether you’re starting out or have been at it for years—read this book if you want to be better at what you do and if you want to get more satisfaction from your job. If you don’t get anything out of it, you are either the perfect software engineer (which is about as real as the Easter Bunny) or you’re in the wrong profession and should probably look for something else to do. The time spent reading this book will yield many rewards.

Book Review: Driving Technical Change by Terrence Ryan

In Book Reviews, Software Engineering, Uncategorized on December 31, 2012 at 3:43 pm

I’ve been going through several books lately on technical leadership. I’m interested in this for my software engineering course as well as a course on software project management that I’m putting together with a colleague. I was hoping that this book would have some real gems that I could use for material for these courses.

When I started the book, I was pretty excited. The table of contents started out with the right topics, in my opinion—Defining the Problem, Solve the Right Problem. But that was about the extend of the usefulness for my purposes. After this, the author goes into identifying various archetypes that one might encounter in software projects. These are the Uninformed, Herd, Cynic, Burned, Time Crunched, Boss, and Irrational. In order to give his choices credibility he applies the “Pattern” buzzword to them. I think he definitely identifies many of the characteristics that software developers encounter, but they just didn’t form a unified picture for me. It might be the fact that he keeps using adopting version control as one of his main examples. I don’t think this is a major issue today, but I could be wrong.

Ryan then goes into techniques for helping sway the opinions of the types he defined. The descriptions are not overly detailed, nor do they need to be. Scanning through the techniques to get a basic understanding of what they are and how to use them is worth the reader’s time. These will add to your toolbox of soft skills that you can use to be a more effective member of the team. These are not leadership techniques, but ones that any engineer can use to help introduce change to a project team or organization. The ones I found most relevant to my career are Gain Expertise (I just think of this as continuous learning), Demonstrate Your Technique, and Create Something Compelling.

The final section is a set of strategies one can adopt to systematically get changes adopted. After reading the first two sections, this should be almost self-evident to a smart reader.

If I were grading this book, I’d give it a B-. It’s somewhere in the middle of the pack for me as far s books that would help software engineers become leaders and effective team members. I think that even though the book is relatively short (213 pages), it could have been presented just as effectively as a series of a few blog posts—maybe that’s how it started.

The bottom line, from my viewpoint is: if you have some extra money for books on soft skills, it won’t be wasted on this book, but if your budget is more limited, look for a book that has more bang for the buck.

Cucumber is Cool and so is The Cucumber Book

In Book Reviews, Computer science, Software Engineering, testing on December 1, 2011 at 2:37 pm

So, I’ve been learning Cucumber—a tool for writing executable acceptance tests—in preparation for my upcoming course, Testing for Developers. The course will be heavy on the theory of testing, but from the viewpoint of the developer. How do you build testability into your code, what techniques can you use, and what tools are there that will help you do test automation. Most of my students will already know the basic xUnit tools, but we will be going much more into mock objects and other techniques for writing really good unit tests. We’ll hit Test-Driven Development (TDD) hard and we’ll look at how TDD and Behavior-Driven Development (BDD) work together, etc. We’ll also be wanting to work with embedded software systems and building test tools when necessary, or at least the glue to help tools work together.

This is an ambitious undertaking. I had heard about Cucumber when I looked at RSpec several months ago. RSpec was a bit too limited for what I wanted. Then I got a copy of The Cucumber Book by Matt Wynne and Aslak Hellesøy, published by The Pragmatic Bookshelf. After reading most of the book and a few weeks of playing around with Cucumber, I’m hooked. Cucumber takes the place of several tools I was thinking about introducing to my class, and allows me to into depth in several areas, using a single platform. If you’re thinking about learning Cucumber, or want to learn something about it, get this book.

The style of the book is great. It’s easy to read and describes how to use Cucumber in several bite-sized pieces. Some readers  may even find that the pieces are nibble-sized and want bigger bites. I urge you to avoid this. Install the software and go through each exercise in the steps described, even though you know what you might need to do in the next few steps. This will help you develop your intellectual muscle memory for using Cucumber. Take time to taste each bite, no matter how small it may be, because there is some new spice that was added that might be subtle if you skip over the step.

The first part of the book, chapters 1-6, introduces you to Cucumber fundamentals. Actually, this part does a little more. It teaches you something about BDD as well. If you’re really not interested in learning about BDD, you can skim chapters five and six, but I would not recommend skipping them. By the end of the first section I was able to do some useful things with Cucumber and used it to demonstrate requirement specification to my current undergraduate software engineering class.

The second part of the book, chapters 7-10, are chapters you need to read and work through if you want to become competent with Cucumber. Again, some of the discussions seemed too small to me, but after reflecting upon what I learned, I think the level is just right. Some of what you learn in this part of the book is how to work with some other tools to use databases and Web pages in your testing.

The third part of the book is one that does not have to be read in any special order, or even at all. But, if you really want to understand how to use Cucumber to define and (acceptance) test Web applications (written in Rails or otherwise) and other types of applications, you need to have these chapters available. So, skim them at least and then refer to them as necessary.

Is there a downside to this book? Well, not to the book itself. The fact is that Cucumber, like many other open source projects works in a specific inter-dependent ecosystem. Setting up Cucumber and its dependents and other pieces you might want like Sinatra, Capybara, etc. can be frustrating; especially if you want to do this on multiple platforms. If you’re not a Ruby expert, you may run into problems and will need to do some searching for answers or post to the forum for the book at the Pragmatic Bookshelf. But don’t let this scare you away. Cucumber is a good tool to learn. Whether you use it regularly or only for special occasions or specific projects, you will think a little bit differently about how you build software.

Book review: Seven Languages in Seven Weeks

In Book Reviews on July 23, 2011 at 12:00 pm

When I received my copy of Seven Languages in Seven Weeks: A Pragmatic Guide to Learning Programming Languages by Bruce Tate (Pragmatic Programmers, 2011), I wasn’t expecting to be impressed. First of all, I had read Tate’s From Java to Ruby and was not impressed by the book. I don’t usually read books aimed at managers, which may explain my disappointment. Also, how much real meat could be in a book that covered seven languages in less than 350 pages? Why most books that try to cover one language often push 1,000 pages—not that anyone in their right mind would actually read the full tome.

To my surprise, this book turned out to be a delight. This book doesn’t serve you the full language in a multi-course meal. Instead, it lays out the small tapas and lets you sample just enough to let you see if you like the taste. And, if you do, it gives you enough to keep you going until you order the full meal from another book, course, or combination of sources. What’s even more interesting is how Tate has selected tasty languages that each tantalize different parts of your intellectual pallet.

There are no common, “fast food” languages like C, Basic, or even Java here. Instead Tate offers avant-garde  languages that are gaining traction—or being rediscovered because they offer new paradigms or efficiences that we need for future applications and computing systems. His choices are Ruby, Io, Prolog, Scala, Erlang, Closure, and Haskell. Few people will know enough about all of these, and even if you do know something about all of them, the chances are that you’ll gain some additional insights.

Tate helps the reader approach each language by framing it with several questions that one should ask when learning any new language. These questions are:

  • What is the typing model?
  • What is the programming model?
  • How will you interact with it?
  • What are the decision constructs and core data structures?
  • What are the core features that make the language unique?

I recently used the chapter on Ruby to introduce the language to high school students. It worked wonderfully. When they were done, several of them decided to use Ruby for their project and did some very nice work in the span of about five days.

The book can be read comfortably in a weekend, but that’s like going to a wine tasting and chugging down everything in sight. Take your time with these languages. Use the seven weeks, or at least a few. Taste deeply and then decide which ones you want to learn more about. It will be a fun ride, and certainly worth your time.