The Success of Open Source, by Steven Weber

Parts of this book are interesting and engaging, and parts are mind-numbingly boring. The author is a professor at Berkeley and his scholarly background shows through strongly. The history of open source software is fascinating, and Weber does an excellent job of walking the reader through its genesis at AT&T Bell Labs to the widespread acceptance found today. His description of open source as "an odd mix of overblown hype and profound innovation" is spot-on, and his comparison of open source to religion was insightful—anyone can read the Holy Bible without a "license" from a Christian sect. The description of the constantly evolving social dynamics of open source is similarly compelling. Where the book drags interminably is during the discussions of the economic and political bases of the movement. Sadly, these last discussions are interspersed through all the interesting parts, making me almost afraid of turning each page for fear of encountering a discourse on tracking "the institutional isomorphism literature by encouraging hierarchical governments to remake their security organizations as networks to interface successfully with their networked adversaries." Well worth your time for the history and underpinnings of open source, but unless you are a political scientist or economist be prepared for a bit of a slog.

First Sentence:

This is a book about property and how it underpins the social organization of cooperation and production in a digital era.

Domain-Driven Design, by Eric Evans

I first read this book several years ago. While recently cleaning the garage I found it again in a box from a previous job where I must have had it on a shelf. Flipping through it showed how much I'd forgotten, so I decided to read it again.

This is a great book, filled with deep concepts and clear examples. Evans says, "Software designs tend to be very abstract and hard to grasp. Developers and users alike need tangible ways to understand the system and share a view of the system as a whole." This is a great summary of what this text teaches. Many patterns are detailed, and approaches to design that are both simple and rarely found in the wild. Most software, even that with good initial design, tends to grow over time in ways that don't necessarily reflect the initial approach. This makes the code brittle and hard to reuse, the dreaded "code rot" problem. The impact can be greatly reduced with the creation of a ubiquitous language shared by all interested parties and a commitment to continual design, not just refactoring code. "One way or another, creating distinctive software comes back to a stable team accumulating specialized knowledge and crunching it into a rich model. No shortcuts. No magic bullets."

The biggest drawback to this book is that it is dense. Over 500 pages, and a lot of information is packed into every page. Makes reading it—at least at a pace where information can be distilled and remembered—take a long time. I suppose this is really a back-handed complement, as a text this complete should be expected to be substantial, but I found it took longer than usual to get through the whole thing. This is a book that every serious software architect should read, preferably on a regular basis!

First Sentence:

This eighteenth-century Chinese map represents the whole world.

Masters of Doom, by David Kushner

This is a fascinating and well-written history of first-person shooter video games and the two geniuses behind them, John Romero and John Carmack. The "Two Johns" are the gaming equivalent of Apple's Jobs and Wozniak, with Romero being the visionary and Carmack being a programming virtuoso. These two personalities initially combine with great synergy to create some of the greatest games ever made (Wolfenstein 3D, Doom, and Quake to name a few) but as success finds them they start to move in different directions. Eventually the conflicts are large enough Romero is fired from the company he founded with Carmack, signaling the beginning of the end.

This book reads more like a novel than a typical corporate history, which keeps it entertaining and captivating throughout. Thoroughly researched, the timeframes cover the rise of personal computers and the part games played in their growth. Hacker sub-culture and government outrage factor in largely as well, giving a holistic look at the rise of immersive computer games. I'm not much of a gamer myself (although I did play a fair amount of Doom back in the day at the office during lunch) but this book does a great job of keeping the subject matter interesting, focusing on the people rather than the games themselves. Highly recommended for anyone interested in the culture of computers or gaming in the 1990's.

First Sentence:

Eleven-year-old John Romero jumped onto his dirt bike, heading for trouble again.

Bitter Java, by Bruce Tate

It has been a while since I've read a Java book, and this one subtitled "The lessons taught by server-side Java antipatterns" seemed pretty interesting. It is amazingly dated, showing just how fast technology has changed in the last decade: CORBA, Microsoft FrontPage, and dial-up modems all feature in various examples. Most surprising was the authors insistence in using Vectors and Hashtables rather than Collections; Collections were already well-established in 2002 and wouldn't have made the code samples any more complicated. In a book largely concerned with efficiency and scalability I find this fairly surprising and bordering on irresponsible. That said, the writing is readable and engaging, and despite being behind the times the patterns presented are still applicable in today's world. I'd recommend this to a neophyte designer, but a more seasoned architect I suspect will find it pedestrian.

