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.

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.

Coders at Work, by Peter Seibel

Fifteen prominent software engineers are interviewed here, focusing on the craft of programming, on how these people approach solving everyday problems in our business. The book evokes a feeling of a computer science version of Inside the Actor’s Studio. Questions like “How did you start programming?” and “What books should every programmer read?” and “What is the hardest bug you’ve ever had to track down?” lead to very interesting conversations about both the person being interviewed and the industry itself.

Surprisingly, these luminaries don’t consistently agree with each other about what is and isn’t important when coding. For instance, Brendan Eich is not a fan of design patterns: “Patterns are really just flaws in your programming language. Get a better programming language.” In the next interview, Joshua Bloch says, “[A book] I still think everyone should read is Design Patterns. It gives us a common language.” There is an element of truth in both opinions, which sparked an interesting conversation at our book club.

I also liked Peter Norvig’s opinion on TDD: “I think test-driven design is great. I do that a lot more than I used to. But you can test all you want and if you don’t know how to approach the problem, you’re not going to get a solution.” There is (rightly) a huge emphasis on testing and software quality these days, and I find it refreshing to find someone that recognizes that all the testing in the world is useless if the software doesn’t actually do what it is supposed to.

Donald Knuth, Guy Steele, Jamie Zawinski (who sounds like an ass), Fran Allen, Brad Fitzpatrick, Dan Ingalls, Douglas Crockford, L Peter Deutsch, Joe Armstrong, Bernie Cosell, Simon Peyton Jones, and Ken Thompson are the other interviews found here. With such diverse backgrounds, common themes such as a dissatisfaction with the level of complexity and size of programs today become even more visible. While I do more (shudder) management than coding these days, I still found this fascinating and recommend it to anyone in the software industry.

First Sentence (From the Introduction):

Leaving aside the work of Ada Lovelace—the 19th century countess who devised algorithms for Charles Babbage’s never-completed Analytical Engine—computer programming has existed as a human endeavor for less than one human lifetime: it has been only 68 years since Konrad Zuse unveiled his Z3 electro-mechanical computer in 1941, the first working general-purpose computer.

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.

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.

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.

Joel on Software, by Joel Spolsky

Joel on Software is a technical blog with topics such as software development, management, business, and the Internet; this book is a collection of some of the better essays. While he tends towards hyperbole and narcissism, Spolsky has a tongue-in-cheek style that I wish I had; a recent column, for instance, used a great quote: “Don’t fall for it. [Developers] also want M&Ms for breakfast and a pony.” Good stuff.

Probably due to the fact that the columns were written over about five years, Spolsky does tend to contradict himself. At one point he gives a rant showing a disdain for abstraction with which I don’t agree. (From his examples I think his real problem is with head-in-the-cloud architects and not abstraction itself, but it doesn’t come off with quite that message.) Later, though, he says that software design is extremely important which seems a very different direction. Another discrepancy is with bloatware; at first he makes very good arguments as to why it isn’t that big of a deal (as disk space gets cheaper and bandwidth becomes a commodity larger programs aren’t a problem; your annoying and useless gizmo is my must-have feature) but then later he laments the absence of a linker in .NET causing his software to be larger than it really needs to be. Hmmm.

A topic on which we don’t agree is interviewing. He likes candidates to write code during an interview and tends to use puzzle questions. To me, design ability is much more important than coding; good designers can always be taught to code while the converse isn’t always true. Puzzle questions while fun strike me as trivia questions; “How many gas stations are in LA?” is only useful the very first time a candidate hears it and the chances of catching someone that hasn’t seem slim. If you are going to ask trivia questions, at least make them technology specific to see how deep of an understanding someone has on a given topic.

Despite how it may seem from the preceding paragraphs, I agree with much of what Joel has to say. Daily builds, a commitment to testing, simple and clear documentation, and humor in the workplace are all important factors of a strong team. I’d recommend this book to any software developer or manager; even if you don’t agree with what Spolsky has to say you will at least think about it.

First Sentence:

Why do developers choose one programming language over another for a given task?

Java 5.0 Tiger: A Developer's Notebook, by David Flanagan and Brett McLaughlin

First a book about geeks, then a book by a geek, and now a book for geeks. I gotta get a life!

Tiger was the code-name for the most recent version of Java. This notebook details a bunch of the new features introduced in this release, and does a pretty good job of it. Generics is the feature about which I’m the most excited; for all Java’s hype as a type-safe language this was an aspect sorely missing. I’ve been a fan of generics ever since I worked on JGL back in the late 90’s. Many people are upset about the addition of templates (and most any change in the language), but then some people will bitch about anything. Fools.

The biggest complaint I have is that the chapter on the new threading and synchronization constructs was really rushed. There was as much space dedicated to enumerations as there was to the much more complicated topic of concurrency! Minor quibble aside, the authors do a good job of explaining the new features. It is a quick read and worth your time if you work in Java.

First Sentence:

