java hosting


Title
Author
Publisher
ISBN
Reviewed by
Review text
Category

Your search returned 116 matching documents



Agile Software Development
by Alistair Cockburn


Addison-Wesley Professional
1 edition
October 2001
304 pages
Reviewed by Junilu Lacar, March 2002
  (10 of 10)


Like so many blind men around an elephant, we each have views of Software Development based on our own limited experiences. In this one of two anchors to the Agile Software Development Series, Alistair Cockburn presents his view: Software Development is a cooperative game.

From this perspective, Cockburn builds a vocabulary that we can use to identify with and learn from experiences and observations that he and other practitioners of agile methodologies such as XP, Crystal, Adaptive, Scrum, and FDD have shared throughout their careers. He shares these experiences and his thoughts about them and how they support his view.

Written for experienced developers and managers, the book makes you reflect on what should be valued for any software development effort to be successful. Still, less experienced developers would do well to read it if only to gain the vocabulary. The vocabulary will help you see things that you would have otherwise not noticed. And if you don't notice something, you can't learn from it.

The appendices are particularly interesting. One discusses the Agile Manifesto and the values it sets forth. Cockburn adds his own reflections on those values. Another presents three articles that have influenced Cockburn's view and includes, of all things, the writings of a 17th-century samurai.

This book has me convinced that Cockburn's view comes very close to describing the true nature of the huge and complex beast that is Software Development. This book should prove useful for many years to come.

Discuss book in the Saloon — More info at Amazon.com


Peopleware / Productive Projects and Teams
by Tom DeMarco & Timothy Lister


Dorset House Publishing Company, Incorporated
second edition
February 1999
245 pages
Reviewed by Mark A. Herschberg, April 2002
  (10 of 10)


This is my all-time favorite software engineering book. Peopleware accurately recognizes that software engineering is about people, not technology. It looks at the many facets of human issues in the software development process, and shows why people aren't simply cogs in a software development machine.

The book spends a lot of time focusing on teams, and making you appreciate the value of teams. It is not the usual 'teams are good' BS in a generic management book. Instead it focuses on what makes a good team, and just how hard it is. For managers trying to build or run a team, this book will help you recognize the skills and techniques you need to do so successfully. It won't teach you about a development process. It will teach you how to make your development process work by getting you to recognize the value of people in software development. (But it's not just for managers, I strongly recommend this book to everyone, from the most junior engineer to the CEO.)

The book also contains large section on the office environment, and provides a lot of strong evidence as to why conventional wisdom doesn't work. I turn down jobs based on what I've learned from this section alone!

Oh yeah, this book is a little different from most books out there, it provides hard evidence based on years of research.

This book fundamentally changed my views on software engineering!

Discuss book in the Saloon — More info at Amazon.com


The Pragmatic Programmer - from journeyman to master
by Andrew Hunt, et al


Addison-Wesley Professional
1 edition
October 1999
352 pages
Reviewed by Frank Carver, November 2000
  (10 of 10)


One of a very small number of general software development books which disdain the ivory tower of theoretical methodology, and deal with real, practical issues. It covers a broad sweep of the craft of software development, with examples for a variety of languages and systems, in a light yet detailed style. I cannot recommed this book highly enough. If you are just embarking on a career in software development this is a great way to get to the heart of what it's all about. Even if you have been developing software for years you will find yourself nodding in agreement at some points, smiling at others and wondering why you never thought of the rest. The pull-out card of 70 "tips" is worth the price alone. Keep this book where you work, and dip into it. Often.

Discuss book in the Saloon — More info at Amazon.com


Creating a Software Engineering Culture
by Karl E. Wiegers


Dorset House Publishing Company, Incorporated
1 edition
August 1996
358 pages
Reviewed by Mark A. Herschberg, April 2002
  (8 of 10)


This is a book about software project management, but from a different perspective. It is targeted for first line managers. Like most books on project management, it covers the basic steps found in most development cycles. Unlike most books on project management, this one is specifically designed to promote good cultural practices. In that sense, this isn't a good first book on project management. However, it is a good second book. The chapters are full of good advice on what institutional and team policies help to promote good software practices among engineers. Each chapter includes a summary, list of helpful tips (culture builders and culture killers) and a list of references.

Although this book is aimed at managers, as with most books of this nature, all levels of engineers can benefit by reading it. You can use the tips in this book to either improve your own engineering culture, or to identify the problems in your group, that you just haven't quite been able to put a finger on.

Discuss book in the Saloon — More info at Amazon.com


The Cathedral & The Bizarre
by Eric S. Raymond


O'Reilly
1 edition
October 1999
288 pages
Reviewed by Mark A. Herschberg, April 2002
  (7 of 10)


This book is a must read for anyone involved with open source software. Eric S. Raymond is truly the voice of the open source movement.

This book contains his major essays on open source software. The Centerpiece are 3 essays. The first discusses why open source software works and can challenge closed software for institutions and private companies. He then goes on to describe the workings of open source projects and what the major protocols are for claiming and working within that space. The third essay describes the economic models which Raymond believes can make open source project financially viable.

The essays are easy to read an insightful. Even people who aren't involved in open source projects directly, should consider reading these essays in order to better appreciate the growth effect the open source movement is having in the field of software.

In the tradition of open source, the central essays are available online, and can be found at tuxedo.org I found the essays so stimulating that I bought the book anyway. (There is a little more to the book which isn't online, as well.)

Discuss book in the Saloon — More info at Amazon.com


The Mythical Man-Month
by Frederick P. Brooks, Jr.


Addison-Wesley Professional
second edition
August 1995
336 pages
Reviewed by Mark A. Herschberg, April 2002
  (7 of 10)


This book is a classic in the field of software engineering. I consider it a must read. I first read the book for MIT's 6.033 class, but have read it again twice since then. The book is an easy read, broken into a number of small chapters. Fred Brooks describes his experiences and lessons from working on the IBM 360 project.

The chapters themselves vary in usefulness. There are some timeless pieces, such as The Mythical Man-Month, The Second System Effect, and No Silver Bullet. Every engineer should understand these terms. Other topics can be a bit dated, but still teach some meta-ideas which can value even today.

Brooks cuts through the general technological optimism, as true today as it was then, and discusses the issues which really matter in software development. He focuses on the project-level issues which causes software efforts to fail.

If possible, get the 20th anniversary edition. It includes 4 more chapters, as well as a summary of points.

Discuss book in the Saloon — More info at Amazon.com


Agile Software Development with Scrum
by Ken Schwaber,Mike Beedle


Prentice Hall
1 edition
October 2001
158 pages
Reviewed by Frank Carver, June 2002
  (6 of 10)


This book is a strange mixture of trendy agile methodology and dusty corporate management. My guess is that it has been hurriedly re-edited based on an old draft to try and catch the Extreme Programming (XP) bandwagon.

Scrum is fundamentally a management technique, aimed at getting the most from development teams. As such it shares some principles with the new programming methodologies but, tellingly, many of the things which can lower the stress and help make software development fun are absent. There's no "40 hour week", developers are encouraged to put in whatever is necessary, even if it means working all night. There's no "Pair Programming", and mere programmers are actively discouraged from contacting the customers or users to get instant answers and decisions.

Where Scrum scores is in heavyweight, bureaucratic organizations, and its team isolation techniques can help to get a more extreme approach off the ground. Be prepared to abandon it like a first-stage booster if you do get XP into orbit, though.

The production quality of this book is poor. The illustrations are laughable pixelated screen dumps, and the same information could have been got across in a book half the size.

If you are a team leader of a project in chaos, and need a way out, this might be just what you need. But don't ever forget that your team are people, not just "resources".

Discuss book in the Saloon — More info at Amazon.com


Why Does Software Cost So Much?
by Tom DeMarco


Dorset House Publishing Company, Incorporated
1 edition
December 1995
237 pages
Reviewed by Mark A. Herschberg, April 2002
  (4 of 10)


I bought this book based on the name of the author alone. It is a collection of essays, some published, some unpublished by Tom DeMarco, over the last few decades. I must say I was a little disappointed by the book; although, in fairness, it is only because I hold the author in such high esteem and consequently expect so much from his works. The essays vary greatly in topic, from good software practices, to video equipment, to teamwork, to a recipe for pasta e fagioli. In that sense, a good half of the book really isn't relevant for many software engineers on the line. Of the other half, much of it is treated better in his book, Peopleware. Fortunately, Tom DeMarco is insightful enough, and a good enough writer, that what key points he does make which apply to most developers, are very valuable. Is the book worth the time and money it costs? Yes. There just may be other books which are more efficient under this metric.

Discuss book in the Saloon — More info at Amazon.com


Extreme Programming Applied
by Ken Auer and Roy Miller


Addison-Wesley Professional
1 edition
October 2001
384 pages
Reviewed by Junilu Lacar, April 2002
  (9 of 10)


As with other books in the XP series, I found this one both depressing and inspiring. Depressing because it again made me realize how much I have yet to experience. Inspiring because it gives me reason to think that there may yet be hope for me, what the book aptly describes as a "pitiful programmer", and others like me.

If "XP Explained" is the rule book, this is the play book. You should probably read XPE before this book to understand the philosophy on which it is based. Written for developers and technical managers who are interested in doing XP but are not quite sure how to start, it focuses on six of the twelve XP practices that the authors consider "critical starting points" of XP. Much of the advice given on how to introduce these six practices is based on the authors' experiences with XP although there are numerous sidebars relating other people's experiences.

One of the most refreshing things about this book is that even though the authors are recognized pioneers and practitioners, they do not come across as being XP zealots. They describe what worked for them and pretty much leave it up to the reader to decide whether or not it could be useful in his or her own situation. There were some parts that I felt the authors could have elaborated further but overall they succeed in giving useful advice to help you get started with XP.

Discuss book in the Saloon — More info at Amazon.com


Java Tools for Extreme Programming
by Richard Hightower, Nicholas Lesiecki


Wiley
1 edition
December 2001
544 pages
Reviewed by Frank Carver, February 2002
  (9 of 10)


You can happily ignore the main title of this book. Sure there's a nod toward extreme programming, but that's not what this book is really all about. This book is a fine introduction to a whole bunch of really useful tools to boost your Java and especially J2EE programming. And all the tools can be downloaded, source code and all, for free! There are too many tools to list here, but they include the best-of-breed Ant build system, JUnit, HTTPUnit, ServletUnit and Cactus test frameworks, load and performance analysers and some great libraries for interacting with other servers.

Two major test cases are carried through the book to show the benefits of each approach. Each tool covered gets at least a chapter of tutorial, and some of the major ones also get an appendix of API and configuration information.

This book was almost too useful to review. It's been open on my desk from almost the minute I got it and has greatly improved many aspects of my development process. If you want to get up to speed quickly and practically on a load of useful, powerful, tools - get this book. Everyone I've shown it to has wanted their own copy ...

Discuss book in the Saloon — More info at Amazon.com


Extreme Programming in Practice
by James Newkirk, Robert C Martin


Addison-Wesley Professional
1 edition
June 2001
224 pages
Reviewed by Frank Carver, July 2001
  (9 of 10)


I have spoken and corresponded with a lot of people about Extreme Programming (XP). I've encouraged them to read Extreme Programming Explained - Embrace Change and the other XP books. I've shown them some products produced using XP techniques. But somehow it's always been really hard to explain. Now I know what was missing. I needed this book. It's not a big book, but it powerfully expresses how XP works and, more importantly, what it feels like. The authors kept detailed notes when they first implemented Extreme Programming with a fairly simple web/Java/database project, and they give a blow-by-blow account of it. This is not an idealised case study; they made plenty of mistakes, but they show how the team learned from them. All the Java code for the project is shown as it is refactored. All the user story cards and task/time tracking are shown as the project progresses. If you have read or heard about XP but want to know what it's really like, this is the book. It's not much of a reference, but it's a terrific introduction.

Discuss book in the Saloon — More info at Amazon.com


Planning XP
by Kent Beck


Addison-Wesley Professional
1 edition
October 2000
160 pages
Reviewed by Frank Carver, May 2001
  (8 of 10)


Kent Beck and Martin Fowler have to be something of a "dream team" for a computer book. Not only was this book informative and interesting, but I actually enjoyed reading it. The book crackles with ideas and sparkles with a subtle wit. The content of the book covers all aspects of planning, managing and tracking progress on an XP (Extreme Programming) project and is a worthy companion to Kent Beck's anthemic XP Explained. Hard stuff missed out from the earlier work such as how to estimate how long things will take, how to write user stories and how to organize the details of iterations and releases is explained in a straightforward way. It also introduces a few new key XP concepts, showing that this radical methodology didn't spring fully formed into the mind of Beck, but is still evolving. One such key is "Yesterdays Weather", the idea that you can't go far wrong by using past performance as an initial guess for future results. If you are at all intrigued by the new "agile" methodologies, read XP Explained and then this one. Then buy a few more copies for your management.

Discuss book in the Saloon — More info at Amazon.com


Extreme Programming Installed
by Ron Jeffries, Chet Hendrickson, Ann Anderson


Addison-Wesley Professional
1 edition
October 2000
288 pages
Reviewed by Frank Carver, May 2001
  (8 of 10)


This book is part of a series with "Extreme Programming Explained" and "Planning Extreme Programming", and needs to be viewed in that context. "Extreme Programming Explained" is the manifesto, designed to get you fired up about the subject but thin on detail. "Extreme Programming Installed" covers some of the same ground, but focuses on real-world examples and advice on how to make Extreme Programming really work. Jeffries and the team are not afraid to face up to things people have trouble with in real situations. The book covers dealing with difficult managers and customers, deciding what needs testing, making pair programming work for you, and lots more. The bulk of the book goes through the practices of Extreme Programming step by step, but some of the most useful stuff is contained in the so-called "bonus tracks" which appear at the end. The book also has a large and interesting annotated bibliography. Well worth reading, but I'd recommend that you start with "Extreme Programming Explained", then read this one if you like the idea, but want a more practical approach.

Discuss book in the Saloon — More info at Amazon.com


Extreme Programming Examined
by Giancarlo Succi, Michele Marchesi


Pearson Education
1 edition
May 2001
592 pages
Reviewed by Frank Carver, July 2001
  (6 of 10)


I was disappointed with this book the moment I saw it. Most of the books in the "XP Series" are slim and concise. This one runs to 570 pages - it's not quite a Wrox tome, but it's still too big for my liking. It's not like the rest of the series in style, either; it's just a collection of thirty-three unrelated articles all by different authors. On one hand, there is probably at least one article in here for anyone interested in XP. On the other, there are probably several that won't interest you at all. Some articles describe experiences, some describe other methodologies similar to XP, and some focus on specific practices within XP. And some are very academic - stochastic math anyone ? The articles which comprise this book are so varied that it's hard to give an overall recommendation. You really need to study the contents page and dip into a few articles to see if there is anything to tempt you to buy this. As a shared resource for a large team or library it's a good purchase, but for an individual it might be a doorstop after reading the ten interesting pages. If you are interested in XP, but not heavily using or researching it, then go for the other XP series books instead.

Discuss book in the Saloon — More info at Amazon.com


Extreme Programming
by Kent Beck


Addison-Wesley Professional
unknown edition
October 1999
224 pages
Reviewed by Paul Wheaton, April 2000
  (6 of 10)


This book is in the recommended section although I have some mixed feelings about that. I want to give it an excellent review because of the author's connections to Martin Fowler, my favorite author. But I can't. I ended up comparing the book, perhaps unfairly, to Mr. Fowler's books. The writing style is not as good and the concepts seemed too far fetched. Granted, there are several interesting ideas, but I found the overall approach... well... too extreme. I do think that this book will change programming culture for the better. Definitely worth browsing. Since many engineers are reading it, you might want to read it just to be hip. :)

Discuss book in the Saloon — More info at Amazon.com


The Rational Unified Process, An Introduction
by Philippe Kruchten


Addison-Wesley Professional
second edition
March 2000
320 pages
Reviewed by Paul Wheaton, October 2000
  (6 of 10)


The official Rational Unified Process could fill several crates. Most of the ideas revolve around "Create Software by Giveing Lots of Money to Rational Corp." In my opinion, RUP is waaaaaaay too much process. But! This intro book gives a good summary. In fact, I think if most projects used a process that was about 10% to 20% of what you find in the book, you would be doing pretty damn good. If you come to a company that has no process, or is using a waterfall/cascade process, the first chapter of this book can be a lifesaver! Good graphics and good, convincing stuff for the iterative process.

Discuss book in the Saloon — More info at Amazon.com


The Wiki Way: Collaboration and Sharing on the Internet
by Bo Leuf, Ward Cunningham


Addison-Wesley Professional
unknown edition
April 2001
464 pages
Reviewed by Frank Carver, September 2002
  (7 of 10)


A "Wiki" is a web site, where every page is editable, by anybody with a browser. It may seem wierd, but it's a very powerful, and successful, idea. The most well-known Wiki has been running since 1994 with thousands of users. This book covers how and why Wiki works, case studies of use, and installing, configuring, and customizing an open-source Wiki supplied on CD. If you know a little about Wiki, and want more, this is a great book. It's sprinkled with practical advice and gives real code examples for enhancements. It can also be inspirational and has got me buzzing with ideas. It has a fine index and all the "tips" are listed for easy reference. Wiki's obscurity is its greatest weakness, though. If you have never heard the term "Wiki", you would never think to pick up this book. I also found that the assumption of Perl in the example software sections clashed with the language independent nature of the theory and case-study sections. And beware that the book ignores or glosses over a few things which require more effort than in other systems. If you find it clumsy or slow to get things on a web site, if you are looking for an easy way to let people collaborate, or if you just want to make sense of all your scattered notes, read this book.

Discuss book in the Saloon — More info at Amazon.com


Agile Sofware Development Ecosystems
by Jim Highsmith


Addison-Wesley Professional
1 edition
April 2002
448 pages
Reviewed by Johannes de Jong, April 2003
  (8 of 10)


The agile development movement is a potpourri of processes, ideas, methodologies, principles etc. for making better software, which has taken our industry by storm. For someone that starts his investigation / journey in this potpourri, the task must be very daunting. But Jim's book comes to the rescue.

It is the perfect introduction to the Agile movement. He briefly describes 7 major Agile Ecosystems, just enough to let one get an overall feel for it. But he goes further, he interviews the actual "inventors" behind these Ecosystems. These interviews give one some rare and fantastic insight as to the reasoning and ideas of these mover-and-shakers when they decided that the old methodologies had to be replaced with something more suitable.

The book is also full off case studies where the Agile Ecosystems were used. What I find refreshing is that not only the successes were discussed, but also the failures disappointments with the chosen Agile ecosystem.

He ends his book with an section to determine if your company is ready to become an Agile company and to help you design a custom Agile methodology, because that is the main message of this book, you must find an Agile ecosystem that works for your company.

If you aren't into methodology type books, still go and get it for your manager, because it can change your life.

Discuss book in the Saloon — More info at Amazon.com


Test-Driven Development by Example
by Kent Beck


Addison-Wesley Professional
1 edition
November 2002
240 pages
Reviewed by Jason Menard, March 2004
  (6 of 10)


This Kent Beck title is an introduction to the world of Test-Driven Development (TDD). The book teaches the concepts of TDD by working through two complete sample projects. Along the way, Beck gives the reader valuable insight into the thought process and techniques behind successful test-driven development. When the reader has finished working through these sample projects, he should know enough about TDD to get started working on a TDD project.

The book is divided into three sections. The first two sections are each walkthroughs of the aforementioned sample projects using TDD. The third section is a collection of notes and useful tips to try to get the most out of TDD. If you've ever read anything from Beck, then you should be familiar with his style. If you haven t, Beck is an engaging enough writer, and the text flows smoothly and is fairly pleasant to read.

It would help to be familiar with some member of the xUnit family prior to reading this book. Beck uses Java and JUnit for the first section, but never really goes into discussing the JUnit API. Readers unfamiliar with xUnit may have no idea how to proceed with writing their own tests using one of these frameworks. True the API is simple enough that its functions may be ascertained simply by reading the code, but this is no reason not to provide explanation. The second sample project is an actual implementation of xUnit, so a bit more information may be gleaned here. Beck made the curious decision to use Python as the language of implementation for the second project, although he does provide explanation of the language's fundamentals. Finally, none of the sample projects are really complicated enough to do more than get us going on the path of TDD. There will still be many hurdles to climb when working on a real-world project.

If you are seeking a basic introduction to test-driven development, then you might enjoy this title. If you are a Java developer interested in exploring TDD more in-depth, there are better books out there.

Discuss book in the Saloon — More info at Amazon.com


Addison-Wesley Professional
1 edition
November 2002
240 pages
Reviewed by John Wetherbie, May 2003
  (7 of 10)


This book to introduces programmers to Test-Driven Development (TDD). The book is divided into three sections: the first two take the reader through the development of tests and code for multi-currency arithmetic and an automated testing framework. The third section presents patterns for Test-Driven Development.

TDD can help (or make) you think about interfaces. On page 4 the author writes: "When we write a test, we imagine the perfect interface for our operation. We are telling ourselves a story about how the operation will look from the outside. Our story won't always come true, but its better to start from the best-possible application program interface (API) and work backward than to make things complicated, ugly, and 'realistic' from the get-go." How very true!

One problem I had was that I found myself thinking: "C'mon, hurry up! Why is this simple little thing taking so long?". The answer is that the author is showing you how TDD works and that it is OK to take small steps. The author writes: "Remember, TDD is not about taking teeny-tiny steps, it's about being able to take teeny-tiny steps. Would I code day-to-day with steps this small? No." I needed to remind myself of this from time-to-time.

This book is a very good introduction to Test-Driven Development. It contains software development nuggets that can be applied whether or not you are using this development approach.

Discuss book in the Saloon — More info at Amazon.com


Project Retrospectives
by Norman L Kerth


Dorset House Publishing Company, Incorporated
1 edition
February 2001
268 pages
Reviewed by Mark A. Herschberg, June 2003
  (9 of 10)


Project Retrospectives is a must have book for anyone who wants to run a post-mortem or other types of post project analysis. It is a soup to nuts book on how to run a retrospective. The book covers the mechanics of running a retrospective as well as a discussion about the philosophy and purpose of such tasks. The centerpiece is a cookbook of great, creative exercises. Included with each one, in fact, throughout the entire book, is a discussion on the psychology of the exercise, along with references for further reading. For those interested in providing consulting services in this area, there are also chapters covering the process of selling retrospectives to potential customers.

The book is extremely well written and a very quick and easy read (it took me a about 12 hours). Even those who don't run retrospectives will find this book useful. Certainly anyone participating in such an activity can benefit from a better understanding of how it can work (and will gain ideas to make their company's retrospectives more fun and insightful). The final chapters also include some discussion on conflict resolution in the workplace and ideas for promoting a good culture in the workplace.

