Software Modifiability Tactics

Getting back to the subject of my previous blog-entries on Software Architecture Views and Perspectives and Software Architecture Quality Attributes, I wanted to talk more specifically about the quality attribute of Modifiability.

The Modifiability of a software system is related to how minimal is the cost/effort to develop and deploy changes to the software. This relates to well known concepts and principles of coupling, cohesion, maintainability, etc. and is the basis for many of the elements of object-oriented, component-based, and aspect-oriented design ("reuse" is a close cousin for all these as well).

Software Modifiability Tactics are presented in section 5.3 of Software Architecture in Practice. A taxonomy is given which relates architectural tactics to architectural patterns ("styles") and the design patterns which are largely concerned with achieving the attribute (in this case "modifiability") for various types of products and contexts. The article Understanding Architectural Patterns in Terms of Tactics and Models even has a nice matrix that maps architectural patterns or styles to the various kinds of modifiability tactics.

The taxonomy for software modifiability tactics is broken down as follows:

• Localize Changes (increase cohesion)
  
• Maintain Semantic Coherence
  
• Anticipate Expected [types of] Changes
  
• Generalize the Module
  
• Limit Possible Options
  
• Abstract Common Services


• Prevent Ripple Effects (reduce coupling)
• Hide Information
  
• Maintain Existing Interfaces
• Restrict Communication Paths
• Use an Intermediary


• Defer Binding-time (defer decision-making)
• Run-time Registration
  
• Configuration Files
  
• Polymorphism/Delegation
  
• Component Replacement
  
• Adhere to Defined Protocols

In September 2007, an SEI Technical Report on Software Modifiability Tactics was published that provides a comprehensive discussion of these modifiability tactics and the architecture/design patterns that can be used to implement them (and some of the tradeoffs involved).

Links and Resources on Software Modifiability Tactics:

• Modifiability Tactics, Chapter 5 section 3 of Software Architecture in Practice
• Understanding Architectural Patterns in Terms of Tactics and Models
• Modifiability Tactics, SEI @ CMU Technical Report CMU/SEI-2007-TR-002
• Design and Tactics, Lecture notes from an Aalborg University course on Database and Software Architecture

In a subsequent blog-entry I will muse about how Modifiability relates to Agility in both software architecture/design and in software process architecture/design.

Distributed Version Control Systems

A colleague of mine had a question for me about Distributed Versions Control Systems (or DVCS). There are a growing number of such systems these days: Mercurial, Bazaar, git, svk, BitKeeper, Gnu Arch, darcs, Monotone, Codeville, Arx, just to name a few. I referred them to a good essay by David Wheeler that talks about the fundamental differences between distributed vs centralized VCS (among other things).

I also Googled on the topic and came across some interesting links:

• Distributed Version Control Systems: A Not-So-Quick Guide Through [link added 5/13/2008]
• Wikipedia page on Distributed Revision Control
  
• Eric Raymond's Understanding Version Control
  
• Ben Sussman on the Risks of DVCS
  
• Ian Clatworthy on Distributed Version Control: Why and How
  
• Ian Bicking on Distributed vs Centralized VCs
  
• Another blog-entry on DVCS vs VCS
  
• Introduction to Distributed Version Control Illustrated
• Choosing a Version Control System
• Distributed VCSes: git vs. Mercurial vs. SVN
• Why Distributed Version Control matters to you, Today!
• Distributed VCS for the other 80%
• Distributed VCS Shootout Redux
• The New Breed of VCSes
• Why Distributed VCS?
• Zooko's Quick Ref Guide to Free DVCS
  

Anyone else have any links they recommend on the topic? (please, no spam/marketing)

BOOK: Lean Project Management

My review of Lean Project Management is in the February 2008 issue of the Agile Journal.

Lean Project Management: Eight Principles for Success, is actually a second edition of the eBook Eight Secrets to Supercharge your Project with CCPM. It is available both in hardcopy and eBook formats. Lawrence Leach (www.advanced-projects.com) is perhaps best known as author of one of the most comprehensive texts on the subject of Critical Chain Project Management (CCPM). In this book, subtitled "Combining CCPM and Lean tools to accelerate project results," the author essentially integrates Lean Thinking into CCPM, along with elements from the Theory of Constraints (TOC) and PMBoK/PMI. Leach calls the result Lean Project Management or LPM.

... All in all, I found Lean Project Management to be a fairly quick read providing a good overview of some TOC and CCPM fundamentals and how they align with Lean thinking, as well as how Lean thinking can be applied to some of more traditional PMBoK methods. Someone looking for a more comprehensive reference on TOC thinking processes and CCPM would probably be better off reading Goldratt's books, the work of William H. Dettmer, and the 2^nd edition of Leach's Critical Chain Project Management. But for those wanting the bird's eye overview with a brief "zoom in" on some of the details, along with how Lean thinking helps tie it all together with some of the more traditional project management methods, Lawrence Leach's Lean Project Management is a nice overview text describing some of the most powerful aspects of TOC and CCPM through "Lean eyes for the PM guy!"

Read the full review

Software Architecture Quality Attributes