First Sentence:

On a cold day in Eastern Tennessee, my kayak is perched precariously atop a waterfall known as State Line Falls.

Version Control with Git, by Jon Loeliger and Matthew McCullough

I first came across Git at a previous job, but the person that setup and maintained the system had moved on. None of the other developers (including myself) had any experience with the tool and so we sort of made due the best we could but found the experience frustrating. As I'm starting an exciting new job where Git is in wide use I wanted to have a better understanding of the software; I've had good luck with O'Reilly books in the past so I picked up this one. Once again, O'Reilly doesn't disappoint.

Version Control with Git is a well designed reference, walking the reader through download and installation to the basic underlying principals all the way through advanced manipulations. The examples are both useful and obvious and the illustrations complement the text well; Loeliger makes even complicated topics like altering existing commits clear. There were some editing errors such as diagrams being printed in the wrong order and an odd way of sometimes referring to the very next sentence as if it were in another part of the book entirely, but nothing so major that basic understanding of the topic at hand was impacted. At this point I not only understand why git pull does not behave like svn update but also marvel at the possibilities of true collaborative development. I very much look forward to seeing how Git is used at my new job!

First Sentence:

No cautious, creative person starts a project nowadays without a back-up strategy.

The Lean Startup, by Eric Ries

I found The Lean Startup to be an easy and fun read. Taking on many of the same topics as the Poppendieck’s Implementing Lean Software Development but from more of a corporate or management perspective, Ries does an excellent job of describing exactly how one would go about setting up a new company with the ability to quickly innovate and become successful. The key is the Build-Measure-Learn feedback loop and reducing the time it takes a group to completely cycle through this process. Ries believes that you shouldn’t build anything without the ability to measure its success; in the agile software world this is very similar to well-defined acceptance criteria. Measuring is not only the normal quality metrics such as test coverage, but (and probably more important) customer acceptance. Having feedback from actual customers that your company is actually building the right thing is invaluable, and if you discover you aren’t going in the right direction, learn from this knowledge and pivot your behaviors.

The sections on choosing the proper metrics and tests to measure a product were by far the best part of the book. Ries calls traditional numbers used to judge products “vanity metrics:” total customers, gross revenue, and the like. Instead, metrics should be “actionable, accessible, and auditable.” Actionable means there must be a clear cause and effect for the data; if the numbers don’t reach a desired threshold it must be obvious what the next steps are. If web site hits suddenly increase, is it because of a better product or a PR campaign? If you can’t answer the question, you have a vanity metric rather than an actionable metric. Accessible means the reports are easily understood and provide a common frame of reference for everyone involved. Is a web site hit a successful login from a unique IP within a 24-hour period, or simply any request to the server? Auditable means the metric data is both black-and-white testable and easily available. If a test shows that a project should be killed, you don’t want the losers to challenge the veracity of the metric.

As with most agile processes, the ability to change is key. “As a movement, the Lean Startup must avoid doctrines and rigid ideology.” Other than the Lean doctrine itself, of course! The discussions here are quite broad; this is a book of ideas much more than a simple template to follow for success. That isn’t meant as a knock on the book, but that The Lean Startup should be only the first of many places a budding entrepreneur should begin a quest for success.

First Sentence:

Building a startup is an exercise in institution building; thus, it necessarily involves management.

Dealers of Lightning, by Michael A. Hiltzik

Several years ago I read Fumbling the Future about the failure of Xerox to capitalize on the creation of GUI-driven networked personal computers years before their competition. Dealers of Lightning is another look at the same PARC Labs organization, but concentrates more on the inventors than the inventions themselves. While equally compelling, Dealers of Lightning draws a different conclusion from Fumbling the Future: Xerox didn’t squander a golden opportunity, but instead the idea that a single company can remain in control of such a fast moving and constantly changing industry as computing is capricious and Xerox shouldn’t be blamed. While I agree the hardware/software trade is extremely fluid, the fact that Xerox—other than laser printers—has never been an important market player in this world still points to a serious lack of capitalizing on their intellectual property.

