Product Description

For courses in Advanced Software Engineering or Object-Oriented Design. This book covers the human and organizational dimension of the software improvement process and software project management -- whether based on the CMM or ISO 9000 or the Rational Unified Process. Drawn from a decade of research, it emphasizes common-sense practices. Its principles are general but concrete; every pattern is its own built-in example. Historical supporting material from other disciplines is provided. Though even pattern experts will appreciate the depth and currency of the material, it is self-contained and well-suited for the layperson.

Product Details

• Amazon Sales Rank: #377106 in Books
• Published on: 2004-07-26
• Original language: English
• Number of items: 1
• Binding: Paperback
• 432 pages

From the Back Cover
See what reviewers at Slashdot.org originally had to say about James and Neil's book!

"This is a remarkably wise book, full of pragmatic advice drawn from real projects. Ultimately, software development is a human experience, and Jim and Neil have captured the essence of that experience in this work. The tapestry of patterns they have woven is postively brillant, and each thread therein is a delight to read."

--Grady Booch, IBM Fellow

Do you want to really improve your software development organization instead of complying with an arbitrary standard, or trying the latest fad? This book presents the fundamentals of creating sustainable organizations, based on in-depth studies of over 100 real software development organizations.

The authors present nearly 100 organizational patterns to help you create a highly effective organization. Case studies and vignettes illustrate how these patterns work. This practical guide shows you how to reshape critical parts of your organization. Regardless of your role, you will find patterns that you can use to make your organization more effective.

"This carefully researched, artfully described, and extraordinarily useful handbook of deep wisdom on creating teams that generate terrific software should be on every software development manager's bookshelf."

--Luke Hohmann, Hohmann Consulting
Author of Beyond Software Architecture

"As soon as I had worked through these patterns, I realized that several of my clients engaged in process definition projects could make use of them."

--Ian Graham, Technical Director, trireme.com

Excerpt. © Reprinted by permission. All rights reserved.
Developer Controls Process ... an organization has come together to build software for a new market in an immature domain or in a domain that is unfamiliar to the development team. Progress will be marked by an INFORMAL LABOR PLAN (4.1.14). The necessary roles have been defined and initially staffed.

A development culture, like any culture, can benefit from recognizing a focal point of project direction and communication. Successful organizations work in an organic way with a minimum of centralized control. Yet important points of focus, embodied in roles, tie together ideas, requirements, and constraints into an artifact ready for testing, packaging, marketing, and delivery.

Strict control is viewed by most development teams as a draconian measure. The right information must flow through the right roles. You need to support information flow across analysis, design, and implementation.

Because developers contribute directly to the end-user-visible artifact, they are in the best position to take accountability for the product. Of all roles, they have the largest stake in the control. The manager has some accountability as well, to the extent that he or she indirectly supports delivery of the user-visible artifacts. These are process issues.

Therefore:

Make the Developer the focal point of process information. In the spirit of ORGANIZATION FOLLOWS MARKET (5.1.9) place the developer role at a hub of the process for a given feature. A feature is a unit of system functionality (implemented largely in software) that can be separately marketed, and for which customers are willing to pay. Responsibilities of developers include understanding requirements, reviewing the solution structure and algorithm with peers, building the implementation, and performing unit testing.

Note that other hubs, such as a manager role, may exist as well, though they are less central than the Developer role.

The Developer who is at the hub of a particular feature may be accorded that position according to FEATURE ASSIGNMENT (5.2.14), but, more generally developers should be at the communication hub of whatever process engages them in writing code for the customer. This pattern moved toward the center of the process using the patterns WORK FLOWS INWARD (4.1.18) and MOVE RESPONSIBILITIES (5.1.18). Though Developer should be a key role, care must be taken not to overburden that role. This pattern should be balanced with MERCENARY ANALYST (4.1.24), FIREWALLS (4.2.9), GATEKEEPER (4.2.10), and more general load-balancing patterns like RESPONSIBILITIES ENGAGE (5.1.14), HALLWAY CHATTER (5.1.15), and MOVE RESPONSIBILITIES(5.1.18). The Developer should enjoy particularly strong support from the PATRON ROLE (4.2.15), and conflicts can be escalated to the PATRON ROLE when consensus breaks down.

If the Developer controls the process, then it’s possible to implement the pattern WORK FLOWS INWARD (4.1.18). Developers, of course, don’t control the process unilaterally, but as a collective group, starting with DEVELOPING IN PAIRS (4.2.28).

We have no role called Designer because design is really the whole task. Managers fill a supporting role; empirically, they are rarely seen to control a process except during crises. While the Developer controls the process, the Architect controls the product. [In the figure, the Architect role is split across Framework Owner and ARCHITECTURE TEAM (5.2.4). This communication is particularly important in domains that are not well understood, so that iteration can take place to explore the domain with the customer.

In a mature domain, consider HUB SPOKE AND RIM (5.1.17) as an alternative.

You can still write down your process as part of a process improvement program. But keep the documentation light; many organizations have found that one page per process is good enough. And make sure each process step meets a need that you can tie to your organization’s value proposition. Most often, this value is or should be tied to the product you are producing for a paying customer. If it isn’t obvious how the process step helps to achieve what you know the customer wants, the do the right thing instead.

Customer Reviews

Best organisational patterns
This is the best book on patterns since the publication of Alexander's A Pattern Language. The book offers four pattern languages containing over 100 patterns that show you how to design, grow, shape and improve an organisation. The patterns are dense, full of insights, wisdom and knowledge; they are based on the authors' more than a decade of research and experience. Many of the patterns are timeless, such as CommunityOfTrust, ConwaysLaw and NamedStableBases. Some patterns are really beautiful, such as WorkFlowsInward, ArchitectAlsoImplements and FormFollowsFunction. Although the book is about organisational patterns, I have found it valuable for anyone who is interested in patterns or wishes to learn about patterns.

Finally
This rare jewel is a practical guide to the deeper secrets and relationships of software development.

It is however based on "true Science", since it was originally based on extensions to Moreno's sociometric techniques, although it reads like literature -- it is art.

To the lucky ones that read it, understand it, and practice it, it will provide, undoubtedly, the passage to a higher level of understanding of how people work, and work best, when doing software devleopment.

Although "agile development" pehaps was first practiced by LISP programmers in the 1960's, Organizational Patterns is perhaps the first documentation that ever existed on true Agile development. No one, to my knowledge, had done so before. (Not Scrum, which started in 1993, nor XP which started much later. etc.)

To the interested readers I only have one simple advice: read every single page -- twice!!, and practice the patterns, many times!!!

Outstanding book about sociology in software development
OK, I have to admit, this is the first book review I've ever written on Amazon and having read a lot of good books I should probably get off my a** and write more :-)

As a former developer and now a software development manager, I have come to realise that the "soft side" or sociology of software projects (communication with clients, communication with teammates, project management, team dynamics, cultural issues, morale, division of work, remote collaboration, etc) is considerably more complicated than the programming work itself.

Over time, you start to see patterns emerge such as "start a large project with a small experienced group and gradually phase people into a project as time goes on". This book does by far the best job of cataloguing and explaining dozens of these patterns related to (1) software project management (2) structuring, building and nurturing software project teams and (3) organization and division of development tasks to maximize the effectiveness of the team as a whole.

Highly recommended to anyone involved with software development at both the management level and in the trenches. Have fun!