Discuss book in the Saloon — More info at Amazon.com


Code Reading: The Open Source Perspective
by Diomidis Spinellis


Addison-Wesley Professional
unknown edition
June 2003
528 pages
Reviewed by Thomas Paul, June 2003
  (5 of 10)


Programmers need to be able to look at code and analyze what it does in order to change it or fix it. The concept behind this book is to use many of the open source code samples to discuss how to read code and how to spot potential trouble areas in code. Unfortunately the book doesn't stay focused on this single goal and that detracts from its overall value. The book spends too much time explaining the basics of programming instead of concentrating on reading code. It also bounces around from one language to another, from C to C++ to Perl to Java, which is very confusing. For example, if you are a Java programmer do you really care how the C compiler optimizes strcmp calls? And what does that have to do with reading code?

Some of the advice is fairly basic such as try to realign indentations properly and replace complex code structures with simple placeholders when doing analysis. Although there are parts of the book that are excellent, too many of these good parts are wrapped under what should be basic concepts to anyone reading code. How can you debug a Java program, for example, if you are unfamiliar with abstract classes, libraries, or polymorphism? Do you really need a book on code reading to explain basic object oriented programming?

Overall, the book seems very unfocused and I really can't recommend it.

Discuss book in the Saloon — More info at Amazon.com


Sams Teach Yourself Extreme Programming in 24 Hours
by Stewart Baird


Sams
1 edition
November 2002
480 pages
Reviewed by Ilja Preuss, July 2003
  (8 of 10)


This book is bigger than the typical XP book. That can be partly explained by its scope. Most chapters, of course, explain how to do XP, but there is more. It starts with a short history of software development and methodologies, reasoning about the forces that brought XP into existence. The two chapters on how to start implementing XP in your team/organization are certainly very valuable. And finally there are also discussions about alternative and complementing agile processes.

The chapters (called hours) are of mixed quality. Especially the ones about organizational aspects are quite good -- my favorite is the one about pair programming. When it comes down to actual coding, the book seems to be oddly concentrating on tools instead of practices. Unfortunately, single chapters are also a little bit confusing -- sometimes the sentences just don't connect; some of the hours would possibly have been better shortened a bit. All in all it is a nice read, though.

If you want to know how you can integrate XP in your own coding practice tomorrow, this book won't help you much. On the other hand, if you are interested in learning the concepts of the whole process, if you want to introduce XP to your team or organization, this book would give you a good kickoff. It still won't tell you all you need to know, but it will make you aware of the key concepts. And the well-compiled references will do the rest.

Discuss book in the Saloon — More info at Amazon.com


The Rational Unified Process Made Easy
by Kroll and Kruchten


Addison-Wesley Professional
1 edition
April 2003
464 pages
Reviewed by Panagiotis Varlagas, August 2003
  (10 of 10)


This book helps you understand RUP and how to apply it to your projects. Authoritative authors: Kruchten and Kroll are the top technical and management guys in Rational respectively.

Read chapter 2, which captures the "Spirit of the RUP", the 8 tenets of the RUP philosophy. Master these core concepts, since, to apply the RUP, it is not sufficient that you know the product components, but you have to understand which ones to apply and how.

Chapter 3 is most useful. It charts the territory of processes out there (XP, agile processes, heavyweight assessment standards like CMM), and helps you understand where RUP falls in the picture.

Skip chapter 4, which explains RUP phases in the context of a one-man project.

Chapters 5-9 expound on the 4 RUP phases. Chapter 10 is product-specific. Chapter 11 is extremely important; talks about adopting RUP in your organization and proposes treating RUP's adoption as a project of its own, applying some sort of "meta-RUP" on it. Chapter 12 discusses planning an iterative project. Ch. 13 covers "antipatterns" - important reading; some stuff (e.g. the discussion on what constitutes a bad use case) are useful in a context broader than RUP.

Following are chapters discussing each role's (PM, Architect, Analyst, Developer, Tester) RUP perspective. I liked the discussion on "Good Enough Quality" in the Tester chapter. A "must-read"!

All in all, a good and useful read. Get it if only for chapters 3, 13, and 18.

Discuss book in the Saloon — More info at Amazon.com


Effective Project Management
by Robert K. Wysocki, Rudd McGary


Wiley
third edition
August 2003
504 pages
Reviewed by Valentin Crettaz, August 2003
  (9 of 10)


Project management activities are often seen as a waste of time even though they are at the core of any project. Various studies demonstrate that many projects have failed because they lacked the appropriate project management support. Properly managing a project is a difficult, but very important aspect of any kind of venture, be it academic or industrial, small or big, short- or long-lasting. This book introduces existing project management methodologies and best practices, and explains how to successfully manage a project from inception to completion.

The first two bestselling editions of this book have successfully taught the Traditional Project Management approach (TPM) and imposed themselves as the definitive guide to effective project management. This third edition completely covers the first two but it has undergone a major rework to introduce Extreme Project Management (xPM) as well as a new approach, called the Adaptive Project Framework (APF) that bridges the gap between TPM and xPM. This new project management framework is suitable for those kinds of projects for which the TPM and the xPM approaches are inadequate. APF has proven to be very successful in many real-world projects. APF is good tool that teaches you how to better deal with changes and how to anticipate and expect them.

In summary, this book can be of great value to both experienced and inexperienced project managers. It is bundled with a CDROM containing all MS Powerpoint slides of every figure, and a trial edition of MS Project 2002.

Discuss book in the Saloon — More info at Amazon.com


Bug Patterns in Java
by Eric Allen


Apress
1 edition
October 2002
264 pages
Reviewed by Nathan Pruett, October 2003
  (8 of 10)


This book boils thirteen of the most common bugs down to their root causes and formulates them as 'bug patterns'. Each bug pattern describes how to identify the bug by the symptoms it exhibits, why the bug is occurring, and gives one or more suggestions to fix it and prevent it from occurring again.

If the bug you are searching for isn't covered, the author also describes a methodical approach to tracking down bugs efficiently and quickly. Suggestions on how to prevent bugs from occurring in various stages of the development cycle are also presented, which are helpful even if you aren't currently searching for a bug in your code. Most of the suggestions are based on the XP development model, but the practices that are important are pointed out so they can be incorporated into any other style of development.

Even though debugging doesn't sound like a fun topic, the author has a very readable style and is able to get you excited about preventing and fixing bugs. The chapters have been very well thought out and the book is broken into topics very well.

This is a great book to partner with a 'best coding practices' type of book, like 'Practical Java' or 'Effective Java'. Those books are really good at describing how Java should be coded. This book gives examples of why those practices should be followed, and how to quickly get back on track when they aren't and something goes wrong.

Discuss book in the Saloon — More info at Amazon.com


Balancing Agility and Discipline: A Guide for the Perplexed
by Barry Boehm, Richard Turner


Addison-Wesley Professional
1 edition
August 2003
304 pages
Reviewed by Lasse Koskela, October 2003
  (8 of 10)


Reality check. Balancing Agility and Discipline focuses on saying out loud what people in the trenches have been thinking all along. There's still no silver bullet -- we need a well balanced tool bag instead of a multipurpose hi-tech hammer.

The authors start the journey by describing the fundamental differences between traditional, plan-driven approaches and the latest agile methods. This is a great introduction and paves the way for the discussion to follow. However, occasionally the text uses the term "agile process" too loosely when really talking about the extreme characteristics of XP.

Next, Boehm and Turner set out to describe a typical day in the life of two teams; one agile and the other not so. However, these stories didn't quite reach the level of detail I was expecting.

The authors continue by presenting two case studies of projects where a plan-driven method was streamlined using agile techniques and an agile method was scaled up with some plan-driven elements. The subject is of great interest and the authors' approach is definitely valid.

A decision tool for customizing an appropriate mix of agile and plan-driven ingredients is explained. The tool itself is largely based on Boehm's earlier work and focuses on risk management. The authors illustrate the mechanics of the tool by presenting a family of applications of varying levels of stability and complexity. The rationale behind the thought process for composing the optimal method is valid and built on well-known truths.

The last third of the book is populated by numerous appendices. The first appendix introduces some popular agile and plan-driven processes and maturity models in the form of two-page summaries and comparison tables. The summaries serve as useful reminders but nothing more. The rest of the appendices, however, provide a short but valuable collection of tools for balancing the software development process and some empirical data on the costs and benefits of agility.

In summary, I would classify Balancing Agility and Discipline as a suggested reading for both agilists and sceptics. It's not necessarily a classic but it certainly serves as a useful reminder of things the industry has learnt the hard way and shouldn't be taken too lightly. Agile methods promote retrospectives. Boehm and Turner suggest extending that retrospective a bit farther.

Discuss book in the Saloon — More info at Amazon.com


Agile and Iterative Development: A Manager's Guide
by Craig Larman


Addison-Wesley Professional
1 edition
August 2003
368 pages
Reviewed by Lasse Koskela, October 2003
  (9 of 10)


I was expecting a lot from this book, having read and enjoyed Larman's prior work. On the other hand, I expected it to be somewhat simplistic as the title implied the target group being managers, which I am not. One of these expectations was correct.

Larman's latest presents a wonderful introduction into what iterative and evolutionary development is about. The word "agile" in the title seems a bit displaced as the text mostly discusses about "iterative" and "evolutionary" rather than "agile", but that really is no big deal because what's inside the covers is pure gold for any one.

After a thorough introduction to the theory, Larman drops a bomb on the table; the chapter titled "Evidence" is worth the salt alone. Larman has collected an impressive list of references to early, large projects employing iterative and evolutionary development. He also reminds us how the creators of predictive planning based methods have themselves preferred an iterative approach from day one.

The book also packs nice descriptions of four iterative and evolutionary processes, namely XP, Scrum, UP, and Evo. The descriptions are clear but, to some degree, repetitive.

Although the chapter on evidence is definitely the gold chip, the last 70 pages proved to be a very pleasant surprise. Larman presents a list of practical tips and tricks for adopting and running iterative processes, as well as answers the toughest questions in a Q/A section.

Highly recommended. Have your boss read it as well.

Discuss book in the Saloon — More info at Amazon.com


Extreme Programming with Ant
by Glenn Niemeyer, Jeremy Poteet


Sams
1 edition
May 2003
456 pages
Reviewed by Ilja Preuss, November 2003
  (4 of 10)


As the subtitle "Building and Deploying Java Applications with JSP, EJB, XSLT, XDoclet and JUnit" indicates, this is a tools book. Consequently, the Extreme Programming practices are merely used as a motivation to introduce new Ant features into the build process - and sometimes this feels rather far stretched. In many cases, a good XP team should try a more team- and less tool-oriented solution than presented in this book. Also, the repeatedly mentioned "lead developer" coming to important decisions by himself feels quite contrary to XPs "Whole Team" practice.

So the book concentrates on covering Ant, and starts quite promising in this regard. Using a case study to show how a build script can evolve with the needs of a project is a nice idea, and the introduction to Ant is concise and to the point. Unfortunately, the book later starts to rush through the topics, much of it covering how to integrate different tools into the build process. There are also some much-less-than-optimal examples, which makes you wonder about the depth of knowledge of the authors; they even show a hand-made solution to implementing boolean attributes for custom tasks, even though Ant comes with a much more elegant inbuild mechanism.

This book still taught me interesting new things about Ant. I'd guess most beginners would be better off with a book more concentrating on its core concepts. If you want a good book on Extreme Programming, you will definitively have to look elsewhere.

Discuss book in the Saloon — More info at Amazon.com


Extreme Programming Refactored: The Case Against XP
by Matt Stephens, Doug Rosenberg


Apress
1 edition
August 2003
432 pages
Reviewed by Ilja Preuss, December 2003
  (2 of 10)


Trying to show the shortcomings of XP in a satirical way and proposing changes to make it less fragile is a noble goal, and this book has some points to make. Its vast majority is composed of misunderstandings and logical fallacies, though.

Many XP practices are violently misrepresented. The "thorough analysis" promised on the front cover often comes down to quoting an XP proponent out of context and making fun of it. One of the most ridiculous examples is when they quote Ron Jeffries with "'There must be food' is a core XP principle" and then hold XP responsible for the vermin problem of a company.

Another common pattern is the reference to a project which failed to implement XP followed by the conclusion that XPs demands are unrealistic. Reports of successful implementations are with a handwaving attributed to not doing XP by the book.

The style of the book is questionable, too. At times its tone is quite aggressive - ideas are called "idiotic", XP proponents are accused of intellectual dishonesty. Quotes of XPers are marked with a picture of Marx Groucho, so that you don't accidentally take them seriously. I don't think that satire is good in making someone understand a new concept; satire based on an already distorted view feels painfully pointless.

If you have already made up your mind about XP and enjoy making fun of it, you might like this book. I can't recommend it to anyone interested in a serious criticism, though.

Discuss book in the Saloon — More info at Amazon.com


Pragmatic Version Control Using CVS
by David Thomas Andrew Hunt


Facilitator's Guide to Participatory Decision-Making
by Sam Kaner


New Society Publishers
1 edition
April 1996
272 pages
Reviewed by Ilja Preuss, January 2004
  (10 of 10)


If you ever attended a meeting about a tough topic, you probably know what an unpleasant experience it can be; doubly so when the goal of the meeting is to come to a decision.

This book discusses tools and techniques to help a group to find a solution to the problem at hand every attendee can subscribe to.

The first two chapters explain group dynamics of decision finding meetings and discuss the values of participation. Their pages can easily be used as slides in a presentation.

After an introduction to the role of the facilitator, there are 15 chapters addressing topics ranging from designing realistic agendas and chartwriting techniques to dealing with difficult dynamics.

But the value of the book does not come from the individual techniques, but from how they form a coherent whole - from the underlying theme of fostering diverse thinking and mutual understanding.

It will probably take me years and several rereads to grasp all the wisdom and apply it in practice. I can only recommend everyone interested in making meetings more effective follows suite.

Discuss book in the Saloon — More info at Amazon.com


Agile Database Techniques: Effective Strategies for the Agile Software Developer
by Scott Ambler


Wiley
1 edition
October 2003
480 pages
Reviewed by Lasse Koskela, January 2004
  (7 of 10)


Agile Database Techniques is a brilliant book. Already after reading the first chapter I felt like I had been run over by a truck, wondering why I haven't paid more attention to these issues before. Yet, it also has its flaws which I will go into further down.

Ambler starts laying out the groundwork for the second part of the book by introducing his Agile Data method, UML and data modeling. He also gives a very useful jump-start tutorial on data and class normalization and discusses the infamous object-relational impedance mismatch. Worth noting is that in each chapter (throughout the book) Ambler makes sure that the reader understands how the subjects relate to the role of an agile DBA and what should he be looking out for. The subjects in part one were introduced so well that I more than once thought, "I've never seen such a well-balanced and informative tutorial."

The second part of the book is dedicated for discussing how evolutionary software development is the reality and how techniques such as Agile Model-Driven Development and TDD can assist in surviving in this climate. The chapter on database refactoring is intriguing and the more comprehensive list of database refactorings, found in the appendices, is something I'll definitely Xerox and keep with me in my traveling tool bag. The second part also covers database encapsulation strategies and approaches to mapping objects to relational databases which, again, is a delightfully comprehensive tutorial, as well as touching on the topic of performance tuning.

The third part is a seemingly random collection of subjects such as finding objects in a relational database, referential integrity, concurrency, security, reports and XML with databases. The text is again of high quality and provides an entertaining walk through the woods, but I feel that these chapters had very little to contribute to the subject of the book. This disconnect is made even more clear when Ambler finishes with a 10-page guide on how to become agile and to introduce agility into the organization.

After reading the book, I feel confused. On the other hand, this book is full of little islands of useful insights that I wouldn't think twice recommending for others to read. On the other, the book as a whole is very fragmented and pretty far from what the book's title might suggest. If you pick up the book with an open mind like I did, you'll gain plenty. Otherwise, you'll probably be disappointed to find out that one half of the book probably talks about something you weren't expecting based on the title. After a long struggle, I'm giving this book "only" seven horseshoes despite that it contains some very, very high quality material.

Discuss book in the Saloon — More info at Amazon.com


Software Development for Small Teams: A RUP-Centric Approach
by Gary Pollice, Liz Augustine, Chris Lowe, Jas Madhur


Addison-Wesley Professional
1 edition
December 2003
304 pages
Reviewed by Lasse Koskela, January 2004
  (7 of 10)


This is what I call a "nightstand book". It's very readable and won't overload your gray brain cells while still stimulating you to analyze your conceptions of the real world you're faced with at work. It's a story about a voluntary software project implemented by the authors on their free time and provides a nice overview of how RUP can be applied to a small project, mixed in with certain ingredients from agile processes such as XP.

The focus of the book is to document what decisions and obstacles the four-member team encountered during the 6 months they spent on the project. The story is very entertaining and I read the book (almost) cover to cover in just 4 days. I found the tips and guidelines splattered around the book to be mostly common sense, but I did make some notes regarding what to do at work a.s.a.p. That's always a sign that the book you're reading was worth reading.

One thing that annoyed me though was the constant praise of the Rational product line knowing that all four authors worked for Rational Software during the project. Also, there were a couple of chapters dedicated for showing little islands of the implementation (code snippets etc.) of which value I frankly didn't see.

In summary, I'd classify this book as a good buy. Not great, but good. No big revelations, but a nice bunch of thought-provokers here and there.

Discuss book in the Saloon — More info at Amazon.com


Software by Numbers
by Mark Denne, Jane Cleland-Huang


Prentice Hall PTR
1 edition
October 2003
208 pages
Reviewed by Matthew Phillips, January 2004
  (10 of 10)


Finally, a book that applies a solid financial methodology to iterative software development. The basis of this book is the Incremental Funding Methodology. IFM is not a new software development methodology. It is a funding methodology that can be applied to your chosen development methodology to maximize ROI through the release of minimum marketable features.

This book starts with the assumption that you are using a methodology such as RUP or XP and builds a case for incremental funding. It moves on to teach you the tools to maximize the ROI on your project. Methods for moving up the self-funding date are also in this book. The book ends with 3 application chapters. The first is on how to apply IFM to RUP. The 2nd is on applying IFM to an agile software methodology. The final chapter is a case study on using IFM. The glossary is excellent and there is a quick reference guide to IFM as well.

Before reading this book, I was never completely convince that an agile methodology was the way to go. This is the book I was looking for to complement agile development.

Discuss book in the Saloon — More info at Amazon.com


Prentice Hall PTR
1 edition
October 2003
208 pages
Reviewed by Lasse Koskela, June 2004
  (9 of 10)


"Software by Numbers" is yet another book I would like any manager involved in my working life to read and re-read.

The authors describe an Incremental Funding Method (IFM) for scheduling incremental development of software which optimizes the Return on Investment (ROI) by having the requirements engineered into Minimum Marketable Features (MMF) with concrete, monetary value.