I hold a fairly low opinion of the predictive ability of most marketers and analysts (Gartner Group and Forrester Research especially). To me, these groups make broad forecasts and then reward companies with good reviews and placement in the appropriate magic quadrant that either pay them or develop product that make their predictions appear to be accurate. My cynicism aside, Dealers of Lightning provides a good overview of the perils of blindly following the path blazed by such divination. In 1981 Xerox conducted a series of market surveys that concluded “the Star was so good and latent demand so strong that customers would clamor for the technology regardless of price.” Of course, the Star sold for over $16,000 each and was a closed-system, competing with the open ~$5,000 IBM PC. Is it fair to hold analysts accountable for failing to predict that IBM would create a cheap machine that revolutionized the market? Maybe not, although Moore’s Law that foresaw exactly this was not only widely accepted in the industry but one of the founding principles of Xerox’s own PARC Labs.

While not a major aspect of the story, one line literally made me laugh out loud: “COBOL was the tedious programming language used for repetitive and uncomplicated business programs such as payrolls and budgets.” I currently work for Micro Focus, one of the leading maker of COBOL products in the world. There aren’t very many people in my company that would appreciate the language described as tedious and uncomplicated!

First Sentence:

The photograph shows a handsome man in a checked sport shirt, his boyish face half-obscured by a cloud of pipe smoke.

Inside the Publishing Revolution, by Pamela Pfiffner

The history of Adobe Systems is surprisingly interesting. The founders, John Warnock and Chuck Geschke, were visionaries in every sense of the word and their imagination reshaped the publishing industry. PostScript changed typesetting, Photoshop changed layout and design, and PDF changed printing itself. This book does a good job of describing the history of this revolution.

Inside the Publishing Revolution is told from an unflinchingly pro-Adobe point of view, but because the author doesn’t pretend to be unbiased it isn’t annoying. Being about Adobe, a company known for imagery, the book is gorgeous. Pictures are on nearly every page, many being creations by modern artists using only Adobe products. Truly, this is closer to a coffee table book than a corporate history. If only the same care had been taking with the copy editing.

The text is presented in chronological order, with scattered sidebars and inset time lines highlighting key and interesting events. Unfortunately, at times the text and the highlights aren’t well coordinated. The most egregious example is the note, “Geschke held for five days by kidnappers” in a sidebar; this is clearly a pretty intriguing fact, but there are no other details. Eleven pages later the kidnapping is explained, but for all the care taken with the images I found this to be really sloppy.

First Sentence:

If the modern publishing era began when Johannes Gutenberg developed movable type in Germany in the 1450s, its successor was the transformation that took root in Silicon Valley in the 1980s, when John Warnock and Chuck Geschke formed Adobe Systems.

Agile Testing, by Lisa Crispin and Janet Gregory

Agile isn’t about speed, it is about quality. While speed is obviously an attractive element of the methodology, if the resulting software is buggy then it doesn’t really matter how quickly it gets released. For many teams, especially young ones, how to work QA into a sprint cycle isn’t clear. This book is an excellent treatise into how testing and agile can work hand in hand.

Unlike waterfall processes, there usually isn’t a separate team responsible for testing in agile. That doesn’t mean that there isn’t a place for traditional QA personnel, though; in fact, a QA skill set is even more important because without a dedicated test team, developers end up doing more of the testing work. With dev executing test cases, the QA folks can apply themselves to exploratory testing, usability testing, and generally non-developer-think testing. The authors state “successful projects are a result of good people allowed to do good work;” this mix of skills and duties is what allows for both speed and quality to be maintained in a project.

What makes this book great, though, is that it covers not only roles and methods of agile testing, but metrics as well. Metrics are always an interesting topic in agile, because each self-organizing team will have different methods, making measurements difficult to standardize. The authors recognize this, and wisely warn against reading too much into the measures, too. “Having the number of unit tests go up every day is a nice bit of feedback... However, it is important to recognize that the number itself means nothing.” In this sense, the implication is that a large number of useless tests doesn’t add value, even if the metric is always increasing.

Easy to read, Gregory and Crispin have authored a very useful reference that should be on the shelf of every agile team.

First Sentence:

“Agile” is a buzzword that will probably fall out of use someday and make this book seem obsolete.

Flex 3 in Action, by Tariq Ahmed, Jon Hirschi, and Faisal Abid