Following on to my previous blog-entry about Software Architecture Views and Perspectives, the book "Software Architecture in Practice" also describes a method called Attribute-Driven Design or ADD. This is not yet-another-design-method like BDD or TDD. ADD is concerned software architectural design (so it's at the "architecture-level" rather than what we might normally think of as the "design-level").

ADD is concerned with explicitly identifying the desired quality attributes of an architecture. Many of us know that simply implementing the (functional) requirements correctly is just the beginning of any good design, and possibly not even the most important attribute of the design. In addition to other attributes like security or availability, there are also attributes like modifiability of an architecture. And it is often these attributes that, if attained, are the true indication of whether or not we've done a good job.

Some of the more commonly desired quality attributes are:

• Availability
• Modifiability
• Performance
• Security
• Testability
• Usability
  

Many of us have also often had difficulty trying to explain to management the importance of things like "refactoring" and what that modifiability gives us in return. ADD makes such quality attributes an explicit goal of the architecture design process. One of the first things it asks us to do is the necessary homework (research and interviews) to analyze and identify what are the desired quality attributes for our architecture and its stakeholders. It also defines use-case-like entities called Quality Attribute Scenarios, which is a way of expressing such non-functional requirements as an explicit use-case (which can then have an associated business-value).

ADD also explicitly mentions the use of patterns and tactics as part of its methodology for achieving quality attributes and making design tradeoffs (quality attributes are often the "forces" for a pattern). For each of the common quality attributes above, it identifies a taxonomy of common tactics and patterns used to make good tradeoff decisions for particular aspects of the design.

Although it look s a bit heavyweight, ADD looks promising in its use of patterns and tactics and recursive/iterative nature. But what I like most about it is that fact that it makes explicit the kinds of quality attributes and their non-functional use-cases or "stories" which can then have business value/priority associated with it, and thereby justify the existence of activities that help realize those attributes of the system.

For some more information on ADD, see the following:

• Software Architecture in Practice
• The SEI webpage on Attribute-Driven Design
• The paper Quality Attribute Design Primitives and ADD
• Introduction to the ADD Method
• A Practical Example of Applying ADD (SEI Technical Report)
• Links from Real-world Software Architecture in .NET Developer's Journal
• Presentation from Paul Clements on Designing Software Architectures
  
• The paper Generalizing a Model of Software Architecture Design from Five Industrial Approaches (by a star-studded list of authors in the field)
  

Now I want to ask the question of applying this same idea to software processes and software process architecture: Seems to me that in Agile development, we're really not anti-process, but there are some really important things (quality attributes of a process?) that we feel are often left out to pasture by a lot of the very formal, CMMI-based processes we witness. Perhaps they're ignoring these important process-design quality attributes? (as embodied in the Agile Manifesto?)

Software Architecture Views and Perspectives

I'm fairly interested in the literature on Software Architecture Views and Perspectives. Folks here may remember my work on Dimensions and Views of SCM Architecture as one of the reasons why ...

The text of the entire 2nd edition of the "Software Architecture in Practice" textbook is available online as one source fo information on the subject (among others). I found another good link (& book reference) at http://www.viewpoints-and-perspectives.info/

It's the website for the book "Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives" by Nick Rozanski and Eoin Woods. They classify/use "Viewpoints" and "Perspectives" as follows:

Viewpoints:

• Functional
• Information
• Concurrency
• Development
• Deployment
• Operational

Perspectives:

• Security
• Performance and Scalability
• Availability and Resilience
• Evolution
• Accessibility
• Development Resource
• Internationalization
• Location
• Regulation
• Usability

Found a few other links too:

• Paul Clements' presentation on View-Oriented Representation of Software Architecture
• Eoin Woods' 2008 Saturn Tutorial on Software Architecture - Stakeholders, Views & Perspectives
  
• Rosanski & Woods BCS-SPA 2005 presentation on Software Architecture Views and Perspectives
• Nick Rosanski's website and Eoin Woods' website
• https://wiki.umn.edu/view/Main/SoftwareArchitecture
• http://ece.ut.ac.ir/classpages/S85/SoftwareArchitecture/
• Lecture slides+notes from a University of Auckland Software Architecture course that are heavily-based off the material in the textbook
  
• Lecture slides+notes from a Univ of Aalborg Database and Software Architecture course where several of the lectures are based off the same materials
  

KanBan is NOT Iteration-Free!

Regarding my previous posting about Software KanBan, much as I really do like it and have nothing but the utmost respect for the likes of Corey Ladas and David Anderson, there is one major quibble I have with some of the stuff being said ...

I think all the stuff saying it is Iteration-less and Iteration-free is a bunch of hooey! I don't agree at all and I think it is extremely misleading to say that Software KanBan doesn't use or need iterative development.

Don't get me wrong - I think I understand where they are coming from. There is often a great deal of recurring and heated discussion on numerous Agile forums about "Ideal" iteration length. I understand how folks can be sick and tired of that (to be honest, I myself never really paid too much attention to those particular discussion threads about ideal iteration-size).

The idea that is new or revolutionary for some is that release/feature content is decoupled from development! One or more features/requests are being worked in parallel, and every two weeks (or however long) some combination of newly developed functionality from those that are ready is selected to be released (rather than before development is underway).

But it seems to me that this is just an application of Agile-style development iterations applied to multi-project management. It is Releases that are decoupled from iterations (and hence iteration-free). But as I see it, the iterations are still present: they are where the development is, on the various feature "projects" that are being developed in an incremental and iterative manner, each at their own rhythm (some might be every two weeks, others might be less frequent, but they all find their pace).

I don't believe for one second that each of those features/requests are specifying and elaborating 100% of their requirements before they start coding anything. Looks to me like, for all but the smallest of requests, they may flesh out a certain amount of requirements up-front (be it lightweight use-cases, or even something a bit more formal), but only to a high-level or medium-level of detail. And from that point on through, the detailed requirements, implementation, and feature-level testing and integration-testing they are proceeding in a VERY MUCH iterative fashion.

It may not be a strict fixed length, in that the rhythm may fluctuate and readjust from time-to-time, but it definitely does have a regular rhythm! The length of any given "iteration" is fixed to the cadence of the feature-team (even if it is a team of 1 or 2). Not all iterations may be the same length, but any given iteration is working to a fixed due-date rather than letting that cycle stretch out until the "scope" is complete.

So don't let anyone tell you that Agile development need not require working in an iterative manner. It most definitely does (and at multiple levels of scale). Just don't assume it means that iterations must always be a property of a "release" as opposed to some other related chunk of work (possibly multiple ones proceeding in parallel).

It is not the releasing that needs to be iterative, it is the development. And if the releases are decoupled form development (which I think is a GREAT idea), then the development of any non-trivial sized feature or request still will need to proceed in an iterative manner according to some regular cadence that gets established.

Katch the KanBan Kraze!

For those who haven't been keeping up with "Agile 2.0" or "Post-Agile", one of the more recent developments has been KanBan for Software Development. I first heard about it from David Anderson in a presentation he gave at about a KanBan System for Sustaining Software Engineering. Then I heard David and some others saying how they did away completely with iterations and simply release every two weeks, and shortly thereafter David started a KanBan Development YahooGroup.

Anyway, I think it looks extremely interesting and promising, particularly for folks in an internal IT or tool development group where much (if not all) of their work is sustaining engineering of existing tools and not so much major new feature/product development.

So I thought I would roundup several resources on the subject for folks who might be interested in learning more:

• Wikipedia page on KanBan
  
• Strategosinc description of KanBan
  
• Yet another decent description of KanBan
  
• KanBon.com's "Business Lean" blog
  
• InfoQ.com article on Visualizing Agile Projects using Kanban Boards (also available from DDJ online)
  
• InfoQ.com article on Incremental Software Development without Iterations
  
• InfoQ.com article on Kanban Applied to Software Development: from Agile to Lean
  
• An article from Dean Leffingwell ("Scaling Agility") on The Simple, Visual, Iteration Kanban
  
• David Anderson's Blog and Articles
  
• Corey Ladas' "Lean Software Engineering" blog
  
• Occasional articles posted at the Agile Practitioner's Forum
  
• KanBan Development YahooGroup

Mary Poppendieck on How to Fail with Agile

Marry Poppendieck gave a keynote at SQE's Agile Development Practices Conference during the last months of 2007. The slides for that presentation are now available online. The presentation is entitled Welcome to the Mainstream (and How to Fail with Agile)

An interesting read!!!

Best SCM Best Practices Article

The November 2007 issue of the CM Journal was devoted to the theme of "What Best Practice is Best?" Joe Farah's article on The Top 10 SCM Best Practices was quite possibly the best article on SCM best practices that I've come across to date!

Joe actually first lists his top ten "runners up" followed by his top ten. They are as follows (read the article if you see any terms that are unfamiliar to you):

1. Use of Change Packages
2. Stream-based Branching Strategy - do not overload branching
3. Status flow for all records with Clear In Box Assignments
4. Data record Owner and Assignee
5. Continuous integration with automated nightly builds from the CM repository
6. Dumb numbering
7. Main branch per release vs Main Trunk
8. Enforce change traceability to Features/Problem Reports
9. Automate administration to remove human error
10. Tailor your user interface closely to your process
11. Org chart integrated with CM tool
12. Change control of requirements
13. Continuous Automation
14. Warm-standby disaster recovery
15. Use Live data CRB/CIB meetings
16. A Problem is not a problem until it's in the CM repository
17. Use tags and separate variant code into separate files
18a. Separate Problems/Issues/Defects from Activities/Features/Tasks
18b. Separate customer requests from Engineering problems/features
19. Change promotion vs Promotion Branches
20. Separate products for shared code

Granted, some of these may not be particularly Agile (nor were they meant to be specific to Agile development or Agile CM) but it's still a pretty darn good list in my opinion!

Lean Research from MIT

A couple months ago I stumbled across the MIT Lean Advancement Initiative (LAI) website at http://lean.mit.edu

It is a veritable goldmine of papers and research relating to lean product development and lean systems engineering. You can search through the publications yourself. I took an initial pass thru and found the following couple dozen papers whose abstracts caught my eye:

• A Comparative Review of Lean Thinking, Six Sigma and Related Enterprise Process Improvement Initiatives
• Measuring Value in Product Development
  
• Improving the Software Upgrade Value Stream
  
• Strategies for Lean Product Development
  
• Understanding Lean Manufacturing According to Axiomatic Design Principles
  
• Value Stream Mapping and Earned Value Management: Two Perspectives on Value in Product Development
  
• Value Stream Analysis and Mapping for Product Development
  
• Sources of Schedule Risk in Complex System Development
  
• Lean Enterprise Model
  
• Cost Awareness in Design: The Role of Data Commonality
  
• Construction Design as a Process for Flow: Applying Lean Principles to Construction Design
  
• Performing Collaborative, Distributed Systems Engineering (CDSE): Lessons Learned
  
• Creating High-Performance Enterprises
  
• Corporate Decision Analysis: an Engineering Approach
  
• Systems Development Technical Interactions and Innovation: A Networks-Based Investigation

Happy reading!

Stellation Archives

Several years back there was an interesting open-source Eclipse project named "Stellation" at www.eclipse.org/stellation. It was to be an advanced/modern version control tool with lightweight branching and support for fine-grained checkout at the logical/semantic level.

Then about 2-3 years ago it just up and disappeared. I tried doing several websearches for it, but to no avail. Then on the revctrl mailing list I saw someone inquire about it, and I chimed in too wondering where it had gone.

Karl Fogel (of CVS and Subversion fame) replied with exactly what I was looking for ...

You can get the whole project archived as a tarball here:

http://archive.eclipse.org/technology/archives/stellation-project.tar.gz

It used to live at http://www.eclipse.org/stellation/. Those pages have been pulled, with no redirect left behind (a bit annoying when an open source project does that!).  But a search on eclipse.org pulled up this thread:

http://dev.eclipse.org/newslists/news.eclipse.foundation/msg00766.html

...which pointed to...

http://www.eclipse.org/technology/archived.php

...which pointed to the above tarball.  Summary from the archive page:
"Stellation is a software configuration management system designed to be an extensible platform for building systems based on the integration of advanced or experimental SCM techniques with the Eclipse development environment. The Stellation project will be using this system to integrate support for fine-grained software artifacts into the Eclipse environment, with particular focus on dynamic program organization, and inter-program coordination.

The Stellation website, newsgroup, mailing list, source code, and latest download are available in a compressed tar archive (110Mb) [http://archive.eclipse.org/technology/archives/stellation-project.tar.gz]"

So now you know! (and so do I).

The Majesty of the Mythical Man-Month

I am still amazed at the number of software managers who are unfamiliar with "The Mythical man-month" lesson that says (paraphrasing here) adding more people to a late project makes it even later. So I decided to round-up some resources on the subject. Here they are:

• Wikipedia entry on the Mythical Man-Month
  
• Code Reads #1
• Serverside.com Walkthru of chapter 1
• The Mythical Man-Month curve
• MMM entry on the "Myths in Software Engineering" Wiki
• TechRepublic.com review
• Software Team-size: the Mythical Man-Month
• Classic Quotes from the Mythical Man-Month
• Late projects, man-months, and the software crisis
• Frederick P. Brook's quotes on software engineering
  
• The Mythical Man-Month and the Future of Software Development

Several of the materials I found were course lectures from various Universities:

• Univ. of Colorado lecture
• USFCA Lecture notes
• UC Irvine Lecture
• UTA Lecture
• William & Mary Lecture
• U. Virginia Lecture/Study notes
• Macquarie Univ. Lecture
  

I like the classic quotes! Among my favorites ...

“Adding manpower to a late software project makes it later.”

“How does a project get to be a year late?... One day at a time.”

“Nine women cannot deliver a baby in one month”

“Program maintenance is an entropy-increasing process, and even its most skillful execution only delays the subsidence of the system into unfixable obsolescence.”

“Plan to throw one away; you will, anyhow.”

“Conceptual integrity is the most important consideration in system design.”

“If a system is to have conceptual integrity, someone must control the concepts. This is an aristocracy that needs no apology.”

“The purpose of organization is to reduce the amount of communication and coordination necessary.”

“Build a performance simulator, outside in, top down. Start it very early. Listen when it speaks.”

“The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds castles in the air, from air, creating by exertion of the imagination. Few media of creation are so flexible, so easy to polish and rework, so readily capable of realizing grand conceptual structures. Yet the program construct, unlike the poet's words, is real in the sense that it moves and works, producing visible outputs separate from the construct itself... One types the correct incantation on a keyboard, and a display screen comes to life, showing things that never were nor could be... It prints results, draws pictures, produces sounds, moves arms. The magic of myth and legend has come true in our time.”

“The computer resembles the magic of legend in this respect, too. If one character, one pause, of the incantation is not strictly in proper form, the magic doesn't work. Human beings are not accustomed to being perfect, and few areas of human activity demand it. Adjusting to the requirement for perfection is, I think, the most difficult part of learning to program.”

Understanding Version-Control

Eric Raymond, famed OpenSource co-founder and Unix guru, author of The Cathedral and the Bazaar and The Art of Unix Programming, is currently working on a draft of a work entitled "Understanding Version Control"

It is an interesting read, and covers some of the more recent systems like Bazaar and Mercurial. For those who wish to give feedback, there is a link you can follow for a reviewers' mailing list.

BOOK: The Art of Agile Development

My review of The Art of Agile Development is in the January 2008 issue of the Agile Journal

This is an amazing book! The Art of Agile Development is nothing less than 10+ years' worth of agile development experience distilled into a single compendium of practical insight and mindful application of Agile practices and principles. James Shore and Shane Warden have succeeded marvelously in doing exactly what they set out to do: "packed everything we knew about the day-to-day practice of agile development into 400 pages ... to provide a complete how-to guide and starter kit for beginning and intermediate agile practitioners" (quoted from the book's website).

... I can't think of a better XP practitioner-guide to date that conveys both the practices and principles of XP for novices and intermediate-level readers, and also goes beyond explaining them to provide quintessential insights, tips, contraindications, alternatives, and organizational strategies for how to overcome the many technical and organizational barriers that can stall an otherwise successful attempt adopting XP.

Read the full review

The Truth About Agile Processes

After my previous long-winded entry about "What do you wish your CEO knew about Agile?", I came across this Forrester report on "The Truth about Agile Processes"

It has a summary of what CEOs/CIOs and managers need to know are the changes they need to make in order to adopt agile:

• Larger-teams should be broken into smaller ones
• Functional silos have to be broken down, or at least weakened
• Specialists may have to pick up new skills
• Teams must learn to self-manage, and managers must learn to let them
• Routine activities have to be automated (integration, builds, testing, etc.)

These underlie the message that "going Agile" is more than just a change in one's technical processes. It also requires changing (mind-set as well as process) how one does not only project-management, but also overall management - including status-accounting and reporting of results. And it requires a great deal of rigor/discipline (even tho it may be less formal) in these practices as well as the technical/engineering practices.

You can't expect to make a successful go of Agile by modifying only your technical process & practices. Management has to make some changes too, and the most significant change may be the mind-set for how they are accustomed to measuring and reporting progress (especially for those currently using stage/gate management).

What do you wish your CEO knew about Agile?

Esther Schindler has been posting on a number of different Agile-related groups & forums asking participants the question:

If you could get the boss to understand one thing, just ONE THING, related to Agile development... what would it be? Why that?

When she posted this to the Agile CM forum at cmcrossroads.com, my reply was as follows ...

My "one thing" would be a bit more basic than either CM or "Agile" (IMHO), and culled from Steve McConnell's talks on "Critical Insights for C-level Executives" and "The 10 Most Powerful ideas in Software Engineering" both of which are available online from Construx (unfortunately you have to register to download them, although registration is free and they promise not to spam you)

McConnell starts off with what he says are 5 insights that C-level Executives already know:

• Software projects are late
• Software projects are out of control
• Answers from software staff are often incomprehensible
• Answers from software staff often seem evasive
• Software is the most unpredictable part of the business

Then he goes on to describe what he calls the 7 Critical insights about software development that C-level executives need to know:

• Typical Budgeting Processes Undermine Effective Development (and don't acknowledge the "cone of uncertainty")
  
• Stage-Gate Processes Are Prevalent In Leading Companies
• Low Quality Is The Single Largest Cost Driver
• People (Staff) Exert The Largest Impact On Project Outcomes
• Software Improvement Works Best When Supported at the Organizational Level
• The Tradeoffs Between Cost, Schedule, And Quality Might Not Be What You Think They Are
• Improved Software Practices Offer Exceptionally High ROIs

McConnell describes the 10 most important/powerful ideas in software development as follows:

• Software Development Work is Performed by Human Beings (people are the single biggest influence factor for success)
• Incrementalism is Essential
• Iteration is Essential
• The Cost To Fix A Defect Increases Over Time, Throughout the Development Lifecycle (even when using iterative/incremental/agile development)
  

• There’s an Important Kernel of Truth in the Waterfall Model
• Ability to Create Useful Software Estimates Can be Improved Over Time (The Cone Of Uncertainty)
• The Most Powerful Form of Reuse is Full Reuse
  
• Risk Management Provides Critical Insights into Many Core Software Development Issues
• Different Kinds of Software Call For Different Kinds of Software Development - The “Toolbox” (there is no single best best practice or method across all software projects/products)
• Software Engineering Body of Knowledge - SWEBOK (existing body of knowledge provides a wide spectrum of support for software development practices, especially CM, PM, RM, QM, Testing, Design, Construction, Management, Maintenance, Methods and Tools)
  

So how would I distill all of that into a single statement to communicate to C-level executives? Tom Gilb get's an honorable mention for his "The Ten Most Powerful Principles for Quality in [Software and] Software Organizations", which he summarizes as a single principle saying:

"Motivate people
towards real results
by giving them numeric feedback frequently
and the ability to change anything for success."

For me, the gist of all the above is that most corporate planning, estimation and management "systems" for software are badly broken because they utterly fail to acknowledge the inherent uncertainty and variation that cannot be removed by "up front" attempts at perfectly stable project plans and/or product requirements (see my article on "The Unchangeable Rules of Software Change"):

• The solution is not going to come about by striving ever harder for perfectly stable plans and requirements earlier in the project!
  
• The only successful way to manage that is through effective and continuous management of risk and change!
  
• And the most effective means of doing that is through the use of iterative and incremental techniques that put people first in order to give frequent feedback and reflection on real-results throughout the course of the project (while still leveraging the existing body of knowledge to serve those people so they can best serve the business).

Many companies seem to behave as if merely identifying risks and having mitigation plans is sufficiently effective, and they just need to do that "up front" and then monitor the risk-list without having to spend much time adjusting, adapting, and refining it throughout the project.

Similarly, many companies seem to behave as if they can effective manage change is they basically strive to prevent changes once the project/requirements is (are) initially baselined.

All that is poppycock! Effective risk and change management comes about only by taking a continuous approach to manage them that use regular increments and iterations to achieve frequent feedback on tangible, valued results. Even that by itself is not enough, because if you do not enable and empower your people to act on those results, collaboratively, throughout the entire lifecycle, then you won't be very effective or efficient at reaching your goals. Your process has to leverage the power of your people rather than being an obstacle that overly constrains/controls them.

That all goes for CM and managing change just as much as it goes for development and managing projects! Stop thinking it is feasible to drive out 100% of the variation and uncertainty early in the project, and rechannel that energy instead on managing risk and change continuously, utilizing iterative/incremental means to attain frequent & regular feedback. Then make sure you empower your people to act on that information by effecting necessary changes as quickly as possible, and using processes that regularly embrace such changes instead of stalling or preventing them.

Flexible Development, Manage It, and Continuous Integration

During my hiatus from this blog since the summer, I still managed to keep up with a few of my book reviews for The Agile Journal. Here they are (with hyperlinks) ...

Flexible Development: Building Agility for Changing Markets by Preston G. Smith published September 2007 by Jossey-Bass My rating: Very good for those looking to apply Agile principles outside of software development. And a very useful concept and measure of flexibility. Read the full review in the December 2007 Agile Journal (also see the book's website at www.flexibledevelopment.com)

Manage It! Your guide to Modern Project Management by Johanna Rothman published June 2007 by the PragmaticProgrammer's Pragmatic Bookshelf My rating: Outstanding! If a budding project manager came to me, with knowledge of text-book project management concepts and project management tools, and asked me "what one book would you recommend to help me swiftly bridge the gap from theory into modern-practice that would most increase my chances of succeeding" I'd be hard pressed to find another book that I'd recommend more highly than Manage It! Read the full review in the November 2007 Agile Journal.

Continuous Integration: Improving Software Quality and Reducing Risk by Paul Duvall, Steve Matyas, and Andrew Glover published June 2007 in the Addison-Wesley Signature Series My rating: Outstanding! For those of you seeking a book on the subject of Continuous Integration (a.k.a. "CI") ... look no further. The book you have got to run out and get is here! No other book to date even comes close to being such a comprehensive and authoritative source of principles, practices, and current technologies and resources about continuous integration. Read the full review in the October 2007 Agile Journal (also see the book's website at www.integratebutton.com)

Visual Studio Team System Better Software Development for Agile Teams by Will Stott & James Newkirk published May 2007 by Addison-Wesley Professional My rating: A highly practical and comprehensive "nuts and bolts" guide for how to use Microsoft's Team System to do eXtreme Programming (XP) using the Agile values. Read the full review in the August 2007 Agile Journal (also see the book's companion site at www.bettersoftwaredevelopment.org)

Oh, and don't forget to look for my upcoming review of The Art of Agile Development in the January 2008 issue of the Agile Journal.

Back for more in 2008

I'm back! My apologies for the six month hiatus since my last blog-entry.

I spent most of the latter half of 2008 being thoroughly enmeshed in a "death march" project at work (as compared to the "near-death march" project I worked for the first half of 2007 :-) . I had intended to try blogging at least every other week, and even have a half dozen blog-entries that I had started and planned to "make coherent" but simply didn't get to. You'll probably see a few of those in the coming weeks.

As of 2008 I will return to blogging regularly, at least weekly on average, and occasionally only bi-weekly or sometimes 2X per week. I have some new thoughts about the meaning of "Agile" CM and CM/ALM Architecture I intend to discuss, as well of plenty of links and resource-lists compile, books to mention, and articles to note (some of them from me ;).

Quick Thinking on Your Feet in the Line of Fire

Do you find it a challenge to both think and act quickly and gracefully in key situations? I ran across three books in the past year all of which have great advice on how to train yourself to do exactly that:

• Quick Thinking on Your Feet: The Art of Thriving under Pressure; by Valerie Pierce


• In the Line of Fire: How to Handle Tough Questions ... When it Counts; by Jerry Weissman


• Improvise This! How to Think on Your Feet; by Mark Bergen, Molly Cox, and Jim Detmar

Maybe this stuff is obvious for a lot of folks who are already skilled at this. Heck some of it is even obvious to me too ... AFTER you learn about it, or while someone is telling you about it. But being able to see it in the moment -- to recognize and identify it, and in less than a heartbeat, respond intelligently and succinctly with grace, civility, shrewdness, and openness, well ... I'm less skilled at that than most (I think) and these are proving helpful to me.

BOOK: Nanoconvergence

The book Nanoconvergence: The Unity of Nanoscience, Biotechnology, Information Technology and Cognitive Science is an utterly riveting short yet well researched, clear and concise text on the coming future of nanocomputing & botechnology and how it will pervade our everyday life every bit as much as barcodes and magnetic strips on credit/debit cards do today. It is both exciting and scary, and really makes you think about software security and quality attributes and regulatory standards and how much more of a role they must be required to play in this science-fiction-becomes-reality future.

I recommend this book, along with a slightly older one called It's Alive: The Coming Convergence of Information, Biology, and Business to get a really good understanding of what this all portends for the future of software and the business and economic ramifications (Think of Enterprise Architecture and how complex it is, then take it all down to the nano-level and meld it with biotech and cognitive science and cybernetics and man-machine interfaces. Then imagine the first Microsoft and Apple releases of the technology and try not to let your skin crawl while being utterly fascinated)

Then go check out www.nanobioconvergence.org

It hurts to even try to wrap my brain around what CM and things like "continuous integration" even mean and how they will be performed and executed in this "new frontier"

BOOK: Design for Trustworthy Software

Design for Trustworthy Software is a rather impressive tome that comprises a compendium of the latest and greatest methods, tools and techniques for system and software design applied to software. It covers Design for Six-Sigma (DFSS) techniques, TRIZ, Taguchi Methods, Quality Metrics, Poka Yoke, 5S, QFD, FMEA, and more.

I expect this book to become a standard reference and graduate-level software engineering text. It is so comprehensive and and yet modern/up-to-date in its coverage. It's a very dry read (and I'm not finished with it yet) and looks to be a comprehensive synthesis of what has been working best in industry for the last 25 years that has only recently (in the past 10 years) been getting some visibility in complex systems software of any significant scale. And it shows how to apply them to software.

BOOK: OOAD 3e - updating the classic

April 2007 marked the release of theObject-Oriented Analysis & Design with Applications, 3rd edition by Grady Booch et.al.

For many, this book was the one that first turned them on to object-orientation as more than just a particular programming language or two, but as an overall way of thinking about how to analyze and design software programs. The book has many classic epiphanies that were precursors to things UML, RUP, patterns and agile development. Booch himself is practically a demi-god of modern software development, architecture and practice.

I guess I've moved on a bit since reading the first edition in the early nineties, because the third edition didn't have as much "zing" for me. And there are so many other good texts around now, that this one reads a bit dry and academic.

I'm actually more interested lately in the work that Booch is doing toward a Handbook of Software Architecture and in his blog.

BOOK: xUnit Test Patterns

xUnit Test Patterns: Refactoring Test Code, by Gerard Meszaros (Addison-Wesley Signature Series, May 2007) is nothing short of FANTASTIC!

As I'm reading through the book, I keep saying to myself "Yes!" and "Aha!" over and over again. This book is very appropros for me right now because I'm dealing with a team that has a legacy codebase and is just trying to develop automated tests and they don't yet have a lot of training or experience refactoring or in automating their own tests, or the xUnit-style tools, much less using all of them together.

This book is EXACTLY what the doctor ordered for my current situation. It covers the basics of test automation styles and frameworks using harnesses and drivers, data-driven as well as other styles and the challenges to be addressed, especially with test setup. It has comprehensive coverage of 68 patterns and an awesome website at http://xunitpatterns.com/ which does a far better job of depicting them than I could on this blog.

If you're trying to get a small group of folks to learn how to do agile-style test-automation and refactoring, this is the book with all the patterns and insight you will want to convey to your team.

'Nuff said!

BOOK: Lean Software Strategies

I reviewed the book Lean Software Strategies for the June 2007 issue of the Agile Journal.

Lean Software Strategies seems to be one of the first books specifically about applying Lean principles and techniques to software development that is not written by the Poppendiecks. When the book first came out, I admit I was put off by several unfavorable reviews at Amazon.com. When I later learned it won the 2007 Shingo prize for excellence in manufacturing research, and saw Lisa Crispin's review at StickyMinds, I decided to give it a second look. I'm glad I did!

Written by Lean experts from two backgrounds, one an academician/researcher and the other an industry practitioner, the style of the book is very different from that of the Poppendiecks. It takes a much more purist (even academic at times) application of Lean production to software development rather than landing squarely on "Agile" or roughly equating the two. I can understand why fans of the Poppendiecks' books, and perhaps those coming from a background that is more "Agile" than "Lean" didn't exactly "rave" about Middleton and Sutton's book. I can also understand the perspective of those coming from a background in Lean production who complain that the Poppendiecks' books are more about "Agile" than "Lean" and that Sutton and Middleton's book is, in their mind, the first book that is truly about applying Lean to Software. I think both camps are "right" in their own way, and that is why I think it is important to read this book in order to gain a broader and deeper perspective of what Lean is and how it applies to software development.

You can read the full review at agilejournal.com.

Upcoming Agile/Lean book reviews

I'm behind in a lot of reading and am finally catching up. As a result I be blogging a LOT about books this month. I have all of the following books (most of which are brand spanking new) that I'll be trying to blog about this summer:

Lean Software Strategies: Proven Techniques for Managers and Developers by Peter Middleton and James Sutton Productivity Press, May 2005

Design for Trustworthy Software: Tools Techniques & Methodologies of Developing Robust Software by Bijay K. Jayaswal & Peter C. Patton Prentice-Hall PTR, August 2006

Patterns of Agile Practice Adoption: the Technical Cluster by Amr Elssamadisy InfoQ online (bound version through lulu.com), March 2007

Object-Oriented Analysis & Design with Applications, 3rd edition by Grady Booch et.al. Addison-Wesley Professional, April 2007

Visual Studio Team System Better Software Development for Agile Teams by Will Stott & James Newkirk Addison-Wesley Professional, May 2007

xUnit Test Patterns: Refactoring Test Code by Gerard Meszaros Addison-Wesley Signature Series, May 2007

Manage It! Your guide to Modern Project Management by Johanna Rothman The PragmaticProgrammer's Pragmatic Bookshelf, June 2007

Continuous Integration: Improving Software Quality and Reducing Risk by Paul Duvall, Steve Matyas, and Andrew Glover Addison-Wesley Signature Series, June 2007

I'm looking forward to writing more about them in the coming weeks!

Lean CM

I found a couple of great resources on Lean CM that are very compatible with the article we wrote last month on Lean-based Metrics for Agile CM Environments.

• Lean Configuration Management – Supporting Increased Value Delivery from Agile Software Teams
  by Jens Norin and Daniel Karlström, in the Proceedings of the 6th Conference on Software Engineering Research & Practice in Sweded (SERPS'06), October 2006 (and also in September 2006 as a Softhouse Whitepaper on Lean CM)
• Gain flexibility & speed with Lean CM
  by Joe Beckett, Plant Magazine, June 2005

I've added these and some others to the list of Agile SCM Articles on the CMWiki.

Defining Agile SCM

The May issue of the CM Journal is devoted to the theme of CM & Agility. Myself and Rob Cowham wrote an article for it entitled Defining Agile SCM: Past, Present and Future.

In our earliest articles on the topic, we defined Agile SCM as "the pragmatic application of sound CM principles & practices in accordance with Agile values, using Lean thinking, to serve the needs of the business!" We wish to elaborate what that means in terms of SCM for Agile development, but even more importantly in terms of how we should apply Agile, Lean and their related principles to SCM processes and procedures.

Basically, we try to emphasize that Agile CM is more than just CM for Agile projects, it also means making CM itself be Agile and using the principles tools and techniques of Agile, Lean, TOC (and even some Six Sigma) for CM. Give it a read through and then give us your feedback!

There is also (finally) a new forum on CMCrossroads.com specifically for Agile CM. Of course one of the discussion topics is "what is Agile CM?" and a lot of detractors saying there is no such thing - that it's just plain old CM for Agile projects and that CM is still CM. I contend it ain't the same old CM, and that Agile CM does more than simply apply classic CM discipline & principles to Agile projects, it also applies Agile/Lean principles, tools and techniques and is just as different from traditional plan-based CM as different architectural styles.

Five R's of Agile SCM Baselines

Almost a year ago I posted an entry on the "5 C's of Agile SCM Codelines". This time I'm posting on the 5 R's of Agile SCM Baselines. I think these are as follows (note that most of these are not unique to Agile/Lean):

• Repeatable -- The steps to create the corresponding Build (Configuration) from its sources should be repeatable: for any baselined configuration, I should be able to build it the same way, over and over again.
  


• Reproducible -- The corresponding Build (Configuration) should be reproducible: for any baselined configuration, I should be able to reproduce it whenever desired.
  


• Reportable -- The corresponding Build (Configuration) should be reportable: for any baselined configuration, I should be able to report all needed details about its content: what files & versions are in it, which changes/requests are in it, who made which change to what (& when), how it was built and with what tools & options, etc.


• Releasable -- The corresponding Build (Configuration) should be releasable: if I have "baselined" it, then almost by definition, it means it should be of 'releasable quality' to the next downstream consumer. (This implies it should be correct + consistent + complete to the extent agreed upon with the its stakeholders.)


• Repairable -- The corresponding Build (Configuration) should be readily repairable: if, for any reason, it is discovered to have some kind of problem, then I must be able to readily repair it either by retracting it and replacing it with it's predecessor, and/or by removing/repairing the offending content and releasing it as a new (corrected) baseline.

I use the term "reportable" instead of "traceable" here for two reasons: 1) 'traceable' doesn't begin with 'R', and 2) 'traceable' brings to mind many negative associations with manual tracing, rather than simply providing the necessary transparency and ability to trace (without necessarily implying doing all that tracing, much less doing it all manually).

Note also that "repairable" may not imply that the cost of repair is low. Ideally, the repair can be done as quickly as possible by the development organization, but getting it to the consumer(s) may be both costly and time-consuming. So, rather than "low cost", being "repairable" speaks more to maintainability, and the ability to quickly understand the system and what must be done to repair it. We want to repair it with minimal interruption of flow, and with a minimum amount of overhead.

Why is any of that particularly "agile"? Most of it isn't, but the 'take' on reportability certainly is, and the notion of "releasable" may seem agile to those who feel the codeline should (ideally) be in a readily releasable state. CMers would say that "releasability" was always part of what a baseline requires (and they'd be right).

What do you think? Did I miss any other important R's? Or should something else be used instead? Would an additional R-word or two not listed above help differentiate between "Agile" CM versus more traditional CM?

Here are all the other R-words I considered:

Recoverable Reliable Reversible Retractable Retainable Realizable Relocatable Remediable Repealable Replicable Revocable Relapsable Rebuildable Recapturable Reconfigurable Reconstitutable Reconstructible Recordable Recyclable Referable Retrievable Reusable Restorable Renewable Replaceable Representable Respectable Responsible Removable Reachable Readable Receivable Reclaimable Recognizable Recommendable Reconcilable Recreatable Remissible Rectifiable Recuperable Redeemable Reducible

If anyone cares, I looked it up at Dictionary.com searching for "r*ble"

Software CM is Not a Process!

The (hopefully) provocative title of today's blog-entry is inspired by Phil Armour's essay "Software is Not a Product!", which is one of many profoundly insightful essay's from his book The Laws of Software Process.

Armour maintains that:

The core issue with the business of software is that we misunderstand what software really is. Software is thought of as being a product, it is looked at as being a product, it is mostly managed as if it were a product. But it's not a product... The hard part about creating software systems is not creating them, it is in acquiring the knowledge necessary to create them (correctly).

Therefore:

Software is not a product, it is a medium for storing executable knowledge.

Our lack of understanding of this basic fact is one of the key issues facing the software industry. We do not "build systems"—we acquire knowledge. The systems we ship to our customers are actually the byproducts of the real activity, which is to learn.

The business imperative is that the real product is the knowledge that is in the systems we ship to the customer, and we don't manage that at all.

So today, I'll attempt a similarly-themed "riff" about Software CM, beginning with the assertion that Software CM is not a process!

This assertion might seem shocking to some. Other CMers might say they have known this all along, saying CM is a discipline (rather than a process), and that numerous formal definitions of SCM have said this for quite some time: SCM is a "discipline" that "governs" or applies "technical and administrative direction and surveillance" to the functional components of CM (item identification & planning; item storage, versioning & change control; status accounting, audit & review).

If software is a medium for storing executable knowledge, and software development is a knowledge acquisition & creation (learning) activity, then the result of software CM is the medium through which software development changes and collaborative learning must ultimately flow.

If the result of software CM is a medium for the conveyance of changes by executing the knowledge gained from learning, then software CM itself must impose some form of order (structure & rhythm) to achieve this resulting collaborative flow of change-flow.

For me, terms like "order" and "structure" evoke memories from my years participating in the software patterns movement and study+discussion of the works of Christopher Alexander. For Alexander, patterns were all about discovering the innate order in structures that emerged naturally from the recurring attempt to resolve (trade-off) the same set of competings concerns (forces) for the same problem in the same/similar contexts. The resulting structures and their sequencing and interaction is what all comes together as an overall (emergent) architecture.

Hence, I would say that Software CM is an emergent yet intentional architecture that ensures the orderly, efficient flow of software development change & collaboration.

The elements of this Software CM architecture include practices, tools & technology, teams & organizations, valued deliverables & intermediate work-products, changes to and assemblies of these deliverables & work-products, and the set of needed status/tracking reports & measures.

Hmmn, this fits in rather nicely with my 4+2 Views of SCM/ALM Solution Architecture and perhaps even does a good job of tying together SCM with Agile/Lean (collaboration & flow), and software patterns (particularly SCM Patterns :).

So there you have it:

Software CM creates the medium through which software development changes & activities must flow. Therefore, Software CM is the intentional architecture of software development change-flow.

What do you think?

BOOK: Release It!

I just received a copy of "Release It! Design and Deploy Production-Ready Software" by Michael Nygard. This looks to be yet another winner from the PragmaticProgrammers' Pragmatic Bookshelf. In fact it made #1 on Amazon.com's "Hot New Releases" list for Design Tools and Techniques for the past two weeks.

Actually, this book isn't about what I had originally thought from reading the early descriptions. I thought it was going to be related to build+release+deployment engineering (CM guy that I am :). It's not about that at all. It is about architecture and design for production deployment concerns, such as: hardware/software "fit", availability/reliability, operability, stability, capacity, and maintainability (not just of the code, but of the deployed product at the customer's site).

"Release It!" covers all those things many of us software-only, high-level abtractionists forgot (or worse yet, never learned) about design & architecture for where the rubber meets the road. I need to add it to my reading list!

April CM Journal and LDM

The April issue of the CM Journal, and there is a FANTASTIC article in it by Austin Hastings about his Longacre Deployment Management strategy for dealing with database CM. It's long, but well worth the read for the insight into a new way of thinking about and doing CM of a database.

The April CM Basics issue has a companion/predecessor article a Case Study: Enterprise and Database CM the describes the initial problem, motivation and challenges that the LDM approach needed to solve. The LDM article goes into the gory technical details of the solution.

Agile Development Distilled

Lately I've been spending some time thinking about how to distill Agile development within my company on a single powerpoint slide for a top-level Executive. I keep going back and forth between something that shamelessly steals (and modifies) something used to describe RUP, and something that shamelessly steals (and slightly modifies) something from Dan Rawsthorne.

Dan Rawsthorne writes that the "essence of agility is: iteration, validation, feedback." I think something along those lines is ...

Agility comes from rapid feedback & learning in short-cycles using:

• Close Collaboration
  
• Continuous Validation
  
• Frequent Iteration
  
• Dynamic Adaptation

RUP talks about 6 Key Principles For Business-Driven Development:
1. Adapt The Process
2. Balance Stakeholder Priorities
3. Collaborate Across Teams
4. Demonstrate Value Iteratively
5. Elevate The Level Of Abstraction
6. Focus Continuously On Quality

I think an "Agile slant" on that would be:

1. Adapt to Change
2. Prioritize Scope
3. Collaborate Across Teams
4. Demonstrate Value Iteratively
5. Elevate the Level of Automation
6. Continuously Validate Quality

Of course much of this just seems like Steven Covey’s Seven Habits of Highly Effective People. And maybe that is true.

Other sources and quotes ...

Alistair Cockburn writes of Seven Properties of Agile Projects: 1. Frequent Delivery 2. Reflective Improvement 3. Osmotic Communication 4. Personal Safety 5. Focus 6. Easy Access to Expert Users 7. A Technical Environment with Automated Tests, Configuration Management, and Frequent Integration

David Anderson's Agile Recipe for Success is: Focus on Quality, Reduce Work-in-Progress, Balance Demand against Throughput, Prioritize. He also writes "Trust is the essence of Agile"

Jim Highsmith adds that: "Agile Organizations don’t just respond to change; they generate it!"

“Agile development uses feedback to make constant adjustments in a highly collaborative environment." -- Andy Hunt, http://www.sdtimes.com/fullcolumn/column-20060615-01.html

"Short Cycles and Customer Involvement" -- 3rd eWorkshop on Agile Methods

"an inclusive, people-centred approach to doing iterative, incremental software development. It uses a combination of technical and social practices to increase collaboration and reduce feedback cycles" -- Steve Hayes, http://pliantalliance.org/?p=31

"The essence of Agile evolution is to gradually transform a typically conservative, risky and unattractive activity into a positive and proactive development activity." --Dave Thomas, Agile Evolution, http://www.jot.fm/issues/issue_2006_09/column2

See table of "Key Characteristics of Agile" at (Towards an Agile Systems Engineering process)

See Agile Axioms and Seven Core Practices of Agile Development

DSDM in a Nutshell

Getting Real

My Nutshell definitions of Agile Development

Why Agility Works

Scrum Primer

Agile EVM

Allan Shalloway's Agile Explained

Dean Leffingwell with Ryan Martens, Scaling Software Agility, Ch 7 on The Essence of Agile

Not so Agile aspects of Agile Development

The Agile-Oriented Paradigm

More take-offs on Covey's Seven habits are ... Five Habits of Highly Visionary Companies Six Habits of Highly Effective CIOs Seven Habits of Highly Effective Programmers Seven Habits of Highly Effective User Interface Designers Seven Habits of Highly Effective IT Managers The Seven Habits of Effective Iterative Development

From SurgeWorks (http://www.surgeworks.com/our-methodology) ... In a nutshell, Agile Methodologies are focused on delivering maximum business value in minimal time. There are several different Agile approaches, but all of them focus on a similar set of core practices. They are: Iterative development Business prioritization Adaptive to changing/evolving requirements Active user involvement

Defining Design Quality

Nice article on Defining Design Quality at InfoQ.com. The article heavily references the work of James Shore, who is currently working on a book with chromatic entitled "The Art of Agility". It has a pretty nice definition of design quality:

"A good software design minimizes the time required to create, modify, and maintain the software while achieving run-time performance."

It also references a few other nice articles:

• An Artima interview with Erich Gamma which notes that "Modification and maintenance time are more important than creation time."
  
• An article by Alistair Cockburn on programming as theory building
  

This also ties in quite nicely with Agile ideas about "Simple Design" and some earlier blog-postings of mine about Simplicity in Design (and ChangeThis for Simplicity).

Best Kept Secrets of Code Reviews

The folks over at SmartBear software have written a nice little book entitled The Best Kept Secrets of Code Reviews. It's free if you go over to their webpage and ask for it (you have to fill out a registration form, and it takes a few weeks to arrive, but they havent spammed me at all since I registered with them a few months ago).

This is a pretty good book and it is VERY pragmatic! It is applicable to Agile development too! [You don't have to do Pair-Programming to be Agile! Pairing is part of XP, which is one particular agile method -- several other agile methods do not require it.]

SmartBear also has a pretty neat suite of tools that look to me like they would be REALLY USEFUL for an organization trying to streamline some of its otherwise heavyweight processes for peer-reviews and related quality metrics:

• CodeCollaborator - Automation for paperless peer code-reviews
  
• CodeReports - Continuous source code metrics over time.
  
• CodePickle - Suspend & resume code changes in local developer sandboxes (implements the PrivateVersions pattern without using version-control branches)
  
• CodeReviewer - automated peer-to-peer code reviews across remote sites
• CodeHistorian - Data-mining and visualizations for version control systems.

And "No!" they did not ask me to blog or say anything nice about them or their products! I'm simply coming from the perspective of someone in a large organization who has witnessed a lot of homegrown and heavyweight processes and tools for these kinds of things, and don't see too many commercial tools addressing the peer-review aspect of development and trying to make it lighter-weight and better-integrated with version-control and the rest of SCM.

The have some other nice resources too:

• Agile Peer Review: Methods, and Results (Powerpoint Presentation)
• The Case for Peer Code Review
• Brand New Information about Code Reviews
• 11 Best Practices for peer code review
• 2500 Reviews at Cisco® - The Largest Case Study of Code Review, Ever
• Why formal inspections fail
• Team-Building for the Cold, Dark, and Alone
• Compare 5 styles of review
• Pros & Cons of Four Types of Review
• Social effects of peer code review

Looks like a lot of "good stuff" to me!!!