The book is very light (less than 200 pages) but packed with interesting material. I read most of the book during a flight from Finland to Germany and finished the book on my way home. Despite the minimal page count, the authors manage to explain why their method is desperately needed and how it fits to existing software processes such as RUP and XP. They also describe the business case for incremental architecture and different strategies for sequencing MMFs and Architectural Elements (AE) for maximum ROI over the project's lifetime.

The only reason for not giving a full 10 for this book is that I would've needed some more baby-steps support for the actual calculations (sequence-adjusted net present values etc.). I'm sure others will be hoping to see some more real world examples of feature deconstruction and sequencing as well. On the other hand, I really appreciate the fact that the authors made the effort of putting up a spreadsheet online for supporting their method.

Overall, an excellent book. Highly recommended.

Discuss book in the Saloon — More info at Amazon.com


Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results
by David J. Anderson


Prentice Hall PTR
1 edition
September 2003
336 pages
Reviewed by Lasse Koskela, February 2004
  (8 of 10)


Agile Management for Software Engineering is targeted for managers and executives working in the software industry. Its focus is on introducing a technique called Throughput Accounting for measuring and tracking software projects. The author basically shows how traditional cost accounting based methods lead to suboptimal business results and how to correct that situation by applying principles of Lean Production and the Theory of Constraints.

The author covers different aspects of management in the software industry one by one--including project management, project planning, production metrics, staffing, resource planning, and product management--explaining how the concepts of Throughput Accounting fit into the picture.

The latter half of the book is dedicated to showing how the theory presented can be applied to a number of agile software processes, namely Feature Driven Development, Extreme Programming, and Scrum.

The first part of the book is a bit difficult to follow due to slightly repetitive text and never-ending acronyms. I wouldn't count this as a defect, however, as the subject of introducing financial measures inevitably requires a certain amount of equations in between beautiful words. Luckily, the latter part, where these measures are applied, flows much better. What I see missing in this book is more concrete examples beyond the arguably theoretical discussion about real-world application. I also noticed that I was constantly waiting for the author to connect the dots and bind the theories presented in a more or less waterfall context into modern, iterative and incremental processes.

All in all, I find Agile Management for Software Engineering to be a book with a solid message: how to better manage a software business. Considering the state of practice in the industry, I'd say this is a must buy for any manager or executive.

Discuss book in the Saloon — More info at Amazon.com


Extreme Programming Adventures in C#
by Ron Jeffries


Microsoft Press
1 edition
March 2004
560 pages
Reviewed by Ernest Friedman-Hill, May 2004
  (9 of 10)


It's a pleasure to watch a master at work. It's human nature to enjoy identifying with experts, whether you're picking up tips or just validating your own experiences. If you're a golfer, you probably love to watch golf on TV. If you (as I do) build furniture, you'd love Fine Woodworking magazine. And if you're a developer doing Extreme Programming, you'll love this book.

In "Extreme Programming Adventures in C#", XP guru Ron Jeffries lets you pull up a chair next to him as he takes a small programming project from concept to delivery. Along the way, Ron learns the C# language, pair programs with several partners, makes mistakes, hurts his arm, and writes clean, well-factored code. In short, he acts like a real programmer with a real life that you'll be able to identify with easily. You'll see Test-Driven Design in practice, and watch as a complete customer-test tool is developed as an organic part of the project.

The most amazing thing about this book is that Ron checks his ego at the door. He doesn't try to hide his mistakes, but instead celebrates them as learning opportunities. The review at the end of each chapter examines what went wrong and what went right. This book validated many of my own experiences in using the XP methodology. If you're interested in how XP and TDD work in the real world, buy it now.

Discuss book in the Saloon — More info at Amazon.com


User Stories Applied: For Agile Software Development
by Mike Cohn


Addison-Wesley Professional
1 edition
March 2004
304 pages
Reviewed by Ernest Friedman-Hill, September 2004
  (8 of 10)


Many books have been written about requirements gathering as a discipline, and many more about techniques for doing it. To my knowledge, this is the first book dedicated to "user stories", the form of software requirements capture used in Extreme Programming (XP). At first blush, you might think that there isn't enough to the topic to warrant a book, because the beauty of user stories is their simplicity. But Mike Cohn shows that there is indeed plenty of potential material -- and useful material at that. My only complaint about this book is that the proofreading could have been more careful; there are too many "stray words" left over from editing.

In "User Stories Applied", Cohn explains what stories are, what makes a good story, and how stories are written. He uses copious examples throughout, and I enjoyed the self-test questions at the end of each chapter. My favorite part of the book comes near the end, when he works through how the initial set of stories would be developed using a nontrivial example (an eCommerce web site.)

Although user stories are traditionally associated with XP, they can be used without it, and Cohn shows how stories fit in with other agile methodologies (Scrum in particular.) If you need to capture requirements for agile projects, or if you're sick of writing ISO standard requirements documents and think there must be a better way, then this book is for you.

Discuss book in the Saloon — More info at Amazon.com


Addison-Wesley Professional
1 edition
March 2004
304 pages
Reviewed by Lasse Koskela, July 2004
  (10 of 10)


"User Stories Applied" was a book that long stood on my Amazon wish list with a "must have" rating. I'm not disappointed. I loved the book. Now let me explain why.

First of all, running the planning aspect of an XP project, for example, well is essential for reaping the benefits of agile software development. Yet, relatively little has been written to guide practitioners in doing that. I, for example, have made all the mistakes Cohn enumerates in the chapters for guiding the user towards writing *good* user stories (usually more than once). These sorts of things make you realize you shouldn't put the book on the shelf to gather dust! The author doesn't cover just writing good user stories, but the whole spectrum from putting together the customer team to estimating stories to discussing the stories to writing acceptance tests for the stories.

Second, it's a pleasure to read. The structure makes sense, each chapter is followed by a useful summary, and there's a set of questions -- along with answers -- to make sure you understood what the chapter talked about. Usually these kinds of Q&A sections simply force me to skip them over. The questions in this book did not. I read each and every one of them and I think there was only one set of questions that I did "pass" with the first try, usually having forgotten some rather important aspects to consider (concrete evidence of their usefulness to me). To finish, the last part of the book, an example project, nicely ties together all the threads.

As usual, there were some things I experienced not so well. I believe the chapter on applying user stories with Scrum could've been left out without breaking the plot. Also, I think a typical user wouldn't have been bothered about dropping the appendix introducing Extreme Programming.

In summary, this is the book to get if you're involved with user stories. I had to pause reading every few pages to scribble down some specific tips. I'm confident that you will too.

Discuss book in the Saloon — More info at Amazon.com


Agile Project Management: Creating Innovative Products
by Jim Highsmith


Addison-Wesley Professional
1 edition
April 2004
312 pages
Reviewed by Lasse Koskela, July 2004
  (10 of 10)


Jim Highsmith has managed to write quite a piece of work. "Agile Project Management" contains a valuable catalog of simple practices that combine to support Highsmith's vision of an agile project's phases: Envision, Speculate, Explore, Adapt, and Close. Furthermore, as the book's title suggests, these practices can readily be applied to practically any agile project, be it software, electronics, or airplanes.

The book follows the "APM Framework" through each of the phases, illustrating what the phase is all about and enumerates through the practices in the APM toolbox. Also, the beginning of each chapter carries a nice little conversation between two fictional characters which asks the tough questions just when you are about to ask them and gives you a rough answer to guide your thoughts to the right direction -- with the chapters themselves discussing the topic in detail.

This is one of those must-read titles for someone who's serious about improving on his craft.

I have to confess that Highsmith's award-winning "Adaptive Software Development" has been waiting on my bookshelf untouched for a long time. Having read APM -- and thoroughly enjoyed every aspect of it -- I can't help but pick it up soon.

Discuss book in the Saloon — More info at Amazon.com


Pragmatic Project Automation
by Mike Clark


The Pragmatic Programmers
1 edition
August 2004
176 pages
Reviewed by Lasse Koskela, September 2004
  (10 of 10)


If you're involved in any type of commercial Java projects, you owe yourself to pick up this book. I'm not kidding.

"Pragmatic Project Automation", the third book in the Pragmatic Programmers' Starter Kit series, authored by Mike Clark, is an invaluable asset for automating the grunt work of your Java development projects and raising your standards regarding quality, lead times in bug fixing, and eventually, the motivation of your whole team.

I read the book over a weekend in two sittings and enjoyed every minute of it. Mike has put together a series of high quality tutorials for setting up a repeatable build process using Ant, scheduling the build process using shell scripts, cron/at, and eventually CruiseControl, while keeping in the spirit of pragmatic thinking. He then continues by showing how to automate your release process and software deployment -- with both simple shell scripts and an open source graphical installer tool. To finish, he talks about different techniques for monitoring your software for errors.

I honestly couldn't find anything to complain about this book -- except that I wouldn't have minded reading another 150 pages of it.

Discuss book in the Saloon — More info at Amazon.com


The Pragmatic Programmers
1 edition
August 2004
176 pages
Reviewed by Ernest Friedman-Hill, August 2004
  (9 of 10)


This little book could double your productivity by showing you how to make computers actually help you do your job. Do you spend too much time chasing configuration bugs, following checklists, and performing repetitive tasks that take time away from your coding and design duties? Then "Pragmatic Project Automation" is for you.

This isn't the kind of "software process" book that tries to sell you on following a methodology. There's no preaching, and there are no outlandish claims of productivity increases. Instead of selling snake oil, Mike Clark just wants to explain, in a clear, effective way, how to use open-source tools to automate your builds, release process, and application monitoring. Java tools like Ant, CruiseControl, and JUnit are the centerpieces of this book, but shell scripts and batch files also make cameo appearances.

There's even a section on assembling novel monitoring devices. Admit it -- wouldn't it be cool to have red and green Lava Lamps that light up according to the status of your project build?

The beginning programmer might wonder what all the fuss is about, but anyone tasked with delivering software on a schedule will appreciate the many ways in which this book will help them.

Discuss book in the Saloon — More info at Amazon.com


The Pragmatic Starter Kit
by David Thomas, Andrew Hunt


Hiring the Best Knowledge Workers, Techies and Nerds
by Johanna Rothman


Dorset House Publishing Company, Incorporated
1 edition
September 2004
352 pages
Reviewed by Valentin Crettaz, October 2004
  (10 of 10)


This book is the B-52 of hiring management. Fully loaded with tons of great tips and piloted by the very talented Johanna Rothman, it will parachute numerous boxes packed with smart and effective tips on the head of hiring officers struggling on the battlefield. The well organized flight plan will take you through stopovers dealing with recurrent hiring management topics, such as defining hiring strategies; writing job descriptions; sourcing, selecting and interviewing candidates; creating fool-proof phone-screens; checking references; hiring technical managers and many more. During the trip, Johanna will hand out numerous check lists that will help you organize your work more efficiently and prevent you from going too deep into the mud. What's more, she will share the most common dos and don'ts that you can follow when creating your own job descriptions and offers. She will also embellish your journey with invaluable and true war stories that she actually experienced during the past twenty years. If you still manage to be hungry after this reading, you will find plenty of excellent references to other books whose content nicely complements Johanna's masterpiece.

This 300-pages book enclosing a mountain of priceless information is definitely one of the best books on hiring management available on the market today. Whether you are a hiring manager in need of some guidance/improvements or a job seeker willing to put together outstanding job applications to maximize your chances, don't wait any further, get this book NOW!

Discuss book in the Saloon — More info at Amazon.com


Practical Subversion
by Garrett Rooney


Apress
1 edition
November 2004
336 pages
Reviewed by Lasse Koskela, November 2004
  (8 of 10)


"Practical Subversion" is just that -- a no-fluff-just-stuff guide to using Subversion. It takes the reader from creating his first repository, importing his first project, checking out a working copy, and so on, to administering the repository and integrating with it using a number of programming languages -- briefly but still.

Having said that, and even though it certainly covers a lot of ground, "Practical Subversion" is not a complete reference. The author covers all subjects in a pragmatic manner, covering the common needs well and giving enough hints to help the reader in finding answers for the edge cases.

What I especially like about product-oriented books like this one is when the authors sneak in advice on best practices in using the product, the "tips and tricks" type of gems that make you go "wow" in a bathtub. In addition to learning how to take a backup, I now know how to add auto-completion for Subversion commands in Bash!

Discuss book in the Saloon — More info at Amazon.com


Agile Software Development in the Large: Diving Into the Deep
by Jutta Eckstein


Dorset House Publishing Company, Incorporated
1 edition
June 2004
234 pages
Reviewed by Lasse Koskela, December 2004
  (8 of 10)


Most other titles on Agile Software Development repeat the mantra about lightweight processes and how they are only applicable for small teams of a dozen or so. This book is different. It sets out to offer the advice of someone who has been running software projects with over hundred people using an agile process -- to help others succeed in the same.

While there aren't any hard numbers and the like, a formula to make a silver bullet, there's plenty of sound advice starting from structures to help scale up an agile process, the challenges one will encounter while scaling, and the peopleware issues evident in large, often distributed projects as well as large companies in general, with all the associated bureaucracy and policies. The discussions about building teams around features versus components, for example, and the division into domain teams and technical service teams are useful reading for someone facing such decisions.

Also, this book does not expect you to know the slang of agile software development. It's written so that a manager familiar with software development -- but not necessarily agile software development -- has no problem understanding what the author is trying to pass on.

What's missing from this book -- something one might wish to get support for, facing a larger than usual agile project -- is the deeper coverage of techniques to facilitate things like emergent architecture across a distributed development team. The project report from a 170-member software project was not quite as detailed as I would've hoped. Detailed case studies are something I am personally very interested in reading.

In summary, while the advice in this book is relatively abstract, and you might think it doesn't have that much to offer if you are already familiar with Agile Software Development in general, I would certainly not dare to risk a large project by NOT reading this book.

Discuss book in the Saloon — More info at Amazon.com


Extreme Programming Explained
by Kent Beck, Cynthia Andres


Addison-Wesley Professional
second edition
November 2004
224 pages
Reviewed by Lasse Koskela, December 2004
  (10 of 10)


The release 1st edition of this book is still considered by many to be the kick start for the growing adoption of a software development process called Extreme Programming. After 5 years, the 2nd edition faces a much different world but also with much different content and approach. The world has learned much and so has the author. I'm glad to see that this 2nd edition reflects that development.

Beck has revised his thinking throughout the book. Some obvious examples include his current preference towards using ideal time over abstract time units in estimating, the fifth value among the initial four, the new set of principles, and the rehash of the practices.

Extreme Programming Explained is not a detailed how-to for adopting the process it describes. Actually, it doesn't really describe a process at all. What it does describe is a system of values and principles and a set of practices to support these. Even though Beck does give each practice (divided into primary and corollary practices in the 2nd edition) their share of explanation, the focus is still strongly on the "what" and "why" instead of the "how".

As someone who has read a dozen books on the topic already, I was delighted to find almost every page to provide something intriguing that either created or challenged my own thoughts. Especially the latter half of the book, dealing with topics such as TOC, scaling, Taylorism, the Toyota Production System, and hot potato itself, offshoring, offered a lot to think about.

This is what a 2nd edition should be like, every single chapter reflecting new insight gathered over the years.

Discuss book in the Saloon — More info at Amazon.com


Subversion in Action
by Jeffrey Machols


Manning Publications
1 edition
December 2004
352 pages
Reviewed by Lasse Koskela, February 2005
  (10 of 10)


Version control and configuration management is a topic that most software developers know just enough to get by. Branching, tagging releases, merging changes, etc. are all things people rarely feel comfortable with doing, largely because every version control system has different ways of doing these tasks. If you're one of those people (like me) and you happen to be using Subversion, this book should be high up on your shopping list.

Jeffrey Machols does a great job in explaining the fundamental concepts of version control and has injected plenty of tips for how to accommodate configuration management in a software development process. That's something many tool-oriented books have lacked, in my experience. In addition to that, Machols gives the most thorough walkthrough of Subversion tools and features I've seen. File permissions, repository-wide revisions, client commands, administrating the repository, taking backups, setting up authentication, configuring the standalone server process as well as the Apache module, wiring up commit hooks. There's very few things missing from this book and the topics that are covered are covered well!

Discuss book in the Saloon — More info at Amazon.com


Managing Agile Projects
by Kevin Aguanno (Editor)



1 edition

pages
Reviewed by Lasse Koskela, March 2005
  (9 of 10)


When Kevin asked me if I'd like to review "Managing Agile Projects", I was initially suspicious of how the title would hold up against other titles in this very popular genre. After reading it, I have to say it does so very well.

"Managing Agile Projects" is not a book about a methodology. Instead, it looks at agile project management as a whole and offers insights to various aspects of it through the words of a number of well-known authors (all of whom have donated any author royalties from this book to charity!). While the book has been stitched together from a huge cast of authors, the whole really is a well balanced whole although some chapters do stick out from the rest, being rather academic for my taste.

The book really is a one-stop shop for describing agile software development to a project manager. It doesn't just run through the usual stuff found in pretty much any book on agile software development but also discusses hot potatoes like fixed-price contracts and documentation. I've read a whole bunch of books on agile software development and I still found plenty of material in this book that made my eyes gleam of new insight.

I'm rating this one at no less than 9 horseshoes!

Discuss book in the Saloon — More info at Amazon.com


Ship It! A Practical Guide to Successful Software Projects
by Jared Richardson, William Gwaltney Jr


Pragmatic Bookshelf
1 edition
June 2005
200 pages
Reviewed by Ernest Friedman-Hill, June 2005
  (9 of 10)


Ship It! is a guide to running successful software projects and a life preserver for failing projects. If you've ever worked on a troubled project, you know what it feels like. The frustration. The sense of impending doom. The urge to polish your resume. We've all been there. So have Richardson and Gwaltney -- and they're offering to leverage their considerable experience to help save you and your project.

There's not much material that's truly new between these covers, but the presentation and point of view is refreshing. It's a rare book that speaks convincingly to both developers and managers, but this one does. The book describes many of the practices of agile development -- continuous integration, automated testing, lightweight planning -- and combines them into a simple, powerful approach to building software called "Tracer Bullet Development." But the book doesn't assume you're going to do everything the authors suggest: they expect you to try just one thing as a time.

My favorite part of the book is compendium of one-page essays on common problems software projects have, and how to apply the principles and practices from the book to solve them. Unlike some other rather strained "antipatterns" catalogs that I've read, this section feels very practical and usable.

If your shop has trouble shipping quality software on time -- and let's face it, most do -- then this book is for you. If you're a manager, I'd say that doubly so.

Discuss book in the Saloon — More info at Amazon.com


Just Enough Requirements Management
by Alan M. Davis


Dorset House Publishing Company, Incorporated
1 edition
May 2005
240 pages
Reviewed by Valentin Crettaz, June 2005
  (10 of 10)


The primary goal of an information system is to provide a solution to a business problem. The development of such systems usually involves people from several sectors, such as the IT sector as the solution provider and the business sectors for which the software solution is being devised. Since the needs are usually expressed by the customer, it becomes immediately clear that one of the most critical phases of the software development lifecycle is the requirements phase. Failing to efficiently manage that phase can have disastrous consequences as the implemented solution might not correctly fulfill the customer's needs.

Alan M. Davis, an award-winning professor, author and entrepreneur, contributes very useful requirements management techniques for effectively performing and managing requirements elicitation, triage, specification and change. Davis argues that one of the main points to focus on when managing requirements is to allow computer-savvy IT actors and computer agnostic business actors to understand each other by using a language that can be understood by both parties and that can be easily adapted to the relative complexity of the problem and to the available resources.

If you repeatedly find yourself having troubles managing requirements for your information system development projects, or if you have a hard time communicating with your marketing or business departments or even with your customers, this book will undoubtedly make your day. If successfully applied, Davis' techniques will definitely have a highly positive impact on both your budgets and the quality of the delivered solutions.

Discuss book in the Saloon — More info at Amazon.com


Subversion Version Control: Using the Subversion Version Control System in Development Projects
by William Nagel


Prentice Hall PTR
1 edition
May 2005
368 pages
Reviewed by Ernest Friedman-Hill, July 2005
  (8 of 10)


This is a straightforward book on a straightforward topic. Subversion is an open-source version control (VC) system conceived as a replacement for CVS. While improving on CVS in a number of ways, it nonetheless feels comfortable and familiar to CVS users. Furthermore, because it avoids some of CVS's worst "gotchas", it's easier for VC novices to learn. Nagel writes this book for both of these audiences in a plain, easy to read style.

