Archive for the 'books' Category

Here's another short book (195 pages) that cannot be missing from a good software engineer's personal library. Robert L. Glass condenses in 55 facts and 10 fallacies — some of them well known, others more controversial — his vast knowledge of the field.

The 55 facts are subdivided into four main sections:

1. About management
2. About the Life Cycle
3. About Quality
4. About Research

The ten fallacies are instead grouped as follows:

1. About Management
2. About the Life Cycle
3. About Education

This organization could provide a hint as to what sections of the book you'd better read first if you are managing programmers rather than if you're more involved in coding. But in any case, I suggest that whatever your positions, you will be better served by reading it all.

Glass, a member of the “old guard” of software engineering, having been a practitioner of the field since its very beginnings, is a bit wary of espousing the latest trends in software, like eXtreme Programming. Some of his facts and fallacies fly right in the face of some XP principles and practices. See for instance fallacy nr. 3:

Programming can and should be egoless.

How can you reconcile this with collective code ownership and pair programming?. In other instances, he shares some of XP's convictions. See for instance fact 28:

Design is a complex, iterative process. Initial design solutions are usually wrong and certainly not optimal.

In the end, no matter what development process you like best, you're bound to find some controversial statements inside this book. If this makes you think about what you're doing and how successful you're being at it, I think the book will have fulfilled its purpose. By being apparently dogmatic in its format (what sounds more dogmatic than a list of asserted “facts”?) Glass manages to teach us that what you should be avoiding mostly is indeed dogma. In the current climate, dogma typically takes the form of a new development methodology that promises to end all debates on methodology. To fight this, everyone should memorize fallacy 5:

Software needs more methodologies.

Highly recommended!

Facts and Fallacies of Software Engineering by Robert L. Glass, Addison-Wesley Professional; 1st edition (October 28, 2002), ISBN: 0321117425

User Stories Applied : For Agile Software Development (Addison-Wesley Signature Series)
by Mike Cohn

Writing user stories is one of the twelve practices of the XP software development methodology. User stories summarily describe features of the software that must be developed, from the point of view of the user. This means that no implementation detail is present on stories.

As with all the XP practices, the emphasis is on traveling light, producing only those artifacts that are absolutely necessary. Thus, user stories contain a brief description of the feature as a reminder, to the developers and to the customer, that sometime in the future they will need to meet and flesh out the details. This is in contrast to techniques like use cases, which might seem similar but are much more formal and rich.

User stories also play a fundamental role in the planning game, one of the other XP practices. During the planning game, the development team and the customer together discuss the stories, the developers estimate the time necessary to implement each story, in terms of story points and the customer prioritizes them. During the next iteration, developers will implement those stories that the customer deemed more urgent, up to a number whose total sum of points does not exceed the estimated team velocity.

All of this is explained in a couple of the XP series books, namely Extreme Programming Explained: Embrace Change and Planning Extreme Programming You'd better have already read at least the former of those before picking up Mike Cohn's book.

User Stories Applied does a good job explaining in detail what user stories are, what goes into them —and what doesn't —, how they should be estimated and what to do with them after the stories have been implemented.

There's a lot of good sense advice in this book, which might induce someone to think that user stories and all other XP practices are just a bunch of generic suggestions that you might apply or not, as you wish. That's certainly not true, as XP is a methodology whose effectiveness lies in the combined action of all the practices when they are taken to the limit. This takes determination and discipline and, in my experience, it's just too easy to fall into the habit of following only some of them, say when you're not under deadline pressure, and still pretend that you're an XP shop.

I would have liked more real-life stories in this book, in order to spice it up a little. As it is, everything that is there sounds highly reasonable (at least to me) but it wouldn't convince anyone who is skeptic of XP's supposed benefits. The example at the end of the book sounds contrived and hollow.

On the other hand, if you have been already convinced by Kent Beck's white book and want to start adopting XP, I can heartily recommend Mike Cohn's book. Recommended!.