I had said earlier I wasn’t going to read any more of the ... in Action series, but there were a few copies of Flex 3 in Action lying around the office so I took a chance. While it wasn’t as bad as the others I’ve tried, I was still left unimpressed. The text is little more than a walk-through of the various Flex API’s, but not detailed enough to be a reference manual and not enough explanation to be a teaching guide. Skip this book and instead look at the excellent video training series that Adobe hosts, or poke around on the Flex Cookbook site.

First Sentence:

This chapter makes the case why Flex is a great addition to your personal skill set or organization.

Implementing Lean Software Development, by Mary and Tom Poppendieck

This book examines the lean manufacturing approach pioneered by Toyota and how it can apply to software development. Lean boils down to seven principles: eliminate waste, build quality in, create knowledge, defer commitment, deliver fast, respect people, and optimize the whole. Many of these are familiar to agile proponents, but not all. Of particular interest to me was the last principle, optimize the whole. Developers have a strong tendency to suboptimize a problem, to “perfect” a small block of code without considering the bigger picture. Optimizing the whole means that instead of looking at an individual step you look at the entire value stream. When combined with a stop-the-line mentality that forces teams to solve problems rather than work around them, there is a lot of potential for not only higher throughput but for higher quality.

Another interesting idea presented here was set-based design: multiple teams solving the same problems at the same time in different ways. The thought here is you can have several groups all tackle the same issue, each taking a different approach or accepting a different amount of risk. They all work simultaneously, and at the end the best one of the solutions can be taken forward. I’ve never worked at a company that was willing to put this many resources towards a single problem but it is an intriguing concept.

Overall, a good book that any agile enthusiast should read. The writing isn’t as compelling as Tabeka or as interesting as Angus, but still well worth your time. Another winner from the Addison-Wesley Signature Series of books.

First Sentence:

Paris, France, July 1785.

Crystal Clear, by Alistair Cockburn

Crystal Clear is another one of the many agile management styles out there today. It is geared specifically for small collocated teams not working on life-critical systems. The wildly different chapter formats I found odd, but Cockburn explains it well: “It is not my ambition that every reader should like every chapter and format. Rather, my hope is that through the use of different perspectives, each reader, coming from his particular background, can find some chapter format that conveys what is needed in order to understand Crystal Clear’s main ideas.” A lot of the methodology doesn’t apply to my current situation (Crystal Clear demands collocation but my team is scattered all over North America) but I still found some interesting ideas here. One I particularly liked was that Crystal allows for teams to choose less-than-optional ways of working; as long as the team is delivering software successfully all is well. This is much more forgiving than many methodologies which seem to require striving for perfection. Another concept I like is the approach to risk: “A safe methodology is one that increases the likelihood of the project succeeding.” Most risk discussions revolve around what can go wrong; this spin of increasing success factors rather than reducing avenues of failure I find to be much more positive. Because of the focus on small teams this isn’t directly applicable to all groups, but everyone should be able to glean something useful from this book.

First Sentence:

I distilled Crystal Clear by asking successful small teams what they would keep or change in the ways they worked.

Why Software Sucks... and What You Can Do About It, by David S. Platt

Great book—a solid discussion about why most software is hard to use, told with enough humor to be enjoyable as well as interesting. “Computers make people feel dumb. In a society where nothing is ever the fault of person doing it, where people sue a restaurant when they spill their own coffee, getting users to blame themselves for anything is a magnificent accomplishment.” It reminded me a lot of Cooper’s excellent The Inmates Are Running the Asylum, especially when Platt was discussing UI design: “You should never see a confirmation dialog anywhere, under any circumstances.”

I did find it a bit repetitive; I suspect that this was originally a series of articles stitched together into a book. One anecdote about how Vanguard’s website is attacked 100 times per second is told multiple times, and the time frames jump around a bit with IE6 sometimes in beta and sometimes released. The overall theme of “programmers make complex things possible instead of simple things simple” remains consistent though.

Platt does an amusing job of sneaking his politics into his various stories. The quote in the opening paragraph is one example, getting snarky about the McDonald’s coffee case. He goes on a privacy rant at one point, upset about how the Patriot Act allows the FBI to look at your library records without consent. (Why people think privacy should be attached to the public library—itself a government agency—is beyond me, though.) He also seems to hold a grudge against market forces; he hates self-checkout lanes at grocery stores while at the same time being puzzled that Peapod.com hasn’t swept the nation. While the usability of the latter is clearly better than the former, consumers are clearly making the former more popular. He is probably upset that VHS beat out Beta, too.