As expected, the book covers the basic concepts of VC software, offers comparisons between Subversion and several other VC systems, and discusses Subversion's command set in detail. But the most valuable part of the book are the numerous discussions throughout of practical approaches to working in a VC environment and to managing a Subversion repository. There's some great material on how VC practices and development methodologies affect each other, and there are some detailed case studies of individual companies and how they use Subversion -- right down to the details of the client software, repository layout, and automation scripts that they use. There's always a danger that a book documenting a specific software package will simply duplicate material that's already in the manual; that really doesn't happen here.

Prospective Subversion users -- whether they're coming from a CVS or SourceSafe environment, or if they're new to VC all together -- won't go wrong with this book.

Discuss book in the Saloon — More info at Amazon.com


Five Core Metrics
by Lawrence H. Putnam, Ware Myers


Dorset House Publishing Company, Incorporated
1 edition
May 2003
328 pages
Reviewed by Valentin Crettaz, August 2005
  (9 of 10)


One of the most notable differences between software engineering and other more mature engineering disciplines lies in the fact that actors on the former field recurrently have a very hard time estimating with high certainty and maximal accuracy how long it will take to complete their projects on time and budget. Without proper tooling, this failure to adequately calculate the duration of a project is not only unavoidable but it usually has dramatic effects on the project outcome.

Building on their combined 60+ years of experience on the field, Putnam and Myers tackle this very sensible issue by showing that there is absolutely no magic behind this estimation process. By gathering basic facts from more than 6,300 past projects, the authors have managed to factor out five key metrics, such as, development time, work effort, number of functionalities, defect rate and process productivity, which they then correlate in a couple of mathematical equations that uniquely define any kind of software development project. These equations provide a unique and powerful scientific means for correctly gauging the different metrics at hand and for successfully fine-tuning the software management process.

If you want to stop wondering whether you'll deliver your project five or six month too late and to start capitalizing on the knowledge from past projects, let this book show you the path. Be advised that this is not an academic book as the whole content is built around concrete data gathered by seasoned professionals from real-world settings.

Discuss book in the Saloon — More info at Amazon.com


Software Project Secrets: Why Software Projects Fail
by George Stepanek


Apress
1 edition
September 2005
192 pages
Reviewed by Valentin Crettaz, September 2005
  (9 of 10)


How many times have you asked yourself what went wrong in your past software projects? How many times have you successfully managed to identify the key factors that made these projects derail? Have you noticed anything wrong at all? Have you asked yourself why software development projects are so difficult to manage and so hard to bring to successful completion?

To answer these questions, Stepanek first enumerates twelve fundamental facts (software is complex, change is inevitable, etc.) that make software development look so different than any other engineering fields. Secondly, the author lists ten wrong assumptions (scope can be completely defined, all developers are equivalent, etc.) that are often made by software project managers. Building on this, Stepanek analyzes three modern project management methodologies (Crystal, XP and RUP) and shows how they can be used for solving some of the identified issues as well as how they fail to address some of the problems. To cope with this, Stepanek delivers seven techniques to help you finish your projects on time and on budget. Finally, the author introduces a case study (made up of real facts) that demonstrates how things can usually go bad and how to make them go well.

If you have already found yourself helpless when answering any of the above questions, this book will definitely provide you with clear and definite answers as well as a couple useful techniques. Armed with that knowledge and your past experience, you will become a successful and highly respected project manager.

Discuss book in the Saloon — More info at Amazon.com


Unit Test Frameworks
by Paul Hamill


O'Reilly
unknown edition
October 2004
304 pages
Reviewed by Lasse Koskela, September 2005
  (7 of 10)


I had used JUnit for several years before picking up this book and I like to think that I know the tool pretty well. So why did I decide to read this book? I read this book because I thought that might help me venture a bit outside my familiar JUnit turf and into doing test-first programming with languages other than Java. The short version? A very nice introduction to all the included xUnit ports. The long version? Read on.

The first four chapters are general introduction to the topic of unit testing (and to some degree, test-driven development). I was prepared to do a quick scan through them all but ended up reading chapters 3 (xUnit architecture) and 4 (writing unit tests) almost word to word -- the topic was mostly familiar but the authors solid writing kind of kept me going.

The first two chapters didn't pique my interest that much, perhaps because I had already seen people develop a unit test framework from scratch as an introduction to the domain.

The real meat of the book that I was looking forward to was in chapters 7 through 9, the introductions to CppUnit, NUnit, PyUnit -- which were mostly new to me although I had done very little fooling around with them before. I wasn't disappointed. The author managed to put together a pretty good set of tutorials for these frameworks. Obviously the same information is available online but I still prefer reading a treekiller rather than a printout of a web page.

The not so bright spots in the book, in my opinion, were the chapters on unit testing a Swing GUI and on XMLUnit. Not that they were in anyway badly written. I just felt like they didn't belong. I would've personally swapped in a couple of additional xUnit ports instead (Ruby and PHP, for example).

This is definitely not a book you'll carry with you from project to project. There's approximately 100 pages of substance split among half a dozen topics so none of them gets covered in detail. The rest, almost 100 pages of the book is what I'd classify as "nice to have" -- I don't mind having that material in the book but I also wouldn't have minded if they'd left them out.

To summarize, if you'd like to get an idea of how the unit testing frameworks on different platforms/languages differ and what they have in common, this is as good an introduction to them as any and well written in all dimensions. However, you might be disappointed if you're looking for a more long-lasting companion.

Discuss book in the Saloon — More info at Amazon.com


Fit for Developing Software
by Rick Mugridge, Ward Cunningham


Prentice Hall PTR
1 edition
July 2005
384 pages
Reviewed by Lasse Koskela, October 2005
  (9 of 10)


Even though Ward and Rick's book on Fit is the first book available on Fit -- perhaps the most popular acceptance testing tool among the whole agile community -- and one might be tempted to think it's selling well because of that alone, I'm saying this book is a hit on its own merits.

I read the beta drafts of the book like many others at the time and was instantly gratified as I read through the table of contents. Ward and Rick didn't make the mistake of writing a pure tool book. They wrote a book that focuses not just on the tool itself but also on using the tool. I ordered a hardcopy as soon as it was released. I devoured it, loved it, and am still using it as a reference today on projects using Fit.

The first part is all about expressing tests with Fit's tables in a way that communicates well. The built-in fixtures are introduced one by one from the perspective of a test engineer wanting to test different kinds of aspects of a system. The first time the authors actually show how to run the tests is in chapter 7. This approached proved to be an excellent choice, as far as I'm concerned. The focus really stays on creating tests without digressions into technical implementation.

After a brief tour through FitNesse, a display of Fitlibrary's power and flexibility, and some miscellaneous topics, Part 2 takes the reader to another level -- the process of turning requirements into Fit tables and the strenghts and benefits of using a tool like Fit in developing software. This is delivered using an imaginary software project as a vehicle in illustrating the communication between people while they're honing their acceptance tests.

Part 3 turns the table and puts the developer hat on. In an action-packed 70 pages, the authors show how to write the Java code backing up all those different kinds of fixture tables we saw in Parts 1 and 2. The discussion is concise and to the point, covering the fixtures rather well. Having said that, I was left with some open questions regarding extending the built-in (and Fitlibrary) fixtures, mostly regarding Fit's internal API. That, however, has been a problem with me and Fit since day one so it's probably just my wiring that's incompatible. Besides, there's more on the internals in the last part of the book.

Part 4 is two-fold. First, we see how the fixtures created in Part 2 look like in Java. There's not too much explanation involved but I didn't feel like that was an issue. The rest of Part 4 is a mixture of topics such as mocking certain aspects of a system, making the system's architecture more testing-friendly, and such. I have to say I was a bit disappointed by the mocking section, having hoped for a more elaborate example rather than sticking to faking system time.

Part 5 starts with a very brief description of Fit's internal API (introducing concepts of Parse object, "more", and so forth, if you've already taken a peek at Fit's source code) and how to develop custom fixtures. Personally, I would've liked to have a lot more material on this exact topic but even the brief overview helped solidify some of the things I had picked up here and there while reading the Fit source code, trying to figure out how to write custom fixtures.

Trying to summarize all that, I'd claim that "Fit for Developing Software" is a must read for anyone involved in using Fit. It's a tremendous resource, especially considering how little documentation on Fit is available online. The book does have its deficiencies as well, though. Whereas the (arguably most important) aspect of creating tests is covered extremely well, the poor fixture developer still has to figure out a lot of stuff out on her own as the custom development topic is not covered as thoroughly. Still, a great book and a warm recommendation from me.

Discuss book in the Saloon — More info at Amazon.com


Software Architect Bootcamp
by Raphael Malveau, Thomas J. Mowbray


Prentice Hall PTR
second edition
December 2003
368 pages
Reviewed by Mark Spritzler, November 2005
  (10 of 10)


Do you know what an architect does? In the programming world, this title Architect is defined in many different ways, some that are too low level that they are really just designers, and not architects, in the traditional sense of the word. An Architect not only looks at technologies and decides which will work best for their project, but they must also define process and standards. They must understand about human behavior, build teams, and learn to learn quickly. There are many different Architectural models out there that many aren't aware of like the Zachman Framework or 4+1 Architect.

But most think an architect just draws UML collaboration diagrams.

This is the first time I have read a book on being an architect that surpassed my definitions of what an architect is. I want to be an architect and this book has taught me much more than I could have thought of.

There are a few rare breed of books that are the top of its class, this book is one of them. If you dream of becoming an Architect then you must buy this book.

Discuss book in the Saloon — More info at Amazon.com


Essential Business Process Modeling
by Michael Havey


O'Reilly
1 edition
August 2005
350 pages
Reviewed by Mark Spritzler, November 2005
  (7 of 10)


BPM, not to be confused with PBS, MPG, or MPH. There is not chance of that because you never forget your book on Business Process Modeling, not because it blows you away, but because of how many naps you take while reading it. The subject is very boring, not for your everyday programmer.

It takes a different kind of developer to love BPM, and to take the time to learn BPEL, WSFL, XLANG, or YAWL, and to do research into Petri Nets and Pi-Calculus.

But there is a need, and to be honest, even though I was bored, I know that this was a very good book explaining the technologies that are out there, the BPM Design Patterns, The "languages" and some examples using them, and a good amount of diagrams showing "workflow".

So, if you are one of the lucky few who either love BPM or just have a job at Filenet, then this is a great book for you to pick up.

Discuss book in the Saloon — More info at Amazon.com


Behind Closed Doors: Secrets of Great Management
by Johanna Rothman, Esther Derby


Pragmatic Bookshelf
1 edition
September 2005
176 pages
Reviewed by Lasse Koskela, November 2005
  (10 of 10)


"Behind Closed Doors: Secrets of Great Management" is a small book with a remarkably big punch. In the book, the authors describe how a manager can help her team achieve great things by doing the little things well.

The book follows the manager, Sam, of an imaginary IT department in his day to day actions with which he helps his direct reports overcome -- and sometimes learn about -- issues they're facing in their teams and the organization. These day-to-day actions are a mixture of techniques for handling difficult conversations, facilitating effective meetings, coaching your coworkers, and generally working with and for the people you are managing.

I thoroughly enjoyed reading the book and, even though I'm currently working as a consultant, have already been able to apply some of the techniques at work. For an acting manager, I'd say this book is a must read. Now if only it'd fit in a back pocket...

Discuss book in the Saloon — More info at Amazon.com


Service-Oriented Architecture Compass : Business Value, Planning and Enterprise Roadmap
by Norbert Bieberstien, Sanjoy Bose, Marc Fiammante, Keith Jones, Rawn Shah


IBM Press
1 edition
November 2005
272 pages
Reviewed by Simon Brown, February 2006
  (8 of 10)


This book starts where you'd expect, by defining SOA, but does it a way that places SOA firmly in the context of both business and technology, setting the scene for the rest of the book. If you're looking for an in-depth technical overview of SOA and a guide showing you how to build services in a specific technology, this book isn't for you.

What this book does do is present SOA from many different perspectives, the first of which is all about the business value of SOA and how it facilitates agility within an enterprise. It also reinforces the fact that, particularly in an SOA world, IT really does need to work as closely with the business as possible, taking their lead to ensure that IT can change with the business.

Following on from this is a look at some of the architectural characteristics of SOA, before moving on to explain how you might plan an SOA project and define people's roles. It then goes on to provide guidance of how to perform the analysis and design activities associated with building an SOA.

"Enterprise Solution Assets" is one of my favourite chapters because it offers some really good advice about formalising and documenting all of those architectural decisions that get made on a day to day basis, in a format resembling that used to document design patterns. I really like this and have subsequently adopted it my current project.

As a technical architect, I found "Determining Non-Functional Requirements" and "Security" extremely relevant to my current role, with the latter chapter providing lots of really pragmatic advice about end-to-end security within an SOA. This is great, and it's rare to find a book that says, "you might not actually need all the overhead of this ideal solution, so here's a much simpler alternative and it's okay to use it". Wrapping up the book are chapters on management and a couple of case studies, one of which resembles our own SOA.

Personally, while I found the initial chapters on business value interesting, I got most value out of the latter half of the book purely because it's just very relevant to the work that I'm doing at the moment. This book manages to distill an obvious amount of SOA experience across many projects into a few hundred pages and, at every stage, I was left with a warm feeling that many of the decisions we've made on our project match up with the best practices being recommended here.

My only criticisms are that the style is a little heavy going in places and there are (unsurprisingly) quite a lot of references to IBM products, especially in the management chapter towards the end.

Overall, if you're an architect looking at SOA now or planning to in the future, this book will help you clarify your thoughts and steer you through the brave new world of a service oriented architecture. It comes highly recommended.

Discuss book in the Saloon — More info at Amazon.com


Practices of an Agile Developer
by Venkat Subramaniam, Andy Hunt


Pragmatic Bookshelf
1 edition
April 2006
176 pages
Reviewed by Jason Menard, May 2006
  (9 of 10)


"Agility" remains a popular buzzword in the industry. Methodologies, tools, and even programming languages have had the adjective applied to them. But what does it mean to be an "agile developer"? How do we know if we're "agile"? Should I expect the ladies to saunter over at parties and say, "I couldn't help noticing that you're agile, how about coming back to my place"? To answer these questions, a good place to start would be to read "Practices of an Agile Developer".

This book, which could have easily been titled "Forty-five Habits of Highly Agile People", starts out by defining agility and what it means for something to be agile. It then proceeds to layout forty-five agile practices grouped into seven areas: Beginning Agility, Feeding Agility, Delivering What Users Want, Agile Feedback, Agile Coding, Agile Debugging, and Agile Collaboration. Your companions on your journey are a demon whose taunts remind you of how not to do things, and a guardian angel eager to steer you onto the path of righteous agility. Each practice is well motivated and adequately described. Additionally, each has sections letting you know what it should feel like if you are following the practice correctly, and how to strike a balance to keep from going overboard or not far enough when following a particular practice.

While the focus of this book is agility, the practices described really lend themselves well to all developers, even the agility impaired. Practices such as "Question until you understand" and "Write cohesive code", to name only a couple, are just plain old good advice for anyone who writes code. So even if you don't aspire to reach the summits of agility, you can look at this book as a self-help book for developers. Read it, soak in some of the good sense it offers, and be better for it.

Discuss book in the Saloon — More info at Amazon.com


IBM Rational(R) ClearCase(R), Ant, and CruiseControl : The Java(TM) Developer's Guide to Accelerating and Automating the Build Process
by Kevin A. Lee


IBM Press
1 edition
June 2006
384 pages
Reviewed by Jeanne Boyarsky, July 2006
  (8 of 10)


"IBM Rational ClearCase, Ant and CruiseControl" walks the reader through setting up automated builds. It is useful if you are doing exactly what the book discusses. In particular, you should be using all three of these technologies and want to do standard builds.

The concepts were excellent. There was a strong emphasis on understanding the terminology. For examples, configuration management and build terms were clearly discussed. The roles involved were also described.

The author introduces code as constructs/idioms rather than as syntax. He calls these "best practices." I don't think of them as best practices, but the idioms are very useful in getting started quickly. Due to this approach, the book doesn't offer much instruction on customization.

The coverage of ClearCase was very thorough. The book includes both the Base ClearCase and ClearCase UCM. Ant and CruiseControl were covered enough to automate a standard J2EE build with ClearCase.

This book will save you a lot of time in getting an automated build working if you haven't used the technologies before. It supplements the materials available on the web nicely.

Discuss book in the Saloon — More info at Amazon.com


Time Management for System Administrators
by Thomas A. Limoncelli


O'Reilly
1 edition
November 2005
226 pages
Reviewed by Jeanne Boyarsky, July 2006
  (10 of 10)


How many times do you get interrupted from your *main* task in a day? "Time Management for Techies who get Interrupted Frequently" could have been the title of this book. While the real title of this book is "Time Management for System Administrators," it is really useful for any techie who faces interruptions. And that's most of us!

In the preface, the author states: "This book is not for programmers. Beta readers told me that programmers should find this book extremely useful, but ... deserve their own book." I agree with the beta readers -- developers benefit from this book plenty. We support production applications, have emergency issues and are frequently called on to answer tech questions.

The book introduces readers to traditional time management concepts in case they are unfamiliar with them. Then the author adapts those techniques to work well when your priorities change throughout the day. There are also chapters are reducing stress, e-mail management and automation.

I found the techniques on prioritizing to be much more relevant than the typical time management book. Since the book is not teaching a technology, it was easier to read than the typical white book with an animal on the cover. The quality is high as you would expect.

I read this 200 page book in four days. It was hard to put down! How much would you pay to have a better handle on your time and responsibilities? At $25, this book pays for itself in no time!

Discuss book in the Saloon — More info at Amazon.com


Joel on Software
by Joel Spolsky


Apress
1 edition
August 2004
362 pages
Reviewed by Jeanne Boyarsky, September 2006
  (7 of 10)


Parts of "Joel on Software" get a 10 and other things about it get a 6. Since there were enough "other things" to interfere with reading, I give the book a 7. What I liked:
1) There were many good points throughout the book. In particular, the "Joel test" for how to identify whether you are on a functioning team/project.
2) The book was entertaining and easy to read.

What I didn't like:
1) There were tons of footnotes with long links, but I can't find the links on joelonsoftware.com. Does that mean I am supposed to type them in?
2) Some essays make more sense on a blog than in a book. For example, one starts with the fact that the website was down last Friday.
3) There is a lot of repetition between essays. This gives me the feeling that a bunch of blog entries were thrown together with little editing.
4) The book was copyrighted in 2004, but contained essays on the current state of .NET in 2000. This feels very dated now since .NET has since been released.
5) There are way too many plugs for Joel's company. While this is rampant on his blog, I feel that a book should have less advertising.

If you like reading Joel's blog, you will probably enjoy the book. However, if you like reading Joel's blog, you've already read much of this. My expectations exceed the actual book.

Discuss book in the Saloon — More info at Amazon.com


Project Management with the IBM Rational Unified Process: Lessons from the Trenches
by R. Dennis Gibbs


IBM Press
1 edition
August 2006
312 pages
Reviewed by Marc Peabody, September 2006
  (7 of 10)


This is a great book for anyone who loves studying project methodologies. It deepened my understanding of the Unified Process and I think that's really what the book was meant for: to enhance what you already know about the UP.

The content is less story-centric than "Lessons from the Trenches" implies, but the short stories included do a decent job of adding some color and flavor.

The book covers a far greater scope of projects than what concerns a typical project manager. Not that the extra information isn't interesting or valuable, but someone expecting a guide of how to be a project manager may be a bit overwhelmed.

The title also does not warn (though the cover mentions it) that the book heavily focuses on dealing with projects that are outsourced, even to the point of the entire first chapter to outsourcing.

If you know something about project lifecycles and the UP yet you wish to learn more, this might be a good addition to your library.

Discuss book in the Saloon — More info at Amazon.com


Innovation Games: Creating Breakthrough Products Through Collaborative Play
by Luke Hohmann


Addison-Wesley Professional
1 edition
September 2006
192 pages
Reviewed by Marc Peabody, October 2006
  (8 of 10)


Meeting customers' needs is at the heart of every business. The businesses that thrive strive to uncover the less than obvious needs while resisting the temptation to bloat their products with unnecessary features.

Guess what? You won't develop great products by simply throwing a bunch of business analysts together and telling them to change the world. A great product addresses what customers need, so talk to the customers. Problem there is the customers often don't fully understand their needs, or at least they might not understand how to prioritize their needs. A little guidance is in order.

Luke Hohmann's Innovation Games introduces 12 games to play with customers so they will make decisions that reveal "true, hidden needs and desires." The book outlines how to facilitate a large event utilizing a few of the games but I think that, for most people, will prove just as effective (and more practical) on a smaller scale.

The book segregates itself into two sections. The second part blueprints the dozen games individually and the first part talks about everything surrounding preparations. The author is very thorough in how to prepare, perhaps to help us avoid bad experiences. I would have been more interested in learning through others' mistakes than through drawn out details on preparatory drudgeries, but that's really the biggest anchor I see on the "Speed Boat".

