The following are the books, etc., found in the references section of A Practical Guide to Feature-Driven Development (APGTFDD). They are listed here for the convenience of those wanting to read further on a particular related subject. Where a later edition of a particular book exists I have listed that instead of the precise one listed in APGTFDD. I have also added one or two that would have been in the reference list if they had actually been published at the time. While I would recommend most of the books below, that is not true of all of them; some are simply books I referred to for one reason or another when writing APGTFDD. Hopefully, the distinction between the two is clear below.
A number of the books in the list were recommended to the team on the first Feature-Driven Development (FDD) project in Singapore by FDD's creator, Jeff De Luca. These were obviously influential in the development of FDD and as a result ended up being referenced in APGTFDD, and have found a place on my bookshelf. Others I'd met already or read during my time at TogetherSoft.
The list is organised into the following categories ...
- Analysis and Design Patterns
- People and Process
- Extreme Programming
- UML and Use Cases
- Quality and Inspections
...but clicking on the reference tag used in A Practical Guide...immediately below will take you to the relevant book
[Alexander] [Alur][Atels] [Beck 00] [Beck 01] [Berg] [Brooks] [Coad 96] [Coad 97] [Coad 99] [Crosby] [Cusumano] [De Marco] [Dobbs] [E & Y] [Fagan] [Fairley] [Fowler][ Freedman] [Gamma] [Gilb 88] [Gilb 93] [Hohmann] [Jacobson 92] [Jacobson 99] [Jones ][Kassem] [McConnell 93] [McConnell 98] [Miller] [ODR] [Palmer] [Paramount Picture Corporation] [Rosenberg] [Satir] [Tennyson] [Tolkien] [Tufte] [Weinberg 92] [Weinberg 98]
Christopher Alexander's work on patterns is commonly referred to from books and papers on software analysis and design patterns. This must astonish him because he was talking about patterns in buildings and towns, not software. He says, 'Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of solution to that problem, in such a way that you can use this solution a million times over without ever doing it the same way twice".
A guide to the most popular and useful architectural design patterns for the J2EE world. As Martin Fowler says in his foreword, "This book captures vital experience for J2EE development. Don't build an enterprise bean without it". The book presents 21 patterns organised by tier (logical layer): presentation, business and integration.
Book site: www.corej2eepatterns.com
The design patterns described in this book by the Gang of Four (GoF), the popular name for the four authors, have almost become part of software design folklore. This book brought the idea of software design patterns into mainstream software development. The book has two small disadvantages. Published in 1995 before the emergence of UML, the notation used in the book is based on the obsolete OMT notation, and many of the examples relate to building Graphical User Interface toolkits and Word Processing software, not the sort of software the average developer has the opportunity to design. Nevertheless, it is the original that spawned a library's worth of software pattern books, conference papers and web sites.
Patterns of Enterprise Application Architecture
Martin Fowler doing what he has become renowned for, cataloging and presenting patterns and best practice, the stuff as a developer you really should already know, in an accessible and readable way. There are 51 design patterns from both Java and .Net worlds, covering various topics from the almost ubiquitous money and value object patterns to the more complicated Data Mapper patterns used to 'move data between objects and a database while keeping them independent of each other and the mapper itself'. Published in 2003, it is a great starting point for anyone wanting to explore the design patterns commonly used when building business applications.
Book site: martinfowler.com
The material in the book builds on work described in Peter Coad's previous books and was inspired by work done with Peter on a project in Singapore where co-author Jeff De Luca was the project manager and I was the development manager. Those who have spent the small amount of time required to really understand and try out the modelling in colour technique generally find it very powerful and helpful.
This book uses a number of simple example applications to introduce a set of strategies and patterns for building object models. This is followed by a reference section that lists the strategies and patterns discussed. Possibly due to my level of experience at the time with object modeling I had to frequently put this book down to think through the points raised. It took me several readings to fully absorb all the content. I have returned to this book again and again over the years because of the richness of the content.
The book consists of three hundred pages split into fifteen essays that formed the original edition published in 1975 plus four new chapters that add the 1986, 'No Silver Bullet' essay and three retrospective chapters. What is so disappointing about this book is that so few of the lessons have been genuinely absorbed by the industry thirty years later.
A very interesting and thought provoking look at software development from a psychological and sociological perspective.
The premise behind the book is "The major problems of our work are not so much technological as sociological in nature".
A series of four books on effective software development management. Jeff De Luca says (www.featuredrivendevelopment..com), "Anything written by Weinberg is worth reading". These four books are certainly no exception. 'Quality software management" means both "the management of quality software" and "quality management in the software business"...the two are inseparable'.
Author site: www.geraldmweinberg.com
I have not read this book. I caught the quote I use in APGTFDD in an article on the internet. It fitted with what I was trying to say and reinforced techniques that I'd watched Jeff De Luca use when hiring for the original FDD project in Singapore, and have used myself since; the ability and desire to solve problems and learn being crucial to a candidates success rather than knowing a set of specific answers.
Used in APGTFDD to underline the fact that psychology is plays an enormous part in software development projects. The first edition of book was written in 1971 so much of the technology referred to is obsolete but the psychological principles remain true.
Author site: www.geraldmweinberg.com
Like [Alexander] in the patterns community, this work is referred to by everyone writing about managing change in software development from [DeMarco] to [Weinberg] but it has nothing whatsoever to do with software development per se.
In the end, it's all about the people not the technology.
Extreme programming became popular about the same time as FDD and generated far more hype. Worth reading to compare and contrast with FDD but having tried both processes on real projects, I have found pair programming to be no substitutefor the design and code inspections used in FDD.
In fact, both of the so-called XP projects I have worked on dropped constant pair programming after a while because it was not providing the benefits claimed. Also in both cases, collective ownership slowly deteriorate into individual ownership. Without either practice in place, both projects were left bereft of any form of checks for design and code quality and suffered as a result.
I bought this book to read on a plane trip across the USA but finished it well before we 'started our descent'. The only real points of interest to me were the definitions of a user story that had evolved since the first edition of Extreme Programming Explained, and a smile of recognition while reading the section about asking developers what percentage complete they are on a task.
Mike Cohn has written a much more thorough treatment of the topic. Unless you are one of those people who must have the complete Addison Wesley Extreme Programming series, buy [Cohn] instead.
Referenced purely because it is the sister book to A Practical Guide to Feature Driven Development written as part of Prentice Hall PTR's Coad Series by colleagues at TogetherSoft in 2001. I have not read this book because I am still waiting for one of the authors to send me a signed copy in return for me sending them a signed copy of APGTFDD.
The other intended companion book, A Practical Guide to the Unified Process, never made it to publication. I would like to think the authors succumbed to analysis paralysis while writing detailed use case specifications but I doubt that was the real reason.
As Jim High smith says in his foreword, "Agile planning is deceptive". This book leaves you in no doubt that agile approaches require planning and that the planning techniques used are sometimes, "easier said than done".
Determining the business value and estimating the size of a user story, backlog item, or feature is not necessarily easy. Expecting a customer to simply walk into a meeting and reel off lists of users stories and backlog items without any preparation is also unrealistic. Agile planning requires work and discipline.
Author site: www.mountaingoatsoftware.com
The first edition of this book was published in 1996, and was my first Peter Coad book. I read it in a single weekend. I could not put it down. So much of it spoke directly into my situation as a lead developer on my first Java project. Having battled through the usual texts trying to learn to think and program in an object-oriented way with C++ for the previous two years, this book was simply a pleasure to read.
Unfortunately, Java has moved on considerably since the second edition was published and there has been no third edition. The design principles remain valid but the majority of the detail is very out of date.
Cliff Berg was the Java Language Guru on the project in Singapore where I worked on with Jeff De Luca, and Peter Coad. A little of the work was also outsourced to the company he worked for at the time, DigitalFocus, who were used as an example in APGTFDD when discussing attracting good developers to an organisation.
Although this is a second edition, the content is now out of date. Cliff has written a more recent book called High-Assurance Design and is founder and president of Assured By Design (www.aasuredbydesign.com).
Now in it's third edition, this is still one of the best introductions to the Unified Modeling Language (UML), the most widely used graphical notation standard for depicting software design.
If you are new to UML then this book will teach you all you need to know to use UML effectively in half the pages required by most other texts on the topic.
Author site: martinfowler.com
I have not had good experiences with use cases. That does not mean I think they are without value. Since use cases are as much an expression of requirements as the user stories, backlog items, and features of popular agile approaches, they could be used in a highly iterative software development approach.
The problem is they are so often used as a straight replacement for a traditional functional specification.
Most of my bad experience stems from use case details being written by the wrong people, at the wrong time, and inevitably containing the wrong kinds of information.
This book contains a wealth of sensible advice for those seeking to be successful with use cases.
The original book on use cases and use case driven development.
The book is really only of interest from a historical perspective now and superseded by the author's more recent book [Jacobson 99]. Personally, for use cases I prefer [Miller] for which Ivar Jacobson wrote the foreword.
The official guide to the Unified Process from the three authors of the Unified Modeling Language (UML). Published in 1999.
While I have used use-case driven processes in the past, my only specific experiences with UP, as presented in its commercial form as IBM RUP (IBM Rational Unified Process), have not been positive experiences.
One of my co-author's references. Now superseded by Use Case Driven Object Modeling with UML: Theory and Practice
One of those books that every trainee developer and IT graduate should be forced to read. In an ideal world, if you didn't know this stuff, you would have no right to call yourself a software developer and would not be allowed anywhere near a programmer's editor and compiler.
A definitive work on software inspections. Probably more than you ever to know about the subject. If you read this and are still not persuaded that some sort of peer review or inspection is a good idea, I doubt anything else will convince you.
One of my co-author's references. I have not read this book.
My software engineering course text book from the dim, distant past when I was a student at Keele.
This is mainly an excellent, if somewhat dry, description of state of the art, phased (waterfall) development circa 1985, but even then Fariley notes the need for managers to deal with 'the factors that motivate and frustrate programmers'.
Cliff Berg was the Java Language Guru on the project in Singapore that I worked on with Jeff De Luca, and Peter Coad. He has written a number of articles for the DR Dobbs magazine/web site. To find them go to www.ddj.com and search for 'Cliff Berg'
The old TogetherSoft monthly technical newsletter that I edited (and largely authored) for nearly two years. See The CoadLetter.
Not one of the best Star Trek movies (not as bad as the 'The Final Frontier' or 'Generations' though). Scotty's quip about always multiplying his estimates by four to maintain his reputation as a miracle worker reminds me of developers who tell me they always double their original estimates because they know their managers will insist on halving them.
I studied this at school in English Literature. I had it as the wallpaper for my computer screen during the one project I have worked on that has failed to deliver. However, it seems even more appropriate for development teams who use agile as an excuse to dive into producing coding without any thought about design, quality, or documentation.