Those nitpicks aside, this was a very good book, both entertaining and enlightening. I’d recommend it to anyone involved in the creation of software.

First Sentence:

“That’ll never sell,” I sneered at the title in the bookstore.

User Stories Applied: For Agile Software Development, by Mike Cohn

Every agile team is different. Team dynamics and synergy are key to a truly self-directed team, so every unique group of individuals will have to discover what works for them and what doesn’t. One thing on which most teams (regardless of how different they appear or behave) will agree, though, is that writing software specifications is hard. English is a notoriously imprecise language, and computers are meticulous to a fault; this combination is what makes requirements so difficult. The use of user stories and agile to combat this hardship is very effective, and Cohn does an excellent job of explaining these concepts.

The main idea behind user stories lies in the idea that a story represents a requirement, it doesn’t document it. The goal of a story is to encourage communication about what a feature is and how it should behave, not a treatise on the behavior that can be thrown over a wall to development. In the traditional software world, management will create a Product Marketing Document to define how they want every last feature to behave. Engineering will respond with a Functional Specification, which is a rewrite of the first document with a slightly different point of view. Development is then expected to go off for a year or so and create the product. Simple, right? Cohn discusses this approach, and sums it up with one of my favorite passages in the book: “Most of the times when I see two groups writing separate versions of essentially the same document I already know they are positioning themselves for the end-of-project blame sessions and for claiming to know the intent of the document. This type of silliness goes away with user stories. Along with the shift to conversations from documentation comes the freedom of knowing that nothing is final.” The phrase “nothing is final” frightens many executives with whom I’ve worked, but when you consider that all significant projects undergo changes during development (have you ever had a released application that exactly matched the original specification?) it really isn’t any different than reality, it just recognizes that change is inevitable and accounts for it.

Even if you are familiar with agile and user stories, this book is a great read. It is filled with examples both positive and negative and does an excellent job explaining not only what user stories are, but what they aren’t as well. These negative explanations in particular are quite valuable, as they compare and contrast many popular requirement gathering techniques such as Use Cases and IEEE 830. Looking at how these other approaches work helps clarify what the scope of user stories are supposed to be. I highly recommend this to agile teams, especially product managers and ScrumMasters.

First Sentence:

Software requirements is a communication problem.

Collaboration Explained, by Jean Tabaka

Collaboration Explained is a great book that works on two levels: both a treatise on a topic and an ongoing reference after the initial study. While there is a lot of good information about popular agile methodologies and fostering collaboration, where it really shines is on the topics of meeting facilitation. My favorite anecdote told of a company that had sign above each meeting room door: “If you have not received a purpose and agenda for this meeting, please turn around and return to your desk.” I sure wish I could work at a place like that!

At the heart of the book is the idea that collaboration is powerful. Tabaka mentions many familiar names that believe in this credo of “People over process” but somehow omits Michael Coté who named his blog with this phrase! She points out that with all the differences in the various popular agile techniques, collaboration is the “daily glue that agile teams apply in order to accomplish their joint undertakings.” As someone that follows general agile techniques but doesn’t subscribe to any particular methodology this rings especially true.

One of the collaborative tools that Tabaka discusses is the “fist of five.” This is a way of quickly gathering a feel for where the group stands on a particular issue with more granularity than a simple pass/fail vote. The idea is that you ask for a showing of the fist of five (I call this the “fiery fist of death” because I like to inject humor wherever I can—and I can never remember the “proper” name!) when you want to get a feeling for where the group stands on a particular decision/solution. Everyone then simultaneously holds up a hand extending fingers indicating their position:

1. Five fingers: this is exactly what we should do and we are geniuses for thinking of it.
2. Four fingers: a solid plan that I’m happy to implement.
3. Three fingers: I can live with and support this decision.
4. Two fingers: I have a problem with where we are and we need to keep discussing.
5. One finger: use any finger you’d like to express your feelings.