The games are actually pretty good ideas and I hope this book will inspire more like it. If you're like me and want to have Passionate Users, I recommend engaging in Innovation Games - it will help you to better understand your customers' needs.

Discuss book in the Saloon — More info at Amazon.com


Release It!
by Michael Nygard


Pragmatic Bookshelf
1 edition
March 2007
326 pages
Reviewed by Jason Menard, June 2007
  (10 of 10)


Many of the texts on software engineering discuss following some methodology to produce an ideal design. Working developers quickly learn that the ideal is rarely reality and things happen once we release software out into the wild. Michael Nygard's "Release It!" picks up where these other books leave off.

Nygard talks about all the things that can and will go wrong in the finely crafted software we were sure was ready for production. A full two-thirds of the book is focused on capacity and stability issues including patterns and anti-patterns for both. The remainder of the book deals with general design issues as well as maintaining health and status in an operational system. "Release It!" provides many first hand accounts to illustrate his points, beginning with the Exception that grounded an airline, and these stories serve as excellent motivators. It's better to learn from the mistakes of others, and I really appreciated the detail Nygard went into addressing some of these horror stories.

The Pragmatic Programmers have a few "must read" books and "Release It!" is another one. After reading it and heeding its advice, you'll feel a bit better knowing that your software is better prepared for the rigors of production.

Discuss book in the Saloon — More info at Amazon.com


Implementing the IBM Rational Unified Process and Solutions
by Joshua Barnes



1 edition

pages
Reviewed by Jeanne Boyarsky, August 2007
  (7 of 10)


"Implementing the IBM Rational Unified Process and Solutions" is an IBM Press book. As such, it reads like a 150 page IBM whitepaper. This isn't inherently good or bad, just important to know.

The audience is managers and executives. The book emphasizes ROI, TCO and selling the process. Each chapter has a "chapter return on investment" where you would normally see an introduction. Note that I'm not in the target audience, so take this review with a grain of salt.

The book walks through what to expect at different phases of implementing RUP. It has good charts and examples -- project plan, charts with sample numbers, org charts, budgets, etc. There are examples of common mistakes and things to watch out for.

The beginning of the book mentions other process to compare RUP. They walk you through a ranking tool for weighting areas of examination. This happens again in chapter six. While the example is good, I found myself thinking "didn't we already do this?"

The book was interesting. It just felt more like a whitepaper to me than what I'm used to seeing in a book.

Discuss book in the Saloon — More info at Amazon.com


Continuous Integration
by Paul Duvall, Steve Matyas, Andrew Glover


Addison-Wesley Professional
1 edition
July 2007
336 pages
Reviewed by Jeanne Boyarsky, August 2007
  (10 of 10)


"Continuous Integration" is part of Addison-Wesley series. This series includes books like "Refactoring to Patterns". "Continuous Integration" definitely meets the standards of this series.

Each chapter describes CI related practices. There is a chapter dedicated to risks reduced by CI including anti-patterns like "It works on my machine." Each chapter ends with questions to get you thinking about CI in YOUR process. I particularly like how the authors address the "CI is good by my project is special" problem.

The authors give examples in different languages including Java, .NET and Ruby. The appendices on resources and tools are very useful. The book goes beyond CI and addresses continuous inspection and deployment. My only problem when reading the book is that I forgot I was supposed to be writing a review. It was so good, I just got caught up in the book!

Do check out the companion website integratebutton.com. It currently contains video examples of three practices described in the book. The materials are presented in slide and diagram format. It reinforced the book nicely because it was like a guru explaining his experiences. It also goes into much more detail than the book has room for on each topic.

This is an excellent book and the website adds to it!

* For the JavaRanchers reading this, the first sentence in the book is a quote from Kathy Sierra.

Discuss book in the Saloon — More info at Amazon.com


Implementation Patterns
by Kent Beck


Addison-Wesley Professional
1 edition
November 2007
176 pages
Reviewed by Jeanne Boyarsky, November 2007
  (10 of 10)


"Implementation Patterns" is a great book to make better Java developers. The focus is to make us think about writing more readable and maintainable code. Kent Beck accomplishes this by going thru WHY we write things a certain way.

The audience is Java developers who know the basics of the language. If you have more experience, you will understand points on a deeper level. If you are newer to Java, you will form good habits.

There were just too many things I liked about this book, so here's a list:

- clear, concise and short snippets
- simple, bare-bones diagrams
- discussion on caveats and tradeoffs
- over 100 pages of patterns
- over 75 patterns
- about concepts and OO; not a style guide
- focus on values like communication and simplicity
- section on cross cutting principles like minimizing repetition
- short sections (Kent says some chapters long, but 30 patterns in 30 pages has great subdivision)
- how JUnit 4 design decisions follow theses patterns
- Kent even got in a dig about Sun never removing deprecated code
- bibliography with a blurb from Kent on each title
- pattern index on inside back cover in addition to traditional index

The book can be read straight thru or used as a reference. It's short, light and easy enough that it can be read on an airplane. (and in this case, it was.) It's also organized enough to go back and read about the pattern relevant at the time.

Discuss book in the Saloon — More info at Amazon.com


Software Teamwork: Taking Ownership for Success
by Jim Brosseau


Addison-Wesley Professional
1 edition
November 2007
432 pages
Reviewed by Jeanne Boyarsky, December 2007
  (9 of 10)


"Software Teamwork: Taking Ownership for Success" isn't just about teams. The book provides tips on the individual, group, team and stakeholder levels. (A group is defined as interacting with others without being a team.) I particularly liked the inside cover references. Each of four tables (individual/group/team/stakeholder) that cross reference the chapter number and four areas (trouble signs, success indicators, questions to ask and tools for support.) These combine to form 16 icons. The icons are used within the chapters to highlight key concepts or find them later. While this sounds complicated trying to describe it, it's a case where a picture is worth a thousand words and the concept works very well in reading/navigating/referencing the book.

I also particularly liked the "how is this relevant?" section that ends each chapter. After the chapter summary, the author picks key concepts and asks questions to get you thinking about how it applies in your workplace.

I'm always a bit sceptical of books that claim to address everyone involved in the software development process including managers, developers and stakeholders. This book manages the task impressively.

And finally, the book resonates with problems and phrases used in industry. My favorites are the problem with "and then a miracle happens" and the repeated emphasis on what "done" means throughout the book. There are good analogies, stories and examples throughout the book. It was a great read and very informative. I highly recommend this book.

Discuss book in the Saloon — More info at Amazon.com


Beautiful Code: Leading Programmers Explain How They Think
by Andy Oram & Greg Wilson (editors)


O'Reilly
1 edition
June 2007
618 pages
Reviewed by Frank Carver, May 2008
  (10 of 10)


This is a delightful book. A collection of 33 chapters, each by a different author, all of them worthy of study and thought. Each author was given the same brief - write about your most beautiful code - and the results range widely across the software landscape. Trendy topics such as concurrency and "Map Reduce" nestle cozily with their old friends quicksort and regular expressions. Languages used include the obvious Java and C#, but also JavaScript, perl, Fortran, scheme and others. Don't be frightened, though. No specialist skills are needed other than an inquisitive mind and some experience of software development.

Although there are code samples aplenty in this book, it's not really for direct use. If you want copy-and-paste solutions, look elsewhere. What this book offers is deep insight into what good code is, and how it is created.

It felt somehow wrong to chew and swallow this book for a review. This is a book like a box of fine chocolates; even choosing what to consume next is pleasant anticipation, and each morsel is best savoured, slowly, to get the most enjoyment. Beautiful Code will take a well-deserved place on my bookshelf alongside "The Pragmatic Programmer" and next to the gap where Bentley's "Programming Pearls" once stood. I won't be lending this one out in a hurry, though.

If you care about the craft of code, you should buy this book.

Discuss book in the Saloon — More info at Amazon.com


The ThoughtWorks Anthology: Essays on Software Technology and Innovation (Pragmatic Programmers)
by ThoughtWorks Inc.


Pragmatic Bookshelf
1 edition
March 2008
248 pages
Reviewed by Ulf Dittmer, May 2008
  (7 of 10)


This collection of 13 essays written by various ThoughtWorks (a software consulting company) employees covers a wide range of software development topics. There's no overarching theme - the essays are meant to present current thinking on issues that are being thought about nowadays even if they're maybe not on everybody's mind.

Some essays focus purely on the programming (e.g. domain-specific languages, object design, domain annotations and the mix-and-match of languages that's possible with the JVM and CLR), while the majority addresses issues of the development process. That includes agile testing, performance testing, iteration management, improving the build and release processes and project tracking, amongst others. Some source code in various languages is shown throughout the book, but all is explained, and can be understood even without knowing that particular language.

The depth and style of the essays varies widely, since no two chapters are written by the same author. While all of them should be of interest to any developer or development manager, not many may be applicable to a particular reader's situation. For this reviewer, 4 out of 13 essays were very interesting or directly applicable; that's enough to make the book worthwhile reading. Particularly a chapter about domain annotations (using Java's annotations and .Net's attributes not for code management or deployment purposes, but for issues arising from the problem domain) provided food for much thought.

Discuss book in the Saloon — More info at Amazon.com


Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum (Agile Software Development Series)
by Craig Larman, Bas Vodde


Addison-Wesley Professional
1 edition
December 2008
368 pages
Reviewed by Jeanne Boyarsky, February 2009
  (7 of 10)


"Scaling Lean & Agile Development" has a subtitle "Thinking and Organizational Tools for Large-Scale Scrum." The vast majority of the book applies to software development in general (or at least agile development) and is not specific to Scrum. Two chapters are dedicated to Scrum and some others mention it in passing. Much more space was dedicated to lean practices and Toyota's approach. Which makes sense since "Lean" made the title and "Scrum" made the subtitle.

I liked the emphasis on experiments - ideas to try or avoid. They are spelled out before the book starts and then become the subtitles. I also liked the emphasis on systems thinking and fallacies.

A few points particularly resonated with me including the dangers of lines of code as a metric, the dangers of specialization and discussion of a programming interview.

The book reads like a good textbook. It's not hard to read. There are lots of references to others books (and part two of this book.) It has a good mix between theory and experience. Weighted towards experience - almost like an MBA textbook, but more fun to read.

And it mentions someone from JavaRanch. You'll have to read the book to find out who.

More info at Amazon.com


Addison-Wesley Professional
1 edition
December 2008
368 pages
Reviewed by Lasse Koskela, March 2009
  (8 of 10)


"Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum" is the first of two books co-authored by the same duo. This first volume covers the underlying theory needed for understanding the dynamics of scaling agile development to large organizations, including one of the best introductions to Systems Thinking that I remember reading.

Indeed, the first part of this book is all about thinking tools such as Systems Thinking, Lean Thinking, and Queuing Theory. Throughout the book, the authors refer back to these theories when they try to illuminate the "what" and "why" of various dynamics.

The second part focuses more concretely on how to scale a product development organization. It starts with a thorough, seminal chapter on Feature Teams and continues with more general discussion of what makes teams work. True to their style of writing, these chapters are full of references to related research. Knowing the authors, I expected nothing less. After team work, the authors move on to discussing a scaling technique called "Requirement Areas", specialization, organizational impediments, even budgeting and HR.

The third and last part of the book is essentially an appendix containing the "Scrum Primer" by Gabrielle Benefield and Pete Deemer. Personally, I think this appendix could've been left out, considering that most readers should already be familiar with Scrum.

Again, this book is perhaps the most thoroughly researched text on agile development I've read (and I've read most of them) and the authors clearly know what they're talking about. Having said that, it is also quite a heavy read considering that it's only some 300+ pages. I read it in one day, barely leaving the couch but I can imagine that others might not enjoy the theory-heavy approach as much.

With that said, while it's not full of the kind of concrete tips we'd like to see, this book does offer a strong foundation for understanding how to scale and how not to scale up organizations for agile development. I highly recommend it to leaders, change agents and agile coaches involved in large-scale transitions.

More info at Amazon.com


Implementing Automated Software Testing: How to Save Time and Lower Costs While Raising Quality
by Elfriede Dustin, Thom Garrett, Bernie Gauf


Addison-Wesley Professional
1 edition
March 2009
368 pages
Reviewed by Jeanne Boyarsky, April 2009
  (9 of 10)


"Implementing Automated Software Testing" is meant for software test professionals and managers. The authors also list developers and project managers in the target audience. If an organization has developers/pms in a dual role, this makes sense. The book really is written from a QA viewpoint.

At least one of the authors has done work for the Department of Defense and the other two sound like they have worked closely with it. The writing style reminds me of the CMM documents - a government research paper style leaks through. This isn't a bad thing - I thought it was a very good book - just something to be prepared for.

I particularly liked the distinction between Automated Software Testing and playback/record testing. The book really walks you through setting up an Automated Software Testing program. It contain recipes (which are more like requirements), each of the phases and how to respond to roadblocks. There was a whole chapter dedicated to myths and best practices. For someone setting this up, there are checklists and a job description (skills and roles) needed for each of the phases.

Overall, this book is like a field guide for someone about to start an Automated Software Testing program. My only criticism is that it is acronym heavy - remember the government paper comment - and could have used a glossary.

More info at Amazon.com


The Economics of Iterative Software Development: Steering Toward Better Business Results
by Walker Royce, Kurt Bittner, Michael Perrow


Addison-Wesley Professional
1 edition
April 2009
192 pages
Reviewed by Jeanne Boyarsky, June 2009
  (10 of 10)


The title of "The Economics of Iterative Software Development - Steering Toward Better Business Results" jumped out at me since I'm a software developer at a bank. Software and economics in the same title - cool!

The book is what I call good airplane reading. It's interesting to read, easy to read without a whole pile of focus, can be read in a few hours and doesn't physically weigh to much. The book is mainly geared towards software development managers. Particularly those who want to being iterative development or make their projects more iterative.

The economics comes in through the model of COCOMO, a number of graphs and formulas like net present value. It's not the kind of economics that you have to be an economist to understand. Or even like math for that matter.

In addition to the economics, the book covers things like factors for resistance to change. I particularly liked the section on measurements and how people adjust their over/under reported based on how they think the measurement will be used. I also like the appendix listing the top ten books for managers (like Peopleware) and why to read each one.

Overall, I enjoyed reading the book. I think it is a good book to either show your manager or to read to get a feel for the criteria important to management when selling an idea. And without having to read a whole project management book at that.

More info at Amazon.com


Emotional Intelligence 2.0
by Travis Bradberry, Jean Greaves


TalentSmart
har/onl en edition
June 2009
192 pages
Reviewed by Jeanne Boyarsky, June 2009
  (9 of 10)


"Emotional Intelligence 2.0" is the second edition of a soft skills/career development book. Your EQ (emotional quotient) is the foundation for a large number of soft skills including flexibility, time management, trust, anger management and change tolerance. The book focuses on four areas: self awareness, self management, social awareness and relationship management. Each is illustrated with a scenario showing a good and bad example.

The book comes with an online test. It was basically two pages of questions asking you to rate yourself in various areas. I found it accurate in terms of what I know about my own soft skills strengths and weaknesses.

Some other things I liked about the book:
1) It's small enough to fit in a large purse - making reading convenient.
2) The grouping of techniques and tips by area.
3) A large number of concrete things you can do to improve your soft skills.
4) The fact that each technique is only 2-3 pages - making it something you can read in the morning while having breakfast and focus on for the day.
5) The book was quite up to date - the Hudson River miracle plane landing in NYC (of only a few months ago) was one of the examples.
6) Emotion being listed as a sixth sense.

More info at Amazon.com


Learning jQuery 1.3
by Jonathan Chaffer, Karl Swedberg


Packt Publishing
edition
February 2009
444 pages
Reviewed by Jeanne Boyarsky, June 2009
  (5 of 10)


"Learning jQuery 1.3" caught me by surprise. I had enjoyed Packt's "Learning Dojo" and expected this to be similar. One big difference is that "Learning JQuery" is about twice as long as "Learning Dojo." It's not because there is more content though; it is because there are more unnecessary code examples.

To the point where I felt like I was drowning in code! Not even jQuery code. For example, page 154 is an HTML table. That's it. Want to guess what page 181 was? That's right, another HTML table. Seriously? If I'm learning jQuery, I know what HTML looks like. There are many examples of this. A page of XML here. A whole page of paragraphs of the Gettysburg address. There are also a myriad of browser screenshots of this straightforward HTML.

Not to harp on the wasted space, but this sea of code distracted me and slowed me down as I read. Don't get me wrong - there were many things I did like. The gradually building up of JavaScript. The selector reference. The "nutshell" review of each chapter. (mainly because a lot of it got lost among the unneeded code.)

"Creating Passionate Users" says it is a good thing if readers feel strongly about your book. There's nothing actually wrong with the book. Maybe some beginners really like the handholding of HTML code and will view this as a good thing.

More info at Amazon.com


Exploratory Software Testing
by James A. Whittaker


Addison-Wesley Professional
1 edition
September 4, 2009
224 pages
Reviewed by Jeanne Boyarsky, October 2009
  (9 of 10)


"Exploratory Software Testing" was a very enjoyable read. It is geared towards testers, but I think developers and informal testers can benefit from it as well.

My favorite section of the book was the "tours." This extended analogy compares vacation and testing. It points out different types of testing in a creative and memorable way. Examples:

- "morning commute" = startup
- "arrogant American" provides silly inputs
- "tourist district" differences between experienced/novice users

The author then provides case studies of how the tours were used at Microsoft. I really liked how he showed the importance of focusing on a completely different point of view in different tests.

The first 136 pages provide enough reasons to buy the book. The rest is the author's background, newsletter type posts from university and his Microsoft blog (http://blogs.msdn.com/james_whittaker). While I'm not a fan of blog posts verbatium in a book, it was in an appendix at least.

If I could change three things about the book:
1) A list or table of the tours in one place
2) More consistency in the format of each Microsoft tester's description
3) Order the blog posts by topic rather than chronologically. Posts in a "series" should be together in printed form

As you can see, my biggest "complaints" about the book are quite minor.

And to make the FTC happy: I received a copy of this book from the publisher in exchange for writing this review on behalf of JavaRanch.

More info at Amazon.com


Leading Lean Software Development: Results Are not the Point
by Mary & Tom Poppendieck


Addison-Wesley Professional
1 edition
October 31, 2009
312 pages
Reviewed by Jeanne Boyarsky, November 2009
  (10 of 10)


Wow! I was blown away by how good it was. I expected it to be "light reading" as I'd read about many of the concepts elsewhere. Somehow the authors managed to present them all in a thought provoking way. Even the introduction had me scribbling in the margins. As a result, I only finished 5 chapters in a 6 hour flight. I promptly finished the remainder the next morning. A real page turner.

Each of the chapters follow the same format: detailed example of company applying concepts, 4 frames and brief portrait of how used. A frame is a point of view - like a camera frame. There were detailed examples throughout. Each chapter ends with questions to think about - these aren't classroom exercises - they really help. The frames really drew me in - each time I started the next one, I felt the mental shift.

I'm not sure what my favorite part of the book was - between the current examples (banking crisis, Captain Sully, Obama's website), historical ones (Empire State Building construction), clear diagrams, etc.

The beginning of the book really grabbed me. It explained why Southwest Airlines is so much more successful than the traditional airlines. The fact that I was on an airplane at the time helped, but the example stood on its own.

The fact that I didn't go more than 5 pages without writing a note or more than 1-2 pages without underlining something really speaks for itself. The book was great!

More info at Amazon.com


Making it Big in Software: Get the Job. Work the Org. Become Great.
by Sam Lightstone


Prentice Hall
1 edition
March 20, 2010
456 pages
Reviewed by Jeanne Boyarsky, April 2010
  (10 of 10)


"Making it Big in Software" is a career book that manages to apply to people at many levels. It is good for students, new hires, mid level software professionals and those interested in starting their own company. The author says it is also for those with decades of experience. Probably does but I can't relate to that yet. The book is a mixture of advice, realism about the software world and interviews.

The interviews are interspersed between chapters with selected quotes referenced in the text body. It was a bit disorienting when the quotes were "forward references" but that went away quickly. The author asks the same questions of each interviewee including how they track trends, manage their time, pet peeves and advice. It was fascinating to read what Marissa Mayer (Google) and James Gosling (java) had to say among others. There was a nice balance on the types of people interviewed from CEOs that started their own company to those who rose from the ranks.