Even with nearly 200 pages before you, its going to be awfully tough to cover all of Tiger’s new features.

Beyond Software Architecture, by Luke Hohmann

I read this book not quite a year ago, but let a friend borrow it before I blogged about it. There is a good story behind why I have it as well. The author is a friend of mine from the old days. Luke went to Michigan for college while I graduated from Texas. When they met in the Rose Bowl last year, we made a “governor’s bet”—if his team won I’d have to ship him some Texas BBQ, if mine did he was sending me California wine. As we all know, Texas was victorious and Luke was on the hook for some hooch! When he paid up, he included his latest book along with two bottles of wine. Good guy, that Luke!

This is a really good reference for anyone in the software business. The author covers everything from product naming to when to start over and rewrite the whole thing. Developers will receive an understanding of what the marketing folks do for a living, and non-technical people will get a peek into what it takes to actually write software. Everyone involved will start to understand how a software project should be managed as well, what questions to ask and when to ask them. The best part is that at the end of each chapter there is a summary and checklist of things your organization should be doing; this makes the book valuable not only as a one-time resource, but as something that can be used time and again.

One of the topics covered concerns technical debt. This is a concept I’ve been concerned with for a while at my current job, but didn’t have a solid term to define it. Technical debt is what a project collects when tasks are done “quick and dirty” instead of taking the time to think about the entire problem and solution. The effort that is needed to later fix the inevitable issues that arise from cutting corners are the interest payments on the debt. Virtually every decision that was made on one of my current projects for the past couple of years (before I joined, of course!) was made with speed in mind, and now the product is in such bad shape that it is difficult to make any sort of change at all with any degree of quality. I’ve been railing about this at the office, and Hohmann’s words have helped bolster my case.

First Sentence:

The foundation of a winning solution lies in the architecture that creates and sustains it.

Java Puzzlers, by Joshua Bloch and Neal Gafter

Early last week I came home and discovered a heavy envelope from FedEx waiting for me. I opened it and found a book—Java Puzzlers. To say I was surprised would be an understatement, as I hadn’t ordered it and in fact had never heard of it. Tucked inside the front cover was a note from the publisher saying the book had been sent with the compliments of the authors for my help on the project. My help? What help? The light finally went on when I found my name in the acknowledgements crediting me with puzzle 59. Back in 2002 I attended JavaOne (with Alex and Matt) and went to a great session about Java brainteasers. At its close, Bloch invited the audience to send in other puzzles for future talks; I sent him a couple. He used one of my ideas, and three years later he not only remembered this but sent me a gratis copy! Great guy, that Joshua Bloch!

I’ve always been interested in the trivia and minutiae around software technologies, and this book doesn’t disappoint. It is filled with tricks and obfuscations that can be found within the Java programming language. Things like, “When is i != i true?” [Click for answerWhen i == Double.NaN] I always learn more about how a language really works from something like this instead of a more traditional guide; it makes me think more and I seem to retain the knowledge longer. Even better, along with the soution is a lesson describing how to avoid the pitfall in your everyday coding. Good stuff.

Besides the puzzles themselves, a lot of thought went into this publication. There are optical illusions between each quandary, reflecting the misdirection that is the theme of the book. The title of each puzzle has an amusing name, many of which include hints as to the nature of the trick as well (my favorite: It’s Absurd, It’s a Pain, It’s Superclass!). Also, the layout is designed so that a puzzle always ends on the bottom of a right-facing page and so the answer is hidden from view reducing the temptation to cheat. Smart.

First Sentence:

This book is filled with brainteasers about the Java programming language and its core libraries.

Pragmatic Version Control Using CVS, by David Thomas and Andrew Hunt

If you already are familiar with cvs this book isn’t going to be amazingly useful. It outlines how to create and use a cvs repository and has some good recipes for common tasks. We have a couple of newbies at the office that had never seen cvs (or any configuration management tool!) and found it to be a really good introductory text.

First Sentence:

This book tells you how to improve the effectiveness of your software development process using version control.

Cube Farm, by Bill Blunden

I thoroughly enjoyed this book! It does a fantastic job of humorously describing the world of software development at a large(ish) company. I can’t count the number of times that the author described something that I’ve seen at my company! His depiction of the Web Group versus the Illuminati (code names for two groups within the author’s firm) is a scary parallel to BMC’s PATROL Express versus PATROL battles over the past few years. In addition to telling a very entertaining story, he calls out lessons in each chapter that we should take away from his tales of woe; again, BMC could learn from many of these: “Physical separation can facilitate rivalry;” or “Managers will often ignore a problem to make it go away;” or “If your boss substitutes consensus building for leadership, be afraid;” or “It sucks to live in Minnesota, unless you enjoy ice sports.” Well, maybe not that last one so much. If you are a fan of Office Space or Dilbert, then you’ll enjoy Cube Farm.

First Sentence:

In December 1992, after four years of intense study, I completed an undergraduate degree in physics from Cornell University.