Of course, Tabaka doesn’t express the fingers in quite this way but the end result is the same. This is a powerful technique that I’ve found quite useful, especially in groups that like to hear themselves talk. When I think that we are starting to cycle in our discussions calling for the fist goes a long way towards ending deliberation and moving the group forward.

As I said earlier, this is a great book not only for the discussions but as an ongoing resource. Section IV is particularly valuable, containing templates for many different types of meetings commonly encountered during agile development. Any team leader can learn a lot from reading this book, and individual contributors will benefit by getting a better insight into what makes a group truly collaborative.

First Sentence:

With the current interest in adaptive, more reliable software development practices, project teams and their managers are taking a renewed look at the many people aspects that either contribute to or detract from project success.

Agile and Iterative Development, by Craig Larman

This is one of those books that is useful as both an ongoing reference and as an introductory text. It provides not only a walk through of several iterative software development techniques, but targeted resources for further reading at the end of each chapter and a FAQ and bibliography at the close of the book. The topics are presented in a narrative fashion with many illustrative examples, making for both easy reading and high retention; knowing Larman’s history of developing and presenting training courses this is no surprise. Much like Rothman’s Manage It!, one of the great things about this book is that it delves into things needed for success outside the development methodology at hand; for instance, wikis and mind-maps get mentions here even though they aren’t specific to any particular technique. Larman also does a good job of discussing both the positives and negatives of various approaches, where many competing books tend to avoid the trouble areas and stick to the party line. This holistic view of the world is what makes this text rise above its brethren.

Another reason I enjoyed this book is my connection with the author: we used to work together a decade or so ago at ObjectSpace. In fact, I was one of the guys that interviewed Craig before he joined. At the time I was working in C++ and Craig had mentioned that he had a brief acquaintance with the language. He was being considered for creating and teaching OOAD and Smalltalk courses as I recall, but as an excuse for Craig to meet more people in the company we were asked to get together. Craig had flown in from Canada for a day of interviews and the word in the halls was all positive going into our session. After introductions I started in on the standard C++ language questions and we quickly discovered that he was exactly accurate with his self-evaluation of “vague familiarity.” As the session petered to an awkward close, Craig suddenly perked up and reached into his bag, pulling out a small bottle (think hotel liquor sized) of Canadian syrup saying, “I brought this for you!” Turns out he brought syrup for everyone, but the timing of remembering a gift at the end of a clumsy discussion was priceless. Of course he was hired and went on to great things, but that remains one of my favorite interview stories.

First Sentence:

What value will you get from studying this book, an introduction to iterative and agile methods?

Core JavaServer™ Faces, by David Geary and Cay Horstmann

I found this to be a concise and informative volume discussing JavaServer Faces. It did a good job of showing both how the technology works and why it can save a developer time and effort. After reading it, I was able to look at a fairly complicated source tree using JSF and quickly make sense of it. As is the case with most technical texts these days it is laden with examples; this is both a blessing and a curse. Because Faces is a web solution, it needs a beefy technology stack to be useful; I thought the stack that the authors chose was discussed in much more detail than was needed. Towards the end of the book, there were a lot of orthogonal tools mentioned as well that seemed very out of place. While interesting, LDAP and Seam don’t have much to do with web front ends. All in all, a solid introduction to JSF.

First Sentence:

Judging from the job advertisements at employment web sites, there are two popular techniques for developing web applications:

• The “rapid development” style, in which you use a visual development environment, such as Microsoft APS.NET
• The “hard-core coding” style, in which you write lots of code to support a high-performance backend, such as Java EE (Java Enterprise Edition)

Spring in Action, by Walls and Breidenbach

This book irritated me so much it took me months to work up the desire to blog about it. I picked it up several months ago because I wanted to become more familiar with Spring, the development framework we are using at work. The general concepts s presented are fine, but as it turns out, nothing the (fairly good) doc on the Spring website didn’t cover. The reason I disliked this was that the examples were wrong. Not typo-wrong, but not-even-close wrong. I was so confused that I asked a co-worker that is very comfortable with Spring, and he was confused as well. Few books in this genre are error-free, but this was egregious. I’ve read most of Tapestry in Action as well (I didn’t finish it so I didn’t blog about it) and was fairly unimpressed with it as well. I don’t see myself picking up many more ... in Action books in the future.

First Sentence:

It all started with a bean.