I particularly liked the sections on how to define success (it's not just money), the importance of liking what you do and soft skills. Some of the advice was classic (4 quadrants of time management, hype cycle and general advice) and some was software focused (patents, publishing, public speaking). The examples were great. Larry, Curly and Moe were featured regularly in making examples tangible. It reminded me of giving users names in user stories.

What was most valuable:
* for students - school vs job, landing a job
* for those new to the workforce - time management, mentoring skills
* for those experienced - leadership, career planning, routes to success

I enjoyed reading the book and have a whole list of discussion points from it. I highly recommend you buy your own copy!

Discuss book in the Saloon — More info at Amazon.com


Agile Testing: A Practical Guide for Testers and Agile Teams
by Lisa Crispin, Janet Gregory


Addison-Wesley Professional
1st edition edition
January 9, 2009
576 pages
Reviewed by Katrina Owen, May 2010
  (9 of 10)


Agile Testing takes a look at quality from nearly every angle there is, and not just from the tester's perspective. It is not a nitty-gritty how-to test software -- it is assumed that if you are a tester you already have experience with this. It is comprehensive, starting with a 30,000 foot overview of agile and the different types of testing in an agile project, and then proceeding to cover various aspects of producing quality software, mostly from the point of view of testers. Testers are seen as a core part of the development team, and quality is seen as everyone's responsibility.

The book covers many different types of testing, both in terms of how tests are performed (manual vs automated, scripted vs exploratory), or for different purposes (testing correctness vs robustness, ferreting out bugs, solving the right problem, and solving the problem right), or to test different layers of an application (functionality, scalability, usability, performance, load, security). There is an excellent deep dive into automation -- both in terms of how-to automate, and what to automate. The book goes beyond just the mechanics of testing, covering people issues, process issues, and tool issues.

Highly recommended for anyone who works on an agile team, who would like to work on an agile team, or who would like to help transition their team to more agile processes.

Discuss book in the Saloon — More info at Amazon.com


Patterns-Based Engineering: Successfully Delivering Solutions via Patterns
by Lee Ackerman, Celso Gonzalez


Addison-Wesley Professional
1 edition
July 2010
480 pages
Reviewed by Jeanne Boyarsky, October 2010
  (7 of 10)


"Patterns-Based Engineering" is a big thick hardcover book with three parts. The audience is mainly architects/designers with OO, UML and patterns experience. The reader should also be comfortable dealing with abstract thought.

I had different reactions to each part so reviewing separately:

Part 1
The parts on how to generalize and look for patterns in what we do was interesting. It was approachable and I found myself scribbling in the margins.

Part 1a
There was a case study to walk you through how patterns based engineering works in practice. This was the least abstract part of the book, but it had one major problem - too much exposition on the dev team along with their names. Two pages later I was already backflipping to recall who these people are and by the next day/chapter I had no idea. Felt like I was missing something important.

Part 2
The patterns themselves are very reference like and dry. Nothing wrong with it, but didn't hold my attention. Maybe they aren't meant to be read straight through.

Part 3
I was back to being engaged and writing in the margins for the costs and benefits chapters. I think the misconceptions chapter could have been fleshed out more. Parts of it read like "X is a myth because X is not true" and could have used more examples.

---
Disclosure: I received a copy of this book from the publisher in exchange for writing this review on behalf of CodeRanch.

Discuss book in the Saloon — More info at Amazon.com


The Process of Software Architecting
by Peter Eeles, Peter Cripps


Addison-Wesley Professional
1 edition
July 2009
432 pages
Reviewed by Jeanne Boyarsky, November 2010
  (10 of 10)


"The Process of Software Architecting" looks like it could be read in one sitting. Don't be fooled. It is one of the most informative and thought provoking "job discussion" type books I have read in a long time. I made notes in the margins on page 1 and continued to the end.

Another surprise was the preface saying both architects and students are the target audience. True. Students won't get the deepness of it, but they will still learn a lot. Finally, the authors are both IBM'ers but it doesn't read like an IBM book or have an IBM slant. While the case study uses JEE, the authors summarize relevant knowledge beforehand.

Ok. Enough with the surprises. This approachable book is visual and list heavy which makes for easy understanding. Consistent bold keywords help readability. I found myself skimming some parts where the visual said it all. The appendices provide a tabular summary of much content.

For the 200 page case study, they have tasks defined in a summary box. Each task has steps along with checklists/pitfalls/best practices where applicable. I REALLY like this format. I particularly liked the emphasis on providing a mental map/thinking as an architect.

While the case study is simpler than real life, it is supplemented by examples later. My only complaint was the term "right-sizing" to mean scaling small vs large teams. Since this word was hijacked to mean layoffs, it is emotionally charged. But that being my only issue with the book is still pretty good.

I strongly recommend this book for anyone who is an architect or wants to be one day.

---
Disclosure: I received a copy of this book from the publisher in exchange for writing this review on behalf of CodeRanch.

Discuss book in the Saloon — More info at Amazon.com


Glitch: The Hidden Impact of Faulty Software
by Jeff Papows


Prentice Hall
1 edition
September 2010
208 pages
Reviewed by Ulf Dittmer, November 2010
  (3 of 10)


This book aims to describe how to institute a software development process (and the business environment in which it exists) that leads to higher-quality software exhibiting fewer bugs. According to the author, this is done through "better IT governance". Unfortunately, very little of the book is spent on discussing what that means for the actual development process. The most part is taken up by prescriptions so high level as to be either common sense or inactionable. As an example, among the "Ten Ways to Squander IT Governance Resources" are such items as "Enforce bureaucratic processes without explaining the context", "Lock developers out of the code" and "Create reports that nobody can understand". No kidding.

Much of the rest of the book covers a variety of topics demonstrating the importance of IT and software, and how having them exhibit problems can affect millions of people, up to and including posing a danger to their lives. Well, yes, but that's not exactly fresh insight. Someone who has never worked with IT/software topics may find this interesting and illuminating, but not industry insiders.

Reading was somewhat hard work, since there's no common strand along which the content is organized. Each chapter is more or less unconnected to the others, only the very last one tries to tie it all together. Kind of annoying is the author's habit of breaking down each subject into 3 bullet point, and then each of those in turn into 3 more points - it feels like a series of PowerPoint slides, with too little explanation for each bullet.

---
Disclosure: I received a copy of this book from the publisher in exchange for writing this review on behalf of CodeRanch.

Discuss book in the Saloon — More info at Amazon.com


Prentice Hall
1 edition
September 2010
208 pages
Reviewed by David O'Meara, January 2011
  (2 of 10)



Glitch is an interesting book, but to be honest I didn't really enjoy it. The author is certainly an expert in the field and provides plenty of useful information, but at times I found it difficult to distinguish the stories from the proven content from the opinion.

Each chapter has a topic and conclusion but the coverage feels anecdotal and often a bit light, padded by the included stories. Maybe I was a little sensitive while reading it, but the book is fairly short to begin with and while the stories, figures and tables are important to the text it means there is much less content than the 208 official pages. To me it felt more like a collection of articles or presentations than a book.

The topics are wide ranging and touch many aspects of IT in business and the value of this book is in this breadth. The coverage can be used as a check list or refresher for your own IT reviews or provide suggestions on areas to focus in your own organisation, but you could possibly distil this into a one or two page list and move on.

In the end I just wasn't convinced that the book was worthwhile. It was light, padded and occasionally disjointed. Many of the stories weren't software related and I couldn't see how they served the book. It will look nice on the bookshelf but it didn't deliver the experience I was hoping for.

---
Disclosure: I received a copy of this book from the publisher in exchange for writing this review on behalf of CodeRanch.

Discuss book in the Saloon — More info at Amazon.com


Managing Software Debt: Building for Inevitable Change (Agile Software Development Series)
by Chris Sterling


Addison-Wesley Professional
1 edition
December 2010
288 pages
Reviewed by Jeanne Boyarsky, January 2011
  (7 of 10)


I didn't really know what to expect from "Managing Software Debt." It was the first time I've seen the phrase software debt in a title so I was intrigued. The book does not assume you are a developer or a manager and makes it readable for both.

The descriptions of how debt creeps into the process was excellent.

My five favorite parts were:
"abuse stories" (anti-use cases)
the last chapter - people aren't resources and why this matters along with styles of teams
the word "done" repeatedly being in quotes and an exercise on how to create a definition
the cost of someone else paying the cost of your poor decisions
why silos create debt

I made lots of highlights and was engaged as I read. I didn't make notes in the book because some would be less than favorable to someone who could pick it up. It definitely hit home though.

I would have liked some more tips on how to deal with debt and how to prevent it. The book was certainly thought provoking and raised my awareness of debt in day to day work.

---
Disclosure: I received a copy of this book from the publisher in exchange for writing this review on behalf of CodeRanch.

Discuss book in the Saloon — More info at Amazon.com


Leadership, Teamwork, and Trust: Building a Competitive Software Capability (SEI Series in Software Engineering)
by Watts S. Humphrey, James W. Over


Addison-Wesley Professional
1 edition
January 2011
368 pages
Reviewed by Jeanne Boyarsky, February 2011
  (6 of 10)



"Leadership, Teamwork and Trust" is the original Watts Humphrey's last book. While I knew both the authors were heavily involved in TSP, I wasn't expecting a book on TSP. You'd think something like that would be mentioned on the cover.

The book has two parts. Nine chapters (160 pages) of examples, points and content. And 5 pages (144 pages) of appendices about TSP. That's almost half the book! The appendices weren't bad; they just caught me by surprise.

Back to the part of the book that wasn't about TSP. I liked the mix of stories and points. Some stories were like mini-case studies. Some parts really drew me in such as in chapter 4 on how we differ from unskilled laborers and why management really needs to as well. It included the relationship between money/motivation and trust/blame. I also particularly liked chapter 7 on not using metrics against people so as to not taint the data you get back.

Did I mention that part wasn't about TSP. Well, kind of. Many of the examples were from TSP. The implication being that you need TSP to collect data. These points could have been shown as being more broad.

I did like the first part of the book. I'm taking off a lot of points for the strong TSP bias and the fact that it isn't mentioned on the cover or book description.

---
Disclosure: I received a copy of this book from the publisher in exchange for writing this review on behalf of CodeRanch.

Discuss book in the Saloon — More info at Amazon.com


CMMI for Development: Guidelines for Process Integration and Product Improvement (3rd Edition) (SEI Series in Software Engineering)
by Mary Beth Chrissis, Mike Konrad, Sandra Shrum


Addison-Wesley Professional
third edition
March 2011
688 pages
Reviewed by Matthew Brown, April 2011
  (8 of 10)



The Capability Maturity Model Integration® framework was developed as a guide to applying good practices in process improvement, and this is the definitive reference for the "constellation" aimed at the development of products (there are companion volumes for product acquisition and service management).

The book starts with an overview of CMMI and how to use it. Of particular interest here are a number of "perspectives": short contributions on aspects of the history and application of CMMI, and a chapter containing helpful case studies and essays. These are generally the most readable and interesting parts of the book (except for a couple that are a bit too immersed in their own jargon).

The bulk of the content is a reference manual systematically describing the components of the model: the three Generic Goals, 13 Generic Practices, and 22 Process Areas. Each Process Area uses the same format, which makes it simple to follow, if not the most engaging read. Note that all this is freely available in electronic form from the Software Engineering Institute, except for a number of hints and tips.

This is the third edition, covering CMMI-DEV 1.3, which has attempted to streamline and clarify the model. New material includes quite a bit addressing the use of CMMI with agile methodologies - presumably in response to a perception (incorrect, the authors say) that they are in conflict.

Overall it's pretty dry (if you're allergic to acronyms, stay clear!), and abstract, but if you're after a good understanding of the model this is what you need. What it tries to do, it does well. If you want help applying it, though, you're likely to want something more concrete to go alongside it.

---
Disclosure: I received a copy of this book from the publisher in exchange for writing this review on behalf of CodeRanch.

Discuss book in the Saloon — More info at Amazon.com


Agile Hiring
by Sean Landis


Artima Inc
1 edition
March 2011
213 pages
Reviewed by Jeanne Boyarsky, May 2011
  (8 of 10)



"Agile Hiring" is not about hiring for agile projects. It's about how to hire good software developers in general and is inspired by agile concepts.

The book targets those hiring experienced full timers rather than hiring contractors or entry level employees. I particularly liked including ratios as guidance for how well you are screening at all levels. There was an emphasis on different types of leadership and the long term along with a cute dating analogy. I particularly liked the techniques provided for probing on the phone.

I would have liked more examples of "here's something from a resume; here's how to interpret it" so I could practice and see more of what specifically to look for. There was also one instance of an index reference not being removed which jumped out at me. I only noticed it once so not a big deal though

Overall, I enjoyed reading this book. It motivated me to go back and look at resumes for people we've hired to look for trends and screen better based on that. Feedback loops are good!

---
Disclosure: I received a copy of this book from the publisher in exchange for writing this review on behalf of CodeRanch.

Discuss book in the Saloon — More info at Amazon.com


Software Build Systems: Principles and Experience
by Peter Smith


Addison-Wesley Professional
edition
March 2011
624 pages
Reviewed by Wouter Oet, May 2011
  (3 of 10)



This books promises to explain the principles of a build system and compare the leading build tools.

The author starts by explaining what a build system is. Although useful, this is done is such a basic way that most developers will learn nothing new.

Further into the book the author tries to compare "the five leading build tools": GNU Make, Ant, SCons, CMake and Eclipse's build system. Each tool has its own chapter and an example to build software with that tool is used. These examples can be hard to follow since the syntax of the tool is not adequately explained. I have never used Make but am expected to understand:

%.d: %.c
@$(CC) -MM $ (CPPFLAGS) $< | sed 's #\(.*\)\.o: #\1.o \1.d: #g' > $@

I rather would have seen an abstract explanation of what the tool does and a bigger number of tools. For instance the tool Maven could have got a little more attention than the 1.5 pages it was mentioned in. The book does not contain a table in which the tools where compared to each other which would have been very handy.

The last couple of chapters are about "Advanced topics" and "Scaling up". The advanced topics are about dependencies, testing, installation, version management, build machines and tool management. Most of these topics are contain such basic development skills that I wouldn't call it advanced.

In conclusion I would not recommend this book and just buy a book that is specific for your build tool of choice. If you're looking for a new build tool then just spend a day or 2 trying a couple of them out.

---
Disclosure: I received a copy of this book from the publisher in exchange for writing this review on behalf of CodeRanch.

Discuss book in the Saloon — More info at Amazon.com


Individuals and Interactions: An Agile Guide
by Ken Howard, Barry Rogers


Addison-Wesley Professional
1 edition
April 2011
240 pages
Reviewed by Jeanne Boyarsky, May 2011
  (7 of 10)



"Individuals and Interaction - An Agile Culture" is like two short books in one. The first half is basically a business book with a little about agile. The major parts are DISC personality profiles, how they affect team dynamics, how people react to change, etc. There were some references to agile, but agile serves more as a backdrop/story since the major points apply in general. The second half is a facilitator's guide to communication/teambuilding exercises.

The book was easy to read and has good points. I was worried when the introduction had the last paragraph repeat twice, but the rest of the book was solid.

Even though the facilitator's guide part of the book doesn't apply to everyone, it is worth buying the book for the first part alone. The agile backdrop is a nice way to keep techie's attention through a soft skills book. That said, given the choice, I'd probably buy a book that focused on the communication techniques throughout the whole book.

---
Disclosure: I received a copy of this book from the publisher in exchange for writing this review on behalf of CodeRanch.

Discuss book in the Saloon — More info at Amazon.com


The Clean Coder: A Code of Conduct for Professional Programmers (Robert C. Martin Series)
by Robert C. Martin


Prentice Hall
1 edition
May 2011
256 pages
Reviewed by Jeanne Boyarsky, June 2011
  (9 of 10)



Yes, "The Clean Coder" is a sequel to Uncle Bob's "Clean Code." This is a great book and drills what being a professional developer really means as delivered by a well respected source.

The book is very readable and contains advice mixed with stories from the author's past and dialog. I like the use of dialog to show communication issues like saying "done" or over committing. Even the foreword was a story.

I think there was too much repetition of the stories across chapters. Almost like the chapters were written in standalone form. I felt like I read about the same employer (introduced from scratch) a few times. It was interesting hearing about the punchcard world with lessons and how things have changed. Same for FitNesse. I get that it has unit tests.

The advice is excellent. My favorite three (that were fairly unique for computer literature):
1) difference between performance and practice
2) TDD on offense vs defense
3) focus manna on time management

The only advice I felt strongly against is being in the "flow" being a bad thing. As long as you define the problem out of the flow, I don't see the problem with isolating yourself from the big picture temporarily.

---
Disclosure: I received a copy of this book from the publisher in exchange for writing this review on behalf of CodeRanch.

Discuss book in the Saloon — More info at Amazon.com


Prentice Hall
1 edition
May 2011
256 pages
Reviewed by Mohamed Sanaulla, December 2011
  (10 of 10)



I would say that this is a must read book for all the programmers. Its packed with much needed advice in the current scenario. If you aren't much exposed to the industry (may be you are freshmen), I dont think the book might make much sense. Because lot of ideas discussed in the book would directly apply to your daily activities. We always think that programmers are professionals, but author in the book clearly mentions what it takes to be a professional programmer.

Author takes us along each chapter using either anecdotes related to his life and work or by using conversations between key people relevant to the topic. This way you dont get bored while reading through the topics and can understand the possible type of implementation of the idea.

Author has covered testing and its related strategies over 3 chapters, this shows how important testing is for a product. I got to know in detail about TDD, and other testing strategies and now I can connect these ideas to my work.

Not only technical aspects but also personality development related topics are covered in the book giving the reader a possible all round development.

I found the anecdotes were a lot repeated, but its makes sense because few of them had lot of lessons to be learnt. Few specifications of computers were hard to understand, but it helped me to imagine the skill of the programmers in those 70s and 80s when the technology was still at a nascent stage.
I learnt a lot of new tool names, new testing techniques and few tips for improving my productivity at work and also to learnt the importance of continuous learning and practicing. Overall it was a really good read, managed to complete most of the chapters in one sitting

---
Disclosure: I received a copy of this book from the publisher in exchange for writing this review on behalf of CodeRanch.

Discuss book in the Saloon — More info at Amazon.com


Scalability Rules: 50 Principles for Scaling Web Sites
by Martin L. Abbott, Michael T. Fisher


Addison-Wesley Professional
1 edition
May 2011
272 pages
Reviewed by Matthew Brown, June 2011
  (9 of 10)



This book distils the experience of two practitioners in the field of scalability into a set of rules intended to help anyone building and supporting web applications make sure their products are scalable. And when they say scalable, they mean seriously scalable. They frequently refer to "hyper-growth" companies - the sort of potential Facebooks that might need to allow for almost unlimited growth and don't want to be held back by an infrastructure that can't cope.

The 50 rules themselves cover a very varied range. Some are very high level: "Learn Aggressively" being one such. While not mixing networking gear from different vendors is one of the more specific recommendations. Some may be more controversial but are strongly argued for on scalability grounds. Each has a brief summary of What, When, How and Why, followed by a more detailed (but still fairly brief) discussion of why the rule is important and how to go about using it. At the end the rules are prioritised according to cost and impact.

A couple of themes are common throughout the book. One is their concept of a Scale Cube, illustrating the three axes of scaling (replication, splitting by function, and splitting by affinity). Another, which is striking in what is essentially a technical book, is a very consistent focus on the underlying business: for example, the authors' insistence on ensuring the cost of handling data is less that its value.

There's lots of useful and interesting stuff to learn here, even for those that won't get a chance to put it all into practice, and the format and size make it one to dip in to frequently.

---
Disclosure: I received a copy of this book from the publisher in exchange for writing this review on behalf of CodeRanch.

Discuss book in the Saloon — More info at Amazon.com


Addison-Wesley Professional
1 edition
May 2011
272 pages
Reviewed by Deepak Bala, August 2011
  (8 of 10)



Scalability rules is a book that contains short excerpts of useful advice. When reading through the pages, I can easily relate to the limitations mentioned in the book which will affect scalability and performance. Many rules are derived from real world experience which you can benefit from.

Some of the topics covered in this book are caching at various layers; how caching can affect state; technologies that can help you scale; types of scaling; database related recommendations on scaling etc etc. You can certainly learn a thing or two while going through these rules.

Now, For what I didn't like about the book...

1. The authors kept plugging in their website into the discussion.
2. Sometimes the alternative discussed to a specific problem was not as elaborate as it should have been.

Overall this is a book that will serve you well as a short reference on things you need to keep in mind while designing solutions to scale. I would certainly recommend it to a co-worker.

---
Disclosure: I received a copy of this book from the publisher in exchange for writing this review on behalf of CodeRanch.

Discuss book in the Saloon — More info at Amazon.com


Growing Object -Oriented Software, Guided by Tests
by Steve Freeman, Nat Pryce


Addison-Wesley Professional
1 edition
October 2009
384 pages
Reviewed by Jeanne Boyarsky, June 2011
  (9 of 10)



The person who handed me this book said it was "better than Lasse's book" (Test Driven.) I disagree. One can't compare the two books - Test Driven is meant for beginners and this book is meant for an advanced audience. If you have never written unit tests before, this book is very hard to follow. So put it down, get an intro book and come back.

I really liked the emphasis on making the software responsive to change along with separating acceptance and unit tests. The book uses Junit 4.6 and therefore covers Hamcrest matchers for both JUnit and JMock. I like the authors cover best practices, good design and clearly indicate what is a personal preference. I really liked part 4's emphasis on things that are hard to test at a higher level than "extract method."

The only thing that prevents me from giving full marks, is the case study. While I did read this part in one sitting, it was still hard to follow. There was a lot of information to keep in mind while trying to focus on the lessons of the example. I also think it was admirable for the authors to use a Swing example since Swing is harder to test. However, Swing is also less common for Java developers to use actively adding another block to understanding the software growing/testing aspects. And it is even harder for non-Java developers who are in the target audience for the book.

Except for the case study, I thought the book was amazing. And I'm sure the case study is a matter of taste.

---
Disclosure: I received a copy of this book from the publisher in exchange for writing this review on behalf of CodeRanch.

Discuss book in the Saloon — More info at Amazon.com


Apache Maven 3 Cookbook
by Srirangan


Packt Publishing
1 edition
August 2011
224 pages
Reviewed by Jeanne Boyarsky, March 2012
  (8 of 10)



"Apache Maven 3 Cookbook" is an introductory Maven book. It explains the concepts well. It's been a while since I read a Packt book and it looks like they fixed the proofreading/formatting problem. I only noticed one formatting error, which is nothing. And it was 5.o vs 5.0 - hardly something that interferes with readability.

The beginning was a bit repetitive. The how to install for Windows/Mac/etc repeat pieces instead of having one section and showing the differences.

The cookbook recipes show common things you'll start with - building different types, a Spring app, etc. It even shows Google app engine. The book also includes tools like coding standards. The author says codings standards tools help "lesser experienced programmers adhere to standards expected of them." Hmm. Experienced folks need standards too. Can't remember everything!

That would be only complaint. The book shows so many different things, there isn't room for depth. I have concerns about the depth of the Sonatype book too though so I can hardly hold it against the Packt book. (I'd like links to references on where plugin variables and the like are stored.)

---
Disclosure: I received a copy of this book from the publisher in exchange for writing this review on behalf of CodeRanch.

Discuss book in the Saloon — More info at Amazon.com


Agile Project Management with Scrum (Microsoft Professional)
by Ken Schwaber


Microsoft Press
1 edition
March 2004
192 pages
Reviewed by Jeanne Boyarsky, April 2012
  (7 of 10)



"Agile Project Management with Scrum" is a series of case studies to make points about using Scrum properly.

The book begins with an overview of Scrum. The majority of it is introducing a company and showing how they (mis) used Scrum. It's an excellent example of learning from the mistakes of others rather than repeating them on your own.

This really gets called out in the lessons learned section for each case study. I would have liked some tips on how project managers should deal with "insulating the team" from problems. One example was extreme where he hired an investigator to track down someone with the knowledge that went on a planned vacation. Someone should have asked for it beforehand. Scrum isn't supposed to be about individual heroes and I felt this was space that could have been used for a common scenario.

In one diagram, there is a typo of "Spring" instead of "Sprint". It doesn't detract from the reading at all, but I was entertained because I do that a lot!

Discuss book in the Saloon — More info at Amazon.com


The Scrum Field Guide: Practical Advice for Your First Year (Agile Software Development Series)
by Mitch Lacey


Addison-Wesley Professional
1 edition
March 2012
416 pages
Reviewed by Jeanne Boyarsky, May 2012
  (10 of 10)



"The Scrum Field Guide" is a nice way to get started with Scrum. It covers the practices through useful stories and advice. Heavier on the advice side. The stories seem realistic and highlight important points.

I liked the tables and tips provided. For example how to estimate the first time and how to map pre-Scrum roles. And I loved that there was a whole chapter on "done." I also liked the concept of corporate mandates being a tax on your time.

I also liked the practical advice and explanations such as why it is a bad idea for the product owner and Scrummaster to be the same person. Along with what compromises in roles are better to make than others.

I only spotted one typo (first vs last on page 205), but easy to see what was intended.

I will definitely be recommending this book to my teammates!

---
Disclosure: I received a copy of this book from the publisher in exchange for writing this review on behalf of CodeRanch.

Discuss book in the Saloon — More info at Amazon.com


Addison-Wesley Professional
1 edition
March 2012
416 pages
Reviewed by Matthew Brown, May 2012
  (9 of 10)



This engaging book doesn't try to teach you what Scrum is - it's quite open about that - though it doesn't assume too much knowledge either (and there is an appendix describing the Scrum framework). What it does do is give practical advice. It's targeted at people who are about to adopt Scrum, or have recently adopted it, and it aims to give solutions to the specific problems that everyone is likely to come up against at some point.

The chapters can be read independently, and each one follows the same format. Firstly, there's a story about a development team that encountered a problem related to the theme of the chapter. Often they'll solve that problem, but not always. Then there's a description of an approach to solving that problem, and an analysis of the factors to consider to make sure the approach is successful.

What I particularly like about this book is that it is grounded in realism. While the ideal scenario for Scrum may be a fully aligned company with dedicated teams and supportive senior management, many people have to cope with less than perfect realities. There might be clashing organizational structures and cultures, team members with other responsibilities, legacy systems to support, and so on. This book recognises the real obstacles agile teams might meet, and suggests realistic ways of combating them. Along the way you'll also get good advice about putting the various agile practices to work.

I'd recommend this to anyone thinking of using Scrum, or anyone already using it who's finding the going less than perfect and is wondering where it all went wrong.

---
Disclosure: I received a copy of this book from the publisher in exchange for writing this review on behalf of CodeRanch.

Discuss book in the Saloon — More info at Amazon.com


The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses
by Eric Ries


Crown Business
edition
September 2011
336 pages
Reviewed by Deepak Bala, June 2012
  (7 of 10)



The title of this book is a bit of a misnomer. The intro and prologue suggest that it is aimed at entrepreneurs that are looking to bootstrap a company in the IT domain. The author's background; introduction to IMVU (his company); reference to the dot-com-bubble; led me to believe that this was the case. Through the course of the book the author dilutes this focus. The book is still interesting in many ways.

What I like:

There are many anecdotes in this book. The author helps you experience some of the emotion that he went through at IMVU and other companies through them. Each short story brings out a problem and its relevant solution. Most of these are pretty common knowledge, but some stand out and give you a fresh perspective. I liked the chapters about innovation accounting and testing assumptions. It was interesting to read about how entrepreneurs tested their initial products to assert that it really solved a problem and would be used by a large group of people.

What I dislike:

1. The chapters are very wordy. Far fewer words could have been used to get the point across.
2. The focus is diluted. This book should have stuck to startups and IT. I am not really interested in governments acting like startups or why corporations should hire entrepreneurs in residence.
3. After a few chapters the book feels like a promotional tool for lean startup consulting services. That helps explain #2.

Additionally, the reference section is a separate chapter towards the end of the book. This is very annoying. I need two bookmarks just to get to the reference each time and flipping pages to get to another section breaks continuity.

Conclusion:

I would recommend this book, but it could have turned out so much better.

Discuss book in the Saloon — More info at Amazon.com


TOGAF 9 Foundation Exam Study Guide: For busy architects who need to learn TOGAF 9 quickly
by Kevin Lindley


CreateSpace Independent Publishing Platform
stg edition
July 2012
198 pages
Reviewed by Jeanne Boyarsky, April 2013
  (8 of 10)



My biggest problem with the official study guide for TOGAF that it only appears to be available in PDF format. I like to scribble in a book as a study. For only $20, this book comes printed. Kevin Lindy's book also has the advantages of being shorter and having more practice questions. Good news all around.

Some of the questions in Kevin's book are harder than the real exam questions. Especially "which 5 of the following 8 are true" type questions. But they were good for reinforcing knowledge and looking for keywords in the answers.

I found a couple of questions with suspect errors so I had to take off a star or two. But it was still worth it. I found it significantly easier to learn from Kevin's book than then official study guide. It was a great investment of $20.

Discuss book in the Saloon — More info at Amazon.com


The Essence of Software Engineering: Applying the SEMAT Kernel
by Ivar Jacobson, Pan-Wei Ng, Paul E. McMahon, Ian Spence, Svante Lidman


Addison-Wesley Professional
1 edition
January 2013
352 pages
Reviewed by Jeanne Boyarsky, April 2013
  (10 of 10)



"The Essence of Software Engineering - Applying the SEMAT Kernel" looks to be a classic one day. Not today of course because it just came out. But one day.

SEMAT stands for Software Engineering Methods and Theory. Don't let the word "theory" scare you. It's not a book about theory. It's a way of looking at software. All projects have some things in common. Using a common language to describe them and looking at key concepts (alphas) makes for better software. The book is geared to software professionals and students. With a goal of making for better developers. And SEMAT isn't done. They are incremental releasing supporting products through 2014.

I liked the parts about practices more than the kernel - I think because it was more concrete. The kernel does raise key points though. Some of which we take for granted and some of which we forget about.

The cards and checklists are useful. Did I mention the cards? They are quite prevalent in the book. I wish it said where to buy them.

I particularly liked the chapter on scaling. It didn't just cover scaling volume. It also covered zooming in and reaching out to others.

It will be interesting to see if SEMAT catches on. But even it doesn't, the key points still matter and it is worth the read.

---
Disclosure: I received a copy of this book from the publisher in exchange for writing this review on behalf of CodeRanch.

Discuss book in the Saloon — More info at Amazon.com


Addison-Wesley Professional
1 edition
January 2013
352 pages
Reviewed by Vijitha Kumara, January 2014
  (9 of 10)



This Book particularly is about the software engineering process standard (and theoretical aspects behind it) called SEMAT (Software Engineering Method and Theory) initiated a few years ago.

The book as a whole explains the elements of the SEMAT kernel and how they fit in to the various stages of the software development life cycle. .

It begins with an introduction to the SEMAT kernel, taking a typical software development approach as an example (makes it easier for someone who's new to the concept to understand) to illustrate the concepts behind the SEMAT kernel. Good to see that the chapters are organized in to small number of pages and key elements are explained with various graphics/diagrams and proper descriptions.

Book describes some of the most important parts of the kernel; alphas, their states, checklists and the ability to extend the kernel to define/construct methods of your own. The book also describes even the minor characteristics that most teams do not worry about but critical to the success which are actually an important part of the SEMAT kernel itself. It also describes how the approach can be adapted from small scale to large scale development in later chapters.

What looks good about the SEMAT concept is that it lets the user create/customize their own process still being based on the SEMAT kernel.

As the SEMAT concept is still at early stages of its life, this will be an excellent introduction for both practitioners and academic studies as a guide to explore the principles of an emerging standard.

---
Disclosure: I received a copy of this book from the publisher in exchange for writing this review on behalf of CodeRanch.

Discuss book in the Saloon — More info at Amazon.com


A Practical Approach to Large-Scale Agile Development: How HP Transformed LaserJet FutureSmart Firmware (Agile Software Development Series)
by Gary Gruver, Mike Young, Pat Fulghum


Addison-Wesley Professional
1 edition
November 2012
208 pages
Reviewed by Junilu Lacar, July 2013
  (9 of 10)



This little gem comes in at about 200 pages but is by no means a lightweight in content. It is chock-full of useful information and advice based on practical, real-world experience. While it has the obligatory section to review the Agile Manifesto and Twelve Agile Principles, this book is by no means just a rehash of topics you'll find in introductory books on Agile. It is a full case study of a large-scale, long-term agile transformation in a large corporate setting.

The authors, who include an executive, a program manager, and an architect, detail their journey in transforming the Hewlett Packard LaserJet FutureSmart Firmware program with agile principles and practices. They walk through many of the key technical and management decisions, explaining the principles on which those decisions were made and describing the practices and tools they used. They cover just about everything too, from architecture to tools and practices, from team culture to team management.

What I found most interesting and valuable in this book is its emphasis on a clean and flexible software architecture as a key driver and enabler for agile transformation. The only thing I thought was missing was a mention of the kind of coaching they had and the dynamics around that. It's hard to imagine a large-scale agile transformation without any kind of coaching going on. Otherwise, you really can't go wrong with a book that says software architects should also code.

This book is definitely worth a thorough reading and re-reading if you are undertaking a large-scale agile transformation.

---
Disclosure: I received a copy of this book from the publisher in exchange for writing this review on behalf of CodeRanch.

Discuss book in the Saloon — More info at Amazon.com


Scrum Shortcuts without Cutting Corners: Agile Tactics, Tools, & Tips (Addison-Wesley Signature Series (Cohn))
by Ilan Goldstein


Addison-Wesley Professional
1 edition
July 2013
208 pages
Reviewed by Jeanne Boyarsky, August 2013
  (9 of 10)



"Scrum Shortcuts without cutting corners" was an enjoyable read. It consists of 30 tips that can be read in any order. As I read, I had a mix of reactions:
Of course, doesn't everyone do that
I wish we did that
Good idea

I like the dose of reality - for example recognizing fractional team members exist. There was colorful language - "pretty waterfall along the way", "Scrummer-fall" and "attention deficit disordered puppies" (which probably is politically incorrect but a really funny phrase).

I also liked the warnings. The definition for good vs evil metrics is quite useful.

Most importantly, I have a bunch of items to suggest at future retrospectives. Definitely worth the read!

---
Disclosure: I received a copy of this book from the publisher in exchange for writing this review on behalf of CodeRanch.

Discuss book in the Saloon — More info at Amazon.com


Peopleware: Productive Projects and Teams (3rd Edition)
by Tom DeMarco, Tim Lister


Addison-Wesley Professional
third edition
June 2013
272 pages
Reviewed by Mohamed Sanaulla, October 2013
  (9 of 10)



Peopleware is a must read for Managers who want to explore and learn about different managerial responsibilities and learn about what not to be done while executing those responsibilities. The content is presented with a touch of humour so you need not be surprised if you are found laughing while you are reading. The authors have penned in their experience and what the have seen and learnt about managing people over the years. The book deals identifying right metrics to enable efficient management of IT projects citing the major factor deciding the fate of IT Projects is the people involved in it and not much due to the technological factors.

If you are not a manager yet- you will find some of the chapters/sections of the book interesting and helps you to know how things work at a managerial level. But there are other chapters which make you feel bored like the section on arranging office furniture.

There are lot of one liners through out the book which are really catchy. Few of which I have noted in the first few chapters of the book are:

- The main reason we tend to focus on the techincal rather than the human side of the work is not because it's more crucial, but because it's easier to do.
- People under time pressure don't work better- they just work faster.
- Quality is free, but only to those who are willing to pay heavily for it.

To conclude Peopleware is a MUST read for IT Projectr Managers and I will recommend this along with another great book: "The Mythical Man month".

---
Disclosure: I received a copy of this book from the publisher in exchange for writing this review on behalf of CodeRanch.

Discuss book in the Saloon — More info at Amazon.com


Addison-Wesley Professional
third edition
June 2013
272 pages
Reviewed by Greg Charles, November 2013
  (8 of 10)



Murach's Android Programming is a good introductory course to Android development. Its style is dry and matter-of-fact, and lacks the visual punch of something like the "Heads First" series, or the conversational tone of various other texts. However, it is clear and accurate, and the many downloadable examples are well integrated into the text, which makes it easy to follow along and try out the techniques as they are presented.

Mr. Murach assumes basic to intermediate Java programming abilities, but otherwise the prerequisites for this book are very low. In addition to covering Android specific topics, he gives thorough explanations of how to set up and use Eclipse, how to work with XML files, and even about event handling and listeners. Seasoned developers will find themselves skimming some of the early sections, but that is certainly better than being lost.

I was disappointed with the Eclipse tooling for Android development and found it very difficult to work with. That's hardly the fault of this text, but I would have liked to see more coverage of alternate tools or at least clearer explanations of how the Eclipse tools are organized, and some discussion of known bugs and advice for workarounds.

In short, this book will get you from no knowledge of Android to being able to write moderately complex apps and deploy them to Android devices. It won't be the only book you'll read if you decide on an Android career, but it will set you down the path.

---
Disclosure: I received a copy of this book from the publisher in exchange for writing this review on behalf of CodeRanch.

Discuss book in the Saloon — More info at Amazon.com


SonarQube in Action
by G. Ann Campbell, Patroklos P. Papapetrou


Manning Publications
edition
November 2013
392 pages
Reviewed by Jeanne Boyarsky, January 2014
  (9 of 10)



"SonarQube in Action" is a book I have been looking forward to reading since the book promotion at CodeRanch. During the promo, I learned that I knew about SonarQube (formerly Sonar) than I realized and that I was ready to learn even more.

The book has two focuses. One is how to use SonarQube well. The other is how to improve quality using SonarQube. This includes how to use the metrics, the quality axis and how it affects teams.

I particularly liked the "related plugins" part of each chapter. The screenshots were good zooming in on the parts to focus on. The lifecycle state diagram for normal and manual rules was useful

This is one of a select group of books that has something for everyone from beginners through power users.

The most important measure of whether this book is good is whether I have a list of things to look into at the end. And I definitely do! Both things I learned and things that it reminded me of. A great read. If you are using SonarQube, you should definitely but this book. It supplements the official documentation nicely by providing a different perspective.

---
Disclosure: I received a copy of this book from the publisher in exchange for writing this review on behalf of CodeRanch.

Discuss book in the Saloon — More info at Amazon.com


The ThoughtWorks Anthology, Volume 2: More Essays on Software Technology and Innovation
by ThoughtWorks Inc.


Pragmatic Bookshelf
edition
October 2012
248 pages
Reviewed by Ulf Dittmer, February 2014
  (6 of 10)



A collection of 11 essays by ThoughtWorks employees, this is the 2nd such collection from the company. Unlike the 1st collection, this time they are grouped -a bit uneasily- into 4 categories, but the only value the grouping provides is to signal to a prospective reader in which topics the book is a bit heavier than in other ones. Languages and Testing in particular are treated in depth.

Like in the first collection, the breadth, the width, and the style of the essays varies a good deal, and probably every reader will find some of them interesting, some pointless, and some in between. That calls into question the value of them being published together. Anyone practicing in the software development field who's a bit interested in following trends will not find much new material here, although any given essay may hit just the sweet spot for a particular reader. For someone who hasn't followed the field closely and wants to reacquaint himself, or just broaden his perspective, the book may well provide some fresh ideas, sort of like going to a conference provides fresh insight on some topics where one didn't even know that fresh insight was to be had.

---
Disclosure: I received a copy of this book from the publisher in exchange for writing this review on behalf of CodeRanch.

Discuss book in the Saloon — More info at Amazon.com


Hudson 3 Essentials
by Lloyd H. Meinholz


Packt Publishing
edition
December 2013
124 pages
Reviewed by Jeanne Boyarsky, February 2014
  (7 of 10)



"Hudson 3 Essentials" is the second Packt book I've read that I felt was too short. Lesson to myself: check the page count before requesting. (Nothing against short books - I loved "HTML 5 Security" which is a 50 page e-book. But it isn't priced at $30.)

The intro text is short - at 8 pages - which is good. It includes why Hudson is important plus the history of Hudson vs Jenkins. Chapter 2 covers how to install Hudson on four servers in 16 pages. This felt rushed. If you are starting out by explaining that JBoss, Tomcat, etc are servers, a few pages including screenshots isn't enough of an intro to get started. I would have preferred just one in more depth.

If you are keeping track, we are now a quarter through the book.

As for the meat, I liked the coverage of how to configure Hudson. I like the explanation of how to create your own plugin although it felt very rushed and I would have liked a deeper dive. And if I was new to Hudson, I'd have liked to see how to run a job before writing my own plugin.

One good differentiator is that the sample project is a grails one rather than a Java one like most examples.

The last chapter covers how to upgrade to Hudson 3.1.

Overall, there wasn't anything wrong with the book. I'm giving it a neutral rating because I would have liked to see more depth.

---
Disclosure: I received a copy of this book from the publisher in exchange for writing this review on behalf of CodeRanch.

Discuss book in the Saloon — More info at Amazon.com


Java Extreme Programming Cookbook
by Eric M. Burke and Brian M. Coyner


O'Reilly
1 edition
March 2003
352 pages
Reviewed by Frank Carver, October 2003
  (8 of 10)


This book covers a very similar selection of tools and techniques to "Java Tools for Extreme Programming" by Hightower and Lesiecki, and in a broadly similar way. Both use the currently fashionable idea of Extreme Programming (XP) to attract readers to a collection of short pieces about a bunch of useful tools for Java programming.

The XP stuff is covered quickly at the start, the meat of the book is in the "recipes", which walk you through configuring and using tools such as Ant, JUnit, Cactus etc. to build, unit-test and manage the development of a Java project.