Best Kept Secrets of Peer Code Review, by Jason Cohen

Code reviews are things that I believe are very important to a software development team. Not just because they can reduce defects before QA or the customer sees them, but because they help promote awareness of the codebase in general and provide critical mentoring opportunities to the team. The main message of this book is that the earlier you can find a bug the cheaper it is it fix, and code reviews are an underrated way of accomplishing this. While I agree this is true, I actually believe the mentoring aspects of reviews are actually more important—teach a man to fish and all that.

While loaded with interesting analysis, one detail rang a bit untrue to me. Cohen considers all items found in a review to be defects, but this is not always true in reality. For instance, asking that a comment be added doesn’t mean the code in question is unintelligible, but sometimes simply an explanation of why something was done (for instance, an API class is not marked final due to customer request). When mentoring, it is common to explain new techniques at review time as well; changing for(int i=0;i<longarray.length;++i) to for(long x: longarray) is not fixing or preventing a bug, but something that often happens as a result of a Java review. I believe this overly-broad interpretation inflates the numbers shown in the charts and tables a bit, but as it errs in favor of code reviews I find it easily excusable.

The author is the founder of Smart Bear Software, a company that not surprisingly has a product (Code Collaborator) that aims to ease the burden of doing code reviews. This certainly explains the focus on reducing the overall cost of bugs at the expense of mentoring—it is aimed at the people that control budgets, not the developers writing code. The self-published nature is also evident with something I expect an editor would have caught: the charts presented in landscape mode are turned on the wrong axis! He does reference Tufte, though, so I’ll assume there is some reason we have to spin the book counter-clockwise instead of clockwise.

All in all, this is a pretty interesting book. A lot of analysis and case studies went into it and a clear, convincing case in favor of code reviews is made. It skimps a bit on the mentoring aspects, but as those are probably much harder to quantify it is understandable. If you want to see a detailed look at why code reviews are good for a company, this should be your first stop.

First Sentence:

It was only supposed to take an hour.

Working Effectively with Legacy Code, by Michael C. Feathers

I bought this book at a conference I attended last year. The place I was working had a serious legacy code base and was in desperate need of refactoring. Unfortunately, I didn’t get too far into the book before I realized the development group there was no where near mature enough to accept this sort of change. The founder continually pestered me to stop spending so much time testing and just get software out. He honestly didn’t (doesn’t) understand the purpose of automated tests, much less any realistic quality process. Needless to say we didn’t get along too well and I left not long afterwards. My current employer also has a large legacy code base, but fortunately the organization is much more willing to embrace change. So, I picked this back up again as it seems now seems useful.

Working Effectively with Legacy Code is mainly a patterns book. It covers both how to get unruly code into an automated test harness and once there, how to refactor it. In general, refactoring is better covered in Martin Fowler’s Refactoring, but as the title suggests, many of the patterns here deal specifically with situations commonly found in legacy code: “Dependencies on Libraries Are Killing Me,” “My Application Has No Structure,” and “I Don’t Understand the Code Well Enough to Change It” are three chapter titles. As with most pattern books, it all seems very straightforward once you read it but before reading it you’d be hard-pressed to succinctly explain the techniques.

Many thoughts expressed here I wholeheartedly agree with. “Safety first. After the tests are in place, you can make the code much cleaner.” The echo of test driven development, this idea is essential to confidently modifying existing code. Without solid tests, refactoring is a guessing game at best. Feathers also recommends avoiding “big bulky unit tests that take forever to run.” In fact, he goes as far as saying that any test that takes 1/10th of a second is considered slow. In his mind, if it talks to a database, communicates across a network, or touches the file system, it isn’t a unit test. While I think that is taking things a bit too far, the sentiment is admirable.

Another interesting quote: “Architecture is too important to be left exclusively to a few people. It’s fine to have an architect, but the key way to keep an architecture intact is to make sure that everyone on the team knows what it is and has a stake in it.” This is exactly right. A good software architect is responsible for the big picture, not for the nitty-gritty details. If you are on a team where the architect does all the design and expects the developers simply to code up his designs, start looking for a new job!

One last message: when developing software, always keep your focus; do only one thing at a time. If you bite off too much at once, you end up thrashing. While especially true for refactoring untested or legacy code, this is very good advice for any development project.

First Sentence:

Changing code is great.