The tools and tips the authors have chosen to include are a good representation of current practice, but I have a few reservations about the organization and structure of the book. My biggest worry is whether the target reader is actually likely to find many solutions. The authors seem to assume that everyone will pore over the several pages of "contents" at the front of the book every time they hit an obstacle, but in my experience they are just as likely to flip through pages or head for the index at the back, neither of which works particularly well. Worse than that, they may never think to look in the book in the first place - the "Extreme Programming" in the title may help it sell, but it's not something that jumps to mind when you are struggling to get Ant to deploy a web application to Tomcat.

Discuss book in the Saloon — More info at Amazon.com


O'Reilly
1 edition
March 2003
352 pages
Reviewed by Jessica Sant, April 2003
  (7 of 10)


Java Extreme Programming Cookbook consists of a bunch of "recipes" for helping you to build and test Java programs through XP. Each recipe consists of a Problem, Solution, Discussion and a "See Also" pointer to where you can find more information about the topic. The recipes cover the following opensource technologies: Ant, JUnit, HTTPUnit, Mock Objects, Cactus, JUnitPerf and XDoclet.

Want define a classpath using Ant? Check out recipe 3.7. Wanna test a form in your web application? look at recipe 5.9. This book gives a bunch of good strategies to commonly encountered problems, but it's by no means a complete reference to the different technologies. But it will definitely get you started, and you'll be able to apply these different recipes to your own development environment.

The organization of the recipes and consistency between the chapters is where this book lost points in its rating. Want to know how to run JUnit with Ant? look in the Ant chapter. Want to know how to run HTTPUnit with Ant? Look in the HTTPUnit chapter. The Cactus chapter has a nice recipe about ?When not to use Cactus? and the JUnitPerf chapter has a nice recipe about "When to use JUnitPerf"? it would have been VERY helpful to have such sections for EACH technology discussed in the book, but alas the book is inconsistent.

Overall, I think this is a good book to jump-start you into an XP development environment using open source technologies.

Discuss book in the Saloon — More info at Amazon.com


O'Reilly
1 edition
March 2003
352 pages
Reviewed by Simon Brown, July 2003
  (9 of 10)


I've been reading this book for the past couple weeks and have to say that it's another great book from O'Reilly, although upon seeing the title I was slightly skeptical for a couple of reasons. First of all, I already have the Java Tools for XP book and secondly, the title is slightly misleading.

As regards the title of the book, I have the same complaint as the other book, namely that "XP" is unnecessarily used in the title. Since XP is currently a buzzword, I imagine that this was probably to attract a wider audience. Okay, some of the book does talk about XP and practices such as continuous testing and integration, but the book could have easily been titled "Java Open Source Tools Cookbook" because that's essentially what it is.

Title aside, the content of this book really shines through. Where the Java Tools for XP book talks about tools like JUnit, Ant, Tomcat, etc, this book provides recipes for using those tools, with each recipe addressing a particular problem. For example, there are recipes for building with Ant, testing classes, structuring tests, testing paths through web applications and so on. Imagine a design patterns book but with open source tools. Each problem is explained and followed up by a possible solution. The tools that are covered include all of the major open source offerings (Ant, JUnit, Tomcat, HttpUnit, Cactus, etc) in addition to some other tools such as JUnitPerf that many people may not have come across.

While you can read this book cover to cover, I feel that its real strength is as a reference book to be kept on your desk during development. Also, I think that there is something in this book for everybody. For example, although I've used many of these tools before, I still picked up quite a lot from this book, particularly around some of the less common JUnit functionality and the Ant recipes around automatically starting Tomcat and checking that it's running. Regardless of whether you are doing XP, I would recommend this book to anybody starting out with open source tools or using them from day to day on a project.

Discuss book in the Saloon — More info at Amazon.com


Pragmatic Unit Testing in Java with JUnit
by Andy Hunt, Dave Thomas


Working Effectively with Legacy Code
by Michael Feathers


Prentice Hall PTR
1 edition
October 2004
456 pages
Reviewed by Jeanne Boyarsky, November 2004
  (10 of 10)


"Working Effectively with Legacy Code" is a very valuable resource. The author defines "legacy code" as "code without tests." It doesn't matter whether the code was written last week or ten years ago. There is more emphasis on old code that nobody understands, mainly because it is messier and harder to work with.

The examples in the book are mainly in C, C++ and Java, but there are a couple in C# and Ruby. While it is essential to know one of these languages, the author provides enough information to understand the others. When a technique only applies to a certain language, it is clearly indicated.

The author shows how different diagrams can help you learn how to understand code. In addition to UML, there are dependency and effect sketches. The author uses these to show how to think about understanding and refactoring. Other tools, such as refactoring browsers and mocks are explained.

Speaking of refactoring, there are "dependency breaking techniques" (aka refactorings) with step-by-step instructions (Martin Fowler style) throughout the book. There are also explanations of why patterns and design rules exist. Most importantly, there are lots and lots of cross-references and an excellent index.

Working with legacy code isn't fun, but this book helps make it as painless as possible. With the split emphasis between psychological/understanding/techniques and refactoring, this book is both a great read and an excellent reference.

Discuss book in the Saloon — More info at Amazon.com


Ant in Action
by Steve Loughran, Erik Hatcher


Manning Publications
second edition
July 2007
600 pages
Reviewed by Jeanne Boyarsky, April 2008
  (8 of 10)


"Ant in Action" is really the second edition of "Java Development in Ant." I think the original title was more descriptive as the book focuses more on process, tools and techniques than most Ant books. For example, they introduce continuous integration and why you would want to write unit tests. Not that the Ant coverage isn't good -- it's excellent -- just that the book is so much more.

Like most Ant books the authors don't rehash the excellent online manual and API. For those new to Ant, features are clearly described with good examples and good descriptions of "what happens if _____." The flow diagrams helped visualize concepts nicely.

For those who have been using Ant, there are margin notes about what was added in 1.6/1.7 along with coverage of Ivy. I liked the Java 6/JEE 5 examples. The techniques for writing reusable/maintainable code and extending Ant provided significant value. I was a little disappointed it used JUnit 3.8. The authors explained why and I understand. I still would have liked to see it as this book will still be used when JUnit 4 is in wider use.

Coverage of related tools is also useful. It's good to know what libraries to look into to increase productivity with Ant. I've been using Ant for complex builds for three years and still had a page of take away points from this book. I recommend it for the valuable information and techniques.

Discuss book in the Saloon — More info at Amazon.com


Manning Publications
second edition
July 2007
600 pages
Reviewed by Janeice DelVecchio, September 2010
  (8 of 10)


I have to admit, as someone with knowledge of core Java alone and no prior knowledge of build tools, I was overwhelmed by the table of contents of this book. Once I started reading, I realized there was no reason to worry.

Each step of the setup and use of Ant is described in the first couple chapters of the book. There is an appendix for people (like me) who need a little more help starting up. The build file creation process is broken down and built upon over time. I found the examples helpful and the layout of the book intuitive.

The later chapters of Ant in Action go into way more complex things like larger projects, Ant tasks, integrating Ant into Java projects, and enterprise applications. This is a book I expect to use now and grow into later. I am especially excited about the section on working with XML, and adding in optional tasks.

I would not recommend this book to anyone who has less than a solid understanding of core Java and some awareness of XML. There is an XML primer in an appendix which is pretty helpful if you don't know XML.


Disclosure: I received a copy of this book from the publisher in exchange for writing this review on behalf of JavaRanch.

Discuss book in the Saloon — More info at Amazon.com


Software Architecture for Developers
by Simon Brown


Leanpub
digital (no isbn available at this time) edition
January 9, 2014
242 pages
Reviewed by Junilu Lacar, January 2014
  (10 of 10)



If I were to draw an analogy, Simon Brown's new book (#sa4d) is to software architecture as Robert Fulgham's "Everything I Need to Know I Learned in Kindergarten" is to self-improvement. If you're looking for things like architectural patterns, templates, and step-by-step guides, look somewhere else. The value of this book is in the ideas that Simon shares on how to think about architecture ("architecture is a role, not a rank"), and organize your work so that you can effectively communicate your software's architecture. Simon recommends a lightweight approach that aligns well with agile practices and the book is a great reminder that agility is not only about process management. Another thought from the book that really gets you thinking: "Software architects should code." On the practical side, Parts V and VIII of the book give a wonderful template and example of supplemental product documentation in the form of a Software Guidebook. This supports Simon's assertion that "the code doesn't tell the whole story."

For those aspiring to become well-rounded software architects, this book reminds us that there is more to architecture than just technology. It makes us step back from the trees of technical details and take a good look at the vast expanse of the software architecture forest. Highly recommended reading.

---
Disclosure: I received a copy of this book from the publisher in exchange for writing this review on behalf of CodeRanch.

Discuss book in the Saloon — More info at Amazon.com


Java Design: Objects, UML, and Process
by Kirk Knoernschild


Pearson Education
1 edition
December 2001
257 pages
Reviewed by Junilu Lacar, May 2002
  (4 of 10)


At first glance, this book looks promising. It has all the right stuff listed in the table of contents: general principles of object-oriented design, patterns, refactoring, incremental development, UML, RUP, and even XP. Don't be fooled though because the actual discussion is introductory at best with an almost incidental treatment of Java and how it ties in with the UML, modeling, designing, and creating what the author likes to call a "resilient architecture."

While the book discusses a lot of things that you should know about OO design, UML and iterative development processes, it lacks the focus and depth needed for it to be truly useful. The discussion on UML and design revolves mainly around two use cases and there are very few other examples. Most of the time the author is introducing a new concept and constantly referring to other parts of the book where it will be or has been discussed in detail. However, when I got to the end of the book I was still expecting more detailed discussions and had to go back to see what I missed.

You'll probably get more bang for your buck with Martin Fowler's books on UML and refactoring and Craig Larman's book on UML, patterns and the Unified Process. These books are filled with the examples that "Java Design" sorely lacks. For OO design principles, read the articles by Bob Martin published on http://www.objectmentor.com.

Discuss book in the Saloon — More info at Amazon.com


Agile Software Development: Principles, Patterns, and Practices
by Robert C. Martin with contributions by James W. Newkirk and Robert S. Koss


Prentice Hall
1 edition
October 2002
529 pages
Reviewed by John Wetherbie, January 2003
  (9 of 10)


Agile Software Development is a great Object-Oriented Design book that presents it's subject in the context of Agile Development. The book delivers solid design and programming advice in a very "light" style. Not light in that it avoids technical detail! No, Bob seems to have taken the principles of agile development and applied them to the art of technical book writing.

The book is divided into six sections and has four appendices. There are many UML diagrams and lots of code examples in C++ and Java. If you don't know UML two of the appendices will introduce you to it. The book takes a top down approach. You are first given a quick overview of agile development practices. I particularly liked the Testing and A Programming Episode chapters from this section. The second section presents five high-level design principles that every developer should learn and apply.

Case studies dealing with a payroll system, weather station software, and testing software are then presented. Each case study section starts by discussing the design patterns that will seen in the case study. Section Four discusses subdividing the payroll system into packages. Six principles and a set of package Dependency Management metrics are covered. The book wraps up with the two UML appendices mentioned above, a comparison of two imaginary developments, and an interesting article by Jack Reeves.

In my opinion Agile Software Development Principles, Patterns, and Practices is the best OOD book out there.

Discuss book in the Saloon — More info at Amazon.com


Software Fundamentals: Collected Papers by David L. Parnas
by Edited by David M. Weiss and Daniel M. Hoffman


Addison-Wesley Professional
1 edition
April 2001
688 pages
Reviewed by Jessica Sant, June 2003
  (9 of 10)


Anyone who considers themself a Java developer should know who Dave Parnas is. Without the insight of Dave Parnas in the 60s and 70s there would be no such thing as the Java programming language. Ever heard of information hiding (the basis for all Object Oriented programming)? Yeah, Parnas came up with that. Exception Handling? That's him too. Interfaces? Parnas. (Get the idea?)

This book reprints 33 of Parnas' most influential papers. Each paper is started off with an introduction from one of Parnas' peers (like Barry Boehm), giving the paper a connection to the modern state of Software Engineering, and trying to give the reader an understanding of just how seminal the particular paper was to the world of Computer Science and Software Engineering.

I believe you become a much better programmer if you understand where things come from. Once you understand how things were before "Information Hiding" came about, you get a better appreciation for why its such a necessary and important practice. You'll become a better programmer because you're more aware of what would happen if you didn't have exception handling. And you'll be come a better writer when you understand why buzzwords can be so dangerous in technical papers.

Dave Parnas has been a huge influence over the world of Software Engineering. Everyone should have the chance to read his work.

Discuss book in the Saloon — More info at Amazon.com


Enterprise Services Architecture
by Dan Woods


O'Reilly
1 edition
September 2003
223 pages
Reviewed by Ajith Kallambella, December 2003
  (6 of 10)


In the second book in the series between O'Reilly and SAP, author Dan Woods takes the reader through an interesting tour of Enterprise Services Architecture and the evolution of WebServices(WS). He makes a business case for applying WS in the enterprise and argues that despite slow standardization and lack of broader vendor support, WS strategy will surely benefit early adapters.

For starters get this - The concept of Web Services was actually conceived by SAP! Woods shares the historical perspective and speaks about implementing the very first SOA based applications while working at SAP. The thin UI layer of MySAP.com uses a services layer to communicate with loosely coupled components and data services.

This book is aimed at senior management and IT professionals involved in building software solutions for the ever-changing enterprise landscape. This is a book about the philosophical, ideological and evolutionary significance of SOA. In the section titled Making a business case for the use of SOA, Woods looks at Ent.Web Services through the eyes of a consultant, an analyst, a venture capitalist and finally a system integrator, and quotes from the very best industry experts in each of these domains. Beyond the trenches of IT shops, in what Woods describes as Part Engineering discipline and part Computer Science applied to practical business problems, he hypothesizes that pervasive use of Web services will ultimately result in an incremental improvement towards a more efficient society. Efficiency will primarily apply to reduce annoyances of everyday life such as filing for taxes, setting up health insurance or getting a driver s license. Freed up human capital will cumulatively help build efficient, elegant and practical living conditions for all.

Discuss book in the Saloon — More info at Amazon.com


Succeeding with Use Cases: Working Smart to Deliver Quality
by Richard Denney


Addison-Wesley Professional
1 edition
May 2005
336 pages
Reviewed by Jeanne Boyarsky, August 2005
  (8 of 10)


"Succeeding with Use Cases : Working Smart to Deliver Quality" walks you through four quality engineering disciplines: quality function deployment, software reliability engineering, model based specification and use case configuration management. Most of the book is readable by project managers, while model based specification (pre conditions, post conditions and invariants) is of special interest to developers and testers.

As you can guess, the book assumes you already know about use cases. For the most part, the authors are good about going into detail without making any further assumptions of your background. Examples include concrete numbers and the diagrams are excellent. Once chapter does get theoretical and use algebra, but it is immediately followed by a practical application.

Personally, I found the reasoning and walkthrough of the ROI example to be most valuable. The book does read like a short textbook and academics are explicitly mentioned as one of the target audiences. However, you can tell the book is written by someone who has been through it personally. Overall, I found the book to be a valuable read.

Discuss book in the Saloon — More info at Amazon.com


Emergent Design: The Evolutionary Nature of Professional Software Development
by Scott L. Bain


Addison-Wesley
1 edition
March 2008
448 pages
Reviewed by Ulf Dittmer, May 2008
  (9 of 10)


The author states in the preface that he'd like to push software development as a profession forward by promoting a set of methodologies that are universally recognized as beneficial. This reviewer thinks he achieves this goal admirably and wishes he had had access to a book like this when he first started out with object-oriented software development professionally.

A number of what might be called best practices are examined as to why they're useful, how they might best be applied, and how they deliver value in conjunction with other best practices. Some of these are well-covered by now (e.g. coding style and patterns), others are somewhat newer (like refactoring, the open-closed principle, unit tests and test driven development). At each step the author uses a combination of concrete code (mostly in Java, but easily understandable to everyone) and abstract UML-style diagrams to illustrate what is happening, and what difference a particular technique makes.

One important recurring theme is that the waterfall model of software development is truly dead, and that change of all kind needs to be embraced in a project, especially including changing requirements. Every software professional will recognize the value of being able to cope with change, and in this book that's part of the core message at each step. I recommend the book to get fresh perspectives and new ideas about various parts of the development process, both for developers and managers.

Discuss book in the Saloon — More info at Amazon.com


Documenting Software Architectures: Views and Beyond (2nd Edition)
by Paul Clements, Felix Bachmann, Len Bass, David Garlan, James Ivers, Reed Little, Paulo Merson, Paulo Merson, Robert Nord, Judith Stafford


Addison Wesley
second edition
October 2010
592 pages
Reviewed by Wouter Oet, November 2010
  (7 of 10)



This book tries to provide a guidance on how to make your architecture understandable through documentation.

The book is very complete, all the information you would expect to find is in it. But I feel that the authors took it too far. The amount of information can be overwhelming especially because it is spread over large pieces of text. The book can be hard to read because the language is very technical and the writing style isn't very entertaining. Luckily, the authors included a readers guide (advising you on which chapters to read depending on your background).

The content of the book is good. It contains lots of quotes, sideline hints/tips and perspectives which are very useful. Also the usage of diagrams and examples make it much more understandable. The summaries, questions and references at the end of each chapter are a great addition.

"Documenting Software Architectures" is very complete which makes it ideal as a reference book. It is not for the faint-hearted/beginners but is an addition to each architects bookshelf.

---
Disclosure: I received a copy of this book from the publisher in exchange for writing this review on behalf of CodeRanch.

Discuss book in the Saloon — More info at Amazon.com


100 SOA Questions: Asked and Answered
by Kerrie Holley, Ali Arsanjani


Prentice Hall
1 edition
November 2010
272 pages
Reviewed by Deepak Bala, December 2010
  (4 of 10)



Before we even dive into the review, I thought it would be useful to mention the target audience for this book. The authors recommend that technologists / business stakeholders / architects would benefit from this book. It is not a technology book.

The expectation I had when I started reading this book was that it would give me clear / concise answers to specific problems / scenarios that one encounters in the SOA world. Unfortunately I found the answers to be wayward and not to the point. So what did I dislike about this book ?

1. The authors are undecided about the technical mastery that is required to read this book. For example, a mini tutorial on REST is provided abruptly while answering a question. I would expect an architect or technologist to know what REST is.
2. The answers are very abstract. So abstract that their meaning could be interpreted in a myriad of ways.
3. Some assumptions that are made about the architecture of a target system (the presence of pre-packaged software for example) are not necessarily true for all enterprise systems.
4. The book recommends that you visit the web site www.100Questions.info to have any other questions that you have answered. At the time of this writing, the website is simply a blank page that has been parked by godaddy. Very disappointing.

As for what I liked about the book, you can traverse to any question you want and have it answered. The questions are not necessarily linked to each other in any way. So you can read a question about architecture and then jump to say governance without any problem.

Overall, I did not derive enough value from reading this book.

---
Disclosure: I received a copy of this book from the publisher in exchange for writing this review on behalf of CodeRanch.

Discuss book in the Saloon — More info at Amazon.com


Prentice Hall
1 edition
November 2010
272 pages
Reviewed by Ulf Dittmer, January 2011
  (4 of 10)


"SOA is a paradigm shift." (Q60) that "will forever be entrenched as a best practice" (Q94), and which is an evolution beyond OOP and Agile methodologies (Q38). These are the basic premises of this book, and anyone not buying into them will have trouble getting value out of reading it. The book seems out of a time a few years back when the SOA and web service hypes were at their peak; now that the hype has subsided, and the world has, by and large, recognized SOA as not being a game-changer but just another tool of the trade, and moved beyond large parts of the SOAP ecosystem, it feels strangely out of place.

The authors work, respectively, for IBM -one of the largest pushers of SOA infrastructure software- and a consulting company that specializes in introducing SOA in companies (something that the book advocates, Q48), so maybe this is to be expected. The book emphasizes big enterprise topics and assumes that a remodeling of the software and IT infrastructure (like putting in place ESB and BPM) need to be part of the overall SOA effort. No effort is made to present or justify SOA in environments that are not prepared to make that effort.

The 100 questions and answers are bundled into related categories like architecture, governance, organization that can be read individually as needed. That's a nice touch, as not all material will be of interest to all readers, or at all times, so chapters can be read on an as-needed basis. The presentation itself is clear, and aided by numerous diagrams that help illustrate the main points.

---
Disclosure: I received a copy of this book from the publisher in exchange for writing this review on behalf of CodeRanch.

Discuss book in the Saloon — More info at Amazon.com
 
The Bunkhouse administrator is Ankit Garg.