Recursive Make Reconsidered

In an earlier blog-entry reviewing the book Code Craft, I mentioned the classic paper by Peter Miller entitled "Recursive Make Considered Harmful" ...

Anyway, I recently ran across a bunch of webpages that examined or revisited the issue. I thought several of them were worth sharing, so here they are:

• Recursive versus Non-recursive Makefile architectures benchmark
• Recursive Make isn't all that bad
• "Recursive Make Considered Harmful" Revisited
• Recursive Make Reloaded
• Implementing non-recursive make
• Non-recursive make for Linux kernel
• Non-recursive Automake
• Makepp manual pages on recursive make in legacy makefiles and problems associated with recursive makes

Five Things About Me

I've been "tagged" amidst the recent spree of fellow bloggers who are being "asked" to disclose five personal tidbits about themselves that most people don't know. I won't disclose who tagged me, and I won't be tagging anyone else, but I will comply with the request just for the heck of it ...

1. I don’t drink beer or wine – I hate the taste!

When it comes to alcoholic beverages, the only ones I like are those sweet mixed drinks where you can barely taste any alcohol (you know, the ones that are for "sissies").

2. I got inebriated once when I was two years old (in China no less)!

Or so I'm told ... I don’t remember any of it, but as it was told to me, my folks were flying the family to China, and the airline lost our luggage. As consolation, the airline put us up in a hotel and threw a party for us (and several others in a similar situation). Apparently someone spiked the fruit-punch and I never knew what hit me. My sister says I was walking late at night on the shoreline of Taepei, swaggering, swaying, and hiccuping every couple minutes. Eventually my father picked me up and carried me with my head resting over his shoulder, still hiccupping with a giddy grin on my face, pointing at everything I saw and giggling my head off like only a toddler can. (Hmmn – could this explain #1? :)

3. I lived in Taiwan during 1966-1967, and in Hawaii during 1969!

My Dad was a political science professor, and was at the time one of the foremost experts in his field on US-China relations. He would travel to China or Taiwan every now and again for extended periods of time (weeks or longer). One time he took all of us with him and we lived there for a year. In 1969 he had an exchange program with another professor from University of Hawaii on Oahu. Our house was at the top of a very big hill (or a very small mountain :). I went to pre-school at Noalani elementary school in the Manoa valley.

4. I used to be a dancer, and had 20+ years of classical training!

My mom was a dance teacher, and got me started when I was 4 (along with my older siblings). When I got older I decided to stick with it and got to be quite good at it. All in all I had about 20+ years of classical ballet training, along with modern/contemporary, jazz, and a bit of tap and African. I was in a local dance company during my college years and for a short while after. I was good too! I kept up with it until my mid-30s when I was eventually diagnosed with degenerative disc disease. Sometimes guys would try and give me a hard time about my dance background (that's right about the time I would "let it slip" that I also held black-belts in two different martial arts :-)

5. I have Tourette’s Syndrome (TS)

It's noticeable but mild in my case - not like the more pronounced cases you typically see and hear about on TV shows like Oprah or 20/20.

So there it is; I've done the deed!

BOOK REVIEW: Code Craft

Nostarch Press recently published the book Code Craft: The Practice of Writing Excellent Code by Pete Goodelife.

I have to say the book looks pretty "excellent" itself. It may even become a new classic, replacing the old classic "Writing Solid Code" by Steve MacGuire. And if Steve McConnell hadn't recently updated his even more classic "Code Complete" with a 2nd edition, I might even put Code Craft on a par with that. It's that good!

It's not just about programming & design either. Like Code Complete it covers pretty much all of "software construction." It has some good stuff about build, integration, test, source-control, and more.

About my only pet peeve is that in the "Answers and Discussion" section it talks about recursive make versus inclusive make schemes. It has a pretty good discussion, but I couldn't find any reference to the classic paper by Peter Miller entitled "Recursive Make Considered Harmful". That kind of bothered me because I don't think there's any good excuse for it. It also made me wonder if there were some other places I didn't know about where appropriate references/citations were missed or neglected. (It's not severe enough to make me recommend the book any less highly though!)

I would probably put Code Craft on the "REQUIRED READING" list for any relatively new professional programmer, and have them read it just before before reading Code Complete.

Agile CM/ALM in 2007

Every January at CMCrossroads.com the CM Journal focuses on CM predictions for the coming year. My contribution for this year is Agile SCM January 2007 - Looking Back to Move Forward where I reflect on the previous two years' predictions and update them just a bit, with lots of emphasis on Rational Jazz and MS VSTS:

ALF and Corona? or Open-Sourced Jazz?
While there has been activity on the websites for the ALF and Corona projects, we havent been hearing so much about them in the media outside of Eclipse-centric conferences, and press-release announcements from yet another vendor with an Eclipse "compatible" release of their software. While this certainly doesn't shatter the prediction, there has been more attention (perhaps due to more marketing?) about the upcoming ALM collaboration framework from IBM Rational called "Jazz."

Based on the RDSC 2006 Day 2 Keynote presentation (and also at JavaOne), Jazz is touted as the next generation of the Eclipse platform and the team based software development platform. Rational will of course provide a tool-set to go with it, but says it plans to release the overall framework (and code/APIs) under Open-Source. The claim is that the result is an ALM collaboration architecture which is inherently scalable to provide true support for geographicall dispersed development projects in a true collaborative fashion. Well known names from Rational have been presenting Jazz at various conferences throughout 2006 and generating lots of "buzz," as evidenced by articles and blogs like the following:

• IBM is Revamping Rational
• IBM Jazzes Collaboration
• JavaOne 2006: Keynote on Agile Eclipse, Transparency, Honest, and Retrospective
• Rational Jazz Soon to Eat More of It's Own Dog-food: Transparency
• Jazz is the news
• IBM Jazzing up Rational Offerings, from InfoWorld
• IBM to employ open-source development style for tools, from eWeek
• Online Collaboration and Agile Software Development, from Dr. Dobbs Journal
• Big Jazz News on IBM developerWorks blogs
• Agile Requirements Engineering in the Jazz Collaborative Development Environment, from Rutgers 2006 Software Engineering day
• Hot Jazz vs. Cold Beans, blog-entry

Interestingly enough, with all that marketing buzz, Rational was also very clear about that fact that Jazz would not be released until after 2006. So look for even more "hype" and "hope" in 2007 when the first releases of Jazz become available, and especially when the core Jazz infrastructure is released as open-source under the auspices of Eclipse project. It will be interesting to see the impact this has on the Eclipse ALF and Corona projects (which Jazz doesn't currently use, althought it could conceivably make use of Corona in the future) and the Eclipse BIRT project (which Jazz does make use of). Current marketing would suggest that Jazz is the new vision, or more aptly, more likely, the new open-source hope to slay (or at least compete with) MS VSTS

The site founder, Patrick Egan, usually also initiates a discussion thread to engage the readership into the topic, and this year was no exception, as Patrick asked us What needs to change in CM and ALM for 2007. At the end Patrick added "How does CM fair in an increasingly Agile world?"

This sparked the perennial debate about "Agile CM" and whether or not it's any different from more traditional/mainstream CM. Folks wanting to read the whole thread are certainly welcome to do so. I'm going to excerpt what I think are some relevant thoughts from what I posted ...

My thoughts are much along the same lines as Frank's posting. I think we need to raise the level of abstraction of our thinking and problem solving. There are tools that do this, but the problem is that until the "lowest common denominator" tools catch-up, the majority of the state of the practice won't move too far past that (IMHO).

I do think its a good thing that two of lowest common denominator tools on the version-control side seem to be in the process of being supplanted with successors that go further in this direction (CVS -> Subversion, and VSS -> MS VSTS). I don't see as much on the change-tracking side, and integrations still aren't very integrated for the most part.

Regarding "an increasingly Agile world" ... as more and more shops and companies (and vendors) say they are "Agile", the more the term "Agile" becomes diluted and branded, and more of a marketing term than anything else. And that does do damage (as Joe mentioned); In fact it does the most damage to those that are doing it justice.

I do however think that the increased emphasis & visibility on frequent automated integration is a good thing, and that the trend of not only doing more of that, but using that as a mechanism of generating and reporting more (and more accurate) metrics is also a good thing. ...

The term "Agile" and the ideas behind it is no better or different from other "fads" like Object-Orientation or [software/design] Patterns. They had lots of hype and buzz, they had some legitimate improvements to contribute to the state of the practice (even if the ideas themselves weren't new - that's not necessary in order to have great impact/influence), and once everything was all "hyped out" they faded into the woodwork, as a natural, acknowledged, part of the fundamental knowledge we should use+apply everyday.

Increasingly, software CM implementations & deployments will need to better accommodate an increasingly Lean/Agile world (and it will be more important to know the difference between the pretenders and the real-thing). While I agree with Joe and others that the basic tenets of what CM is and what it is supposed to be don't change because of Agile, the fact remains that the norm for how CM is actually practiced and implemented in many shops will need to change.

Many tools/vendors are already headed in that direction, and have recognized the trend foretold by Thomas Friedman (The World is Flat), Peter Fingar (Extreme Competition) and others like Dan Pink, John Seely Brown, and more. With CollabNet, MS VSTS and Rational Jazz, the emphasis is on connecting and collaborating. And ways of doing software development and CM that fail to acknowledge that, and at least the first five of what Steve McConnell calls The Ten Most Important ideas in Software Engineering are going to have a tougher go of things than they have in the past.

As to whether or not "Agile CM" does (or will) exist, that will be determine by the people who end up actually doing it, and defining it. Anything claiming to be "Agile" will need to legitimately embrace the ideals of collaboration and the human element that Agile emphasizes, as well as at least the first 4 of the 10 ideas McConnell identifies. It will also need to embrace Lean principles and techniques. And if I get to have any part in shaping it, I think it should also include heaping helpings of Theory of Constraints (including Critical Chain) and Six-Sigma as they apply to CM and the "throughput" of change-flow, and change management.

All those things have something useful and important to offer us, and for those that can sift thru the hype and wannabees, there are huge gains to be had (whatever the trendy term end up being). I also agree with Bill Langston that there are some relevant standards (as well as "classic" ideas & methods) that are important to maintain, and which must "temper" the application of the newer and trendier (instead of always going back and forth between rigid and unyielding extremes).

Maybe it should be "Jeet Kune Do" CM instead of "Agile" CM :) Because we need to look at the new things and "keep what is useful" without abandoning the old so we can adapt and change as the speed of business and technology mandates.

Blog upgraded -- tagging COMPLETE!

I'm done upgrading my blog to the new version of blogger. Some of you may have already noticed the new template. Although I tried to keep the same scheme, I couldnt keep the title/header section the same, so the font-size there is a bit smaller and my picture has moved to the top-right below the header section. The right hand panel is also a bit different, the "Previous" and "Archives" section have been merged into a a single dynamic "Archives section with a hierarchical listing.

In addition, I finished tagging my blog-entries with labels. The new "Categories" section lists all of the categories and the number of entries in each category (along with a hyperlink to take you to all entries filed under that category).

Oh yeah! I'm also using a newer picture now -- It's amazing just how much one's hair can thin/recede in just a few years :-(

If youre seeing this, then you should no longer need to worry about any more previous entries getting republished "en masse" anytime soon. Very shortly now I'll be "pushing" my last 4 entries "live" in the next couple of days.

Lean Software Development Resources

[last update: 27-April-2007]

For a colleague at work, I compiled a list of resources covering Lean principles & practices, their integration with Six Sigma and/or Agile development methods, and the application of Lean to software development. I thought others might find it useful, so here it is ...

Books:

• Agile Management for Software Engineering, by David J. Anderson, Prentice-Hall PTR, September 2003

• Lean Software Development: an Agile Toolkit, by Mary & Tom Poppendieck, Addison-Wesley, October 2005 in The Agile Software Development Series
• Implementing Lean Software Development: From Concept to Cash, by Mary & Tom Poppendieck, Addison-Wesley, September 2006 in The Addison-Wesley Signature Series
• Lean Software Strategies: Proven Techniques for Managers and Developers, by Peter Middleton & James Sutton, May 2005 by Productivity Press
  
• Managing the Design Factory, by Donald G. Reinertsen, The Free Press, New York, 1997
• Product Development for the Lean Enterprise, by Michael N. Kennedy, Oakela Press, 2003
  

Presentations:

• Lean Project Management, by David J. Anderson
• Agile Management for Software Engineering, by David J. Anderson
• Managing Lean Software Development with Cumulative Flow Diagrams, by David Anderson
• Lean Manufacturing and the Theory of Constraints – Focusing Lean, by Eric Gowland
• Lean Accounting & Throughput Accounting, Peter Milroy
• Lean Six Sigma - Benefits beyond CMMI L3, Nancy POMA, EDS, October 2006
  
• Software and Lean: Like Chocolate & Cranberries, by James S. Sutton, STSC 2005 Proceedings
• Lean Software Development, by Dr Christoph Stiendl, 2004
  
• Lean Thinking: The Theory behind Agile Software Development, by Mary Poppendieck, 2002
• Implementing Lean Software Development (Practitioner’s Course), Mary Poppendieck, November 2006
• Competing on the basis of Speed, 1hr video presentation to Google by Mary Poppendieck
  
• Other talks by Mary Poppendieck at http://www.poppendieck.com/events.htm

Articles/Papers:

• Business Process Management: What's Driving Toyota?, Baseline magazine, September 2006
• Agile Product Development: Managing Development Flexibility in Uncertain Environments, by Stefan Thomke and Donald Reinertsen, California Management Review 40, no. 1 (fall 1998): 8-30
• Managing Lean Software Development with Cumulative Flow Diagrams, by David J. Anderson
• Agile Software Management Accounting for Systems, by David J. Anderson
• Agile Software Management: Dealing with Uncertainty, by David J. Anderson
• The Lean-Agile Connection: Developing Quality Software Efficiently by Alan Shalloway
• Introducing the Integrated Theory by Dan Rawsthorne and Alan Shalloway
• Whitepaper: Agile Work Uses Lean Thinking, Whitepaper by Mishkin Berteig
• Business Performance Through Lean Six Sigma : Linking The Knowledge Worker, The Twelve Pillars, And Baldrige / by James T. Schutta
• Introducing Lean Software Development, by the Lean Software Institute
• Lean Six Sigma and High-Performance Organizations Combined, by Tom Devane (book excerpt)
• Lean Thinking. Protein-based dietary fad or Management’s New Testament?, BPM Europe
• Bringing Lean Systems Thinking to Six Sigma, by Paul Mullenhour and Jamie Flinchbaugh, 2005
• Lean Software Delivery with the IBM Rational Solution, by Clay Nelson, The Ratioinal Edge, October 2006
• TOC and Lean, Iowa State University Center for Industrial Research and Service
• Lean Thinking for Process Improvement, part 2 of a three part series by bizmanuals.com
• Six Sigma and Lean Manufacturing, by Michael Baudin
• Agile vs Lean Software Develompent
  
• Lean articles at isixsigma.com
• How to Compare Six Sigma, Lean and the Theory of Constraints, by Dave Nave, Quality Progress, March 2002
• Software Development Convergence: Six Sigma-Lean-Agile, by David Hallowell
• Design for Six Sigma and Lean Manufacturing, by Praveen Gupta, 2001

Websites / Blogs:

• Tom & Mary Poppendieck’s home page at http://www.poppendieck.com/
• David Anderson's Agile Management website at http://www.agilemanagement.net/
  
• Lean Enterprise Wiki search engine: http://lean-enterprise-swicki.eurekster.com/
• http://www.leansoftwareinstitute.com/
• http://leaninsider.productivitypress.com/
• http://www.lean.org/
• http://www.evolvingexcellence.com/
• http://www.leansoftwareengineering.com/
  
• Lean blogger Pete Shmula at http://www.shmula.com/has lots of nice blog-entries/articles on aspects of Lean
• NetObjectives Lean Software Resources at http://www.netobjectives.com/resources/lean
  
• Lean manufacturing - Wikipedia, the free encyclopedia

Top 10 ACME blog-posts in 2006

Happy new year to all! I thought this would be appropriate for my first blog-entry in 2007 ...

Here are my top 10 blog-entries of 2006. This is based not on hit-counts, but rather on reference counts (number of mentions in other blog-posts, forums, articles, etc.) in some form or another. Note that there was a tie for the #10 spot.

1. Dimensions and Views of SCM Architecture
2. Scaling Agility: Summary of Resources
   
3. The Unchangeable Rules of Software Change
   
4. Agile SCM Principles: From OOD to TBD+CBV+POB
   
5. Trustworthy Transparency over Tiresome Traceability
   
6. Simple ain't Easy: Myths and Misunderstandings about Simplicity
   
7. Codeline Flow, Availability and Throughput
   
8. Impacts of Extreme Globalization and Extreme Competition
   
9. Agile vs MDE: XP, AMDD, FDD and Color Modeling
   
10. Nested Synchronization and Harmonic Cadences and Feedback, Flow and Friction
    

Some of the above surprises me. Some of it is close to what I was expecting ...

• I'm truly astonished at the #1 post - both because it was so recent and also because I'd seen very little indictaion of interest in my 4+2 views of SCM architecture (most folks probably just liked all the links that went along with it).
• The #2 and #3 entries don't surprise me, and I'm happy to see them there.
• I'm very surprised the "Simple Ain't Easy" post didnt rank much higher. I personally liked that one and my "Unchangeable Rules of Software Change" the most in 2006. And I saw so much discussion and mention of the "Simple Ain't Easy" post, I honestly expected it to be the #1.
• I am surprised by the ranking of the posts on codeline flow & throughput, and nested synchronization & harmonic cadences. I had the impression that struck most folks as rather esoteric.
  

For anyone interested in what the next ten most popular ones were ... here they are:

11. Business Agility Defined
    
12. Extreme Traceability
    
13. Nutshell Definitions of Agile Development
    
14. 5Cs of Agile SCM
    
15. Cost, Cruft and Constraints
    
16. Pragmatic Multi-Variant Management
    
17. Agile IT Organization Refactoring
    
18. Trends in SCM Predictions for 2006
    
19. Everyone Wants to be LUVed
    
20. Lean Principles for Branching
    

Here's hoping I can do as well or better in 2007!

Essential CVS and Global Outsourcing with VSTS

Just received two new books about version-control tools:

• Essential CVS, 2nd edition, by Jennifer Vesperman
  [See the sample online chapter containing the CVS quickstart guide]


• Global Outsourcing with Microsoft Visual Studio 2005 Team System, by Jamil Azher
  [See the online sample chapter on "The Business of Outsourcing"]

The Essential CVS, 2e book is one of the better CVS books available these days. I think I like it better than the classic one by Fogel, but not quite as much as the Pragmatic Programmers "Practical Version Control with CVS" (still - it's pretty close).

To be honest though, I really dont feel like CVS is very desirable among free Version-control tool offerings when we have the likes of Subversion, Monotone, Arch, and others that support the more recent paradigms and higher-levels of abstractions for working with project-wide streams (branches) and more.

The VSTS book is rather interesting. The "Global Outsourcing" parts of the title, and some of the corresponding content, would likely "turn off" a lot of folks. It even has a brief section about Agile development (to which, you'd think "global outsourcing would be anathema).

Mickey Gousset published a review of the book back in October, and it's worth a read. I mostly agree with the comments he makes. I think the book is pretty good, but there is another one coming soon that I expect I'll like a whole lot better, as well as several VSTS books available from Amazon.com.

Still, if you need to do a lot of distributed development across geographically dispersed sites, and want to use VSTS not just for its versioning capabilities, but also the tracking and coordination capabilities, this is probably the book to get.

Upgrading my Blog -- tagging in-progress!

I've upgraded to the latest version of Blogger now that it's no longer in beta. There are still a few blog-entries I haven't "pushed out" yet. I will be going through my old blog-entries and trying to add "tags" to them.

What that means to subscribers of my blog is that you will see dozens, perhaps even hundreds of "new posts" of "old" blog-entries. You might want to temporarily unsubscribe until you see a subsequent entry from me saying Ive finished "tagging" all/most of my prior blog-entries.

Agile Tooling Survey Results

From Pete Behrens' Agile Executive Blog, the results to the Agile Tooling Survey they conducted in October are now available online at http://trailridgeconsulting.com/surveys.html:

With over 500 survey responses from 39 countries, we feel this survey
provides an excellent benchmark for where the agile movement is at
today and how we are using project management tooling to assist our
agile processes.

This report builds a corporate profile of companies that are following
agile processes today and then uses that profile to analyze how they
are using project management tooling to support various aspects of
their agile processes.

It's rather interesting to see what sorts of tools are being used for version-control, defect/issue/enhancement-tracking (DIET), and project planning & tracking, particularly when some high-profile Agilists would have us believe that (other than version control) Agile should "eschew" such tools.

I don't think the problem is the tools. I think the problem is most of them were/are made and used in a non-agile fashion that didn't have the agile way of working in mind. Now that there are some tools out there which do, it seems they are helpful after all :-)

Product-Line CM in CACM

The current issue of Communications of the ACM is focused on Software Product-Lines for software engineering. It has a number of interesting articles on software product-lines and product-families for large-scale reuse.

It even has a few articles related to CM of product-lines, particularly change-management and variability-management:

• Feature-oriented variability management in product line engineering
  Jaejoon Lee, Dirk Muthig


• Multi-level customization in application engineering
  Krzysztof Czarnecki, Michal Antkiewicz, Chang Hwan Peter Kim


• Product management for software product lines: an unsolved problem?
  Andreas Helferich, Klaus Schmid, Georg Herzwurm


• Change management patterns in software product lines
  Kannan Mohan, Balasubramaniam Ramesh

Dimensions and Views of SCM Architecture

The November issue of The Rational Edge has three articles that are closely related to my ideas about applying what we know about software & enterprise "architecture" to the domain of SCM/ALM solutions (and another article about an SCM tool vendor "eating their own dogfood"):

• UML, RUP, and the Zachman Framework: Better together, by Vitalie Temnenco
• The four dimensions of system models, by Fredrik Ferm
• A RUP-based approach to developing a data warehouse, by Scott Ambler
• Change Management at IBM Rational: How those who develop ClearQuest use the product, by Robert Pierce

[Also see some interesting articles on Requirements Engineering in the December 2006 issue of Crosstalk]

Some of you may recall my 4+2 Model Views of SCM Solution Architecture. I've since updated the picture a bit as follows (which Ive now updated over there too), click on the small image below to see a much larger one:



Anyway - reading through the above articles (particularly the one on model "dimensions" and the one on UML+RUP+Zachman together) gave me some more thoughts about my 4+2 views model, such as:

• I have "scale & diversity" as a dimension of "concerns" that bridge all views. I wonder if that corresponds to the "scale" or "level" dimension referred to the in article on dimensions of system models?


• I also have change/creation time, and decision binding time as a "dimension" of concerns. It's not explained real well though. I suppose it corresponds to considering both a "static" and "dynamic" perspective for each view. In a sense there are lifecycles (e.g., promotion cycles) for the elements in each view, as well as important times when decisions are committed to, and/or when artifacts or changes are made. When dealing with variation (diversity) across a product or system, the binding-time employed by the solution can be of great importance.


• By adding a +2 view to RUP/Kruchten's original 4+1, I end up with something that sort of maps to the 6 columns of the Zachman model. Does this mean my 4+2views are really a subset of Enterprise Architecture (EA), or might it mean that its some kind of "bridge" between the two?


• Does it really make sense for me to have Organization and data combined into a single view, or is Data really a separate view (a +3 view?), or should I not go so far as to equate metrics, queries and reports with "Data", but rather as the requirements for data (and hence the possible "bridge" mentioned above)?


• What if I compare contrast my 4+2 views with the model or views put forth by any of ITIL, RUP-SE, DODAF, TOGAF, FEAF, or others (see below)? What value does mine add that warrants being its own "thing" instead of just some poor sawed-off wannabe clone of one of the others?

Anyways, these questiosn made me want to go look-up some of these other models and views. I found some pretty good online articles for some of them (I'm sure I missed a few as well). Here they are:

• The new, improved RUP SE architecture framework
• An IBM Rational approach to the Department of Defense Architecture Framework (DoDAF) Part 1: Operational view
• An IBM Rational approach to the Department of Defense Architecture Framework (DoDAF) Part 2: Systems view
• Estimation variance and governance
• Rational Unified Process for Systems Engineering -- Part I: Introducing RUP SE Version 2.0, August 2003
• Rational Unified Process for Systems Engineering -- Part II: System Architecture, September 2003
• Rational Unified Process for Systems Engineering -- Part III: Requirements Analysis and Design, October 2003
• "How does RUP SE apply to a system of systems?"
• "Leading modern systems development"
• "Thoughts on Functional Decomposition"
• "Organizing RUP SE projects"
• Development of Federal Enterprise Architecture Framework using the Rational Unified Process and the UML
• Introducing The Open Group Architecture Framework (TOGAF), Part 1: Understand TOGAF and IT architecture in today's world
• Introducing The Open Group Architecture Framework (TOGAF), Part 2: Explore an industry standard for defining an enterprise architecture
• Introducing The Open Group Architecture Framework (TOGAF), Part 3: Create an enterprise architecture with TOGAF
• developerWorks : Architecture : New to Architecture

I welcome feedback/comments on any of my thoughts above!

The Cone of Uncertainty

I came across a great set of responses to an IEEE Software Article by Ted Little that seemed to question the cone of uncertainty. Among the respondents were Phillipe Kruchten and Steve McConnell. This prompted me on a search for resources about the cone of uncertainty. Here is what I came up with:

• The Cone of Uncertainty, letters to the editor in response to Little's article.


• Schedule Estimation and uncertainty surrounding the cone of uncertainty, Little's article in the May/June 2006 issue of IEEE Software.


• Introduction to the Cone of Uncertainty, from Steve McConnel's website


• The Cone of Uncertainty described at the Coding Horrors blog


• Reducing the cone of uncertainty, an article from the August Newsletter of Pivotal Insights


• How much will it cost? Part I - The cone of uncertainty, an article from Vantage Technology Group


• The Purpose of Planning, chapter 1 of Mike Cohn's book on Agile Estimating and Planning


• Estimation Variance and Governance, by Murray Cantor, from the March 2006 issue of The Rational Edge

Does anyone know of others? I'm particularly interested in anything available online by Barry Boehm and also from Steve McConnell. [Updated 2/2/2007 - Steve McConnell emailed me himself with the URL to a recently available article on his website]

Giving Thanks

It is the day after thanksgiving here in the U.S. Many of us have been with extended families eating obscenely large amounts of wonderfully homecooked meals and desserts and remembering what we are thankful for.

I have a LOT to be thankful for right about now. My surgery was a success and I'm still healthy. More importantly my sister is doing well with her new kidney, and we are both thankful for that, and for our children and our families (our entire family was incredibly helpful and supportive to the both of us - it's amazing to have a family like that)!

Like I said, I have a lot to be thankful for. And yet, I'm also rembering that today is a year to the day since John Vlissides passed away after a long-term battle with cancer.

John was not only co-author of THE seminal work on Design Patterns, he was also the series editor for the SCM Patterns book: he encouraged Steve and I to write it and was a mentor to us both. I would encourage folks to (re)visit the wiki-page created in John's memory.

During this time of year with the winter holidays coming, many of us give money to charities. Before John battled cancer he endured the loss of one of his own children to cancer as well, and his favorite charity was the Children's Cancer Fund (for obvious reasons). This year, I'm also a big fan of the National Kidney Foundation as well as the National Multiple Sclerosis Society (both for personal reasons).

Give Thanks! And Give Generously! :)

The Buildmeister's Guide

I received a copy of the book The Buildmeister's Guide: How to design and implement the right software build and release process for your environment, by Kevin A. Lee, who runs www.buildmeister.com (the book is also available on Amazon.com).

I really liked Kevin's earlier book on ClearCase, Ant and CruiseControl: The Java Developer's Guide to Accelerating and Automating the Build Process. Even though it was specific to ClearCase it had a lot of really good information in general about build/release process automation. The Buildmeister's Guide "builds" on that (no pun intended) and covers build automation tools (such as CruiseControl and BuildForge) as well as Version Control in general (including tool selection and branching/merging policies). It also covers more than just Java, and has sections on other language & environment factors like .NET and C++.

All in all, it looks like a very good, and short (~110 pages) guide for beginning and intermediate build-meisters to learn a whole lot more about effective practices, resources and tools for software building and releasing.

Simplicity in Better Software

Back in May of this year I blogged about how Simple ain't Easy: Myths and Misunderstanding about Simplicity. That entry ended up being quite popular and very well received.

This month, a streamlined version of that entry is the featured article in the "Last Word" column for the November 2006 issue of Better Software magazine. The writing is a bit more compact, though I did end up having to trim a few thoughts I had really wanted to keep. The quotations and links from the original entry didn't make it into the article, but were instead made part of the online "Sticky Notes" for the November issue.

For those with access to the printed magazine who have a chance to read both the article and the blog-entry, I'd appreciate your feedback as to whether you like the article better, or the blog-entry better, and why.

Surviving CMMI, Lean Sigma, ISO-9000 and Surgery

My surgery went well. I returned from the hospital one week ago and am now able to get around on my own (and do some email :-). My remaining kidney is still learning to do the work of two and will be growing larger in the next couple months (in order to compensate). I'm still dealing with the usual to-be-expected-stuff and hopefully within another couple of weeks I will be mostly back to normal (except that I still need to wait another 2months before trying to lift anything >10 lbs, like my 3yr old & 4 yr old :).

I received a few more books in the mail that look like they will be very helpful to someone like myself trying to introduce/increase Agility in a large corporation that has already committed to the likes of SEI CMMI, ISO-9000 (TL9000 for Telecoms), and Six Sigma.

• Process Improvement Essentials: CMMI, Six Sigma, and ISO 9001; by James R. Persse, PhD. O'Reilly, September 2006 (Theory in Practice Series)


• Lean Sigma: A Practitioner's Guide; by Ian D. Wedgewood, Prentice-Hall PTR, October 2006


• CMMI Survival Guide: Just Enough Process Improvement; by Suzanne Garcia & Richard Turner. Addison-Wesley, October 2006.

These books will help someone like me to "speak the lingo" when presenting Lean/Agile principles and practices to those well versed in the above. The Lean Sigma book will (I hope) especially show me how to use the methods and tools of Six Sigma itself to support Lean concepts and techniques.

Mind Hacks and Surgery

This will be my last blog-entry for at least a couple of weeks. I'm going in for surgery tomorrow to have my kidney removed and transplanted into my sister. It will take me about two weeks to recover to the point where I can sit in front of the computer for any length of time - and another two weeks before I return to work. (Well wishes and prayers for both my sister and me will be warmly welcomed :-)

I received two pretty cool books from O'Reilly the other day. They're not your normal fare. And I havent finished either of them yet. But I'm leafing through them and they both look waaaayyy cool and extremely useful:

• Mind Performance Hacks
  By Ron Hale-Evans
• Mind Hacks
  By Tom Stafford, Matt Webb

I'm looking forward to making my way through the rest of these two books and learning more about how my mind works and how to make better use of it (and better "maintain" it :)

Scaling Agility: Summary of Resources

I published a bunch of entries with numerous resources on different aspects of Scaling Agility. I wrote most of them several days apart but many of them got "pushed out" (published) together in sudden bursts. Here they are again:

• Scaling Agility: Seamless Agility across the Enterprise (introduction)


• Scaling Agility: Agile CMMI and Dancing Elephants (15+ links)


• Scaling Agility: Agile Adoption across the Enterprise (20+ links)


• Scaling Agility: Adapting Agile to the Organization (30+ links)


• Scaling Agility: Agile Systems Engineering (15+ links)


• Scaling Agility: Agile Program Management (20+ links)


• Scaling Agility: Distributed Agile (35+ links)

Feel free to post a comment with other links are anything you feel warrants a new category (e.g., melding Agile with any of Lean, TOC, or Six Sigma)

Lean view of Deming's 14 Points for Management.

There has been a really great discussion thread on the Lean Development YahooGroup on the subject of "How do I find bottlenecks?"

I particularly liked a reply by Alan Shalloway that linked things back to W. Edwards Deming's 14 points for management from his Theory/System of Profound Knowledge. Allan's translation has a bit of a "Lean" slant to it, and doesn't explicitly mention eliminating/reducing variation quite so much. Here is how he summarized it:

Re respect for people, the best place to start, IMHO, is Deming. Here are his fourteen points (Chapter 2 of Out of the Crisis, by W. Edwards Deming, MIT Press, 2000; originally published in 1982.):

1. The world has changed and managers need to adopt a new way of thinking. Delays, mistakes, defective workmanship and poor service are longer acceptable.


2. Quit depending on inspection to find defects and start building quality into products while they are being built. Use statistical process control.


3. Don't choose suppliers on the basis of low bids alone. Minimize total cost by establishing long term relationships with suppliers that are based on loyalty and trust.


4. Work continually to improve the system of production and service. Improvement is not a one-time effort; every activity in the system must be continually improved to reduce waste and improve quality.


5. Institute training. Managers should know how to do the job they supervise and be able to train workers. Managers also need training to understand the system of production.


6. Institute leadership. The job of managers is to help people do a better job and remove barriers in the system that keep them from doing their job with pride. The greatest waste in America is failure to use the abilities of people.


7. Drive out fear. People need to feel secure in order to do their job well. There should never be a conflict between doing what is best for the company and meeting the expectations of a person's immediate job.


8. Break down barriers between departments. Create cross-functional teams so everyone can understand each-other's perspective. Do not undermine team cooperation by rewarding individual performance.


9. Stop using slogans, exhortations and targets. It is the system, not the workers, that creates defects and lowers productivity. Exhortations don't change the system; that is management's responsibility.


10. Eliminate numerical quotas for workers and numerical goals for people in management. [We add: Eliminate arbitrary deadlines for development teams.] This is management by fear. Try leadership.


11. Eliminate barriers that rob the people of their right to pride of workmanship. Stop treating hourly workers like a commodity. Eliminate annual performance ratings for salaried workers.


12. Encourage education and self-improvement for everyone. An educated workforce and management is the key to the future.


13. Take action to accomplish the transformation. A top management team must lead the effort with action, not just support.

These go back 60 years. And (I can't help myself) these principles are in the context that process causes 94% of the errors - so work on the process to support the people! (people and process, people and process, people and process, ...) ;)

Alan Shalloway, CEO, Sr. Consultant
Net Objectives, Gold Level Sponsor of Agile 2006.
Integrating people, process and technology through training, coaching and consulting.

Alan's website also has some really great articles, papers, presentations and resources on Agile, Lean, Scrum, XP, Design Patterns, and all things related to Agile development and object-oriented design.

For some slightly different interpretations and summaries of Demings 14 points and Seven Deadly Sins, see the following:

• Wikipedia entry on W. Edwards Deming
• Demings 14 points and Seven Deadly Sins of Management from Ends of the Earth
• A summary of Deming's 14 points from the University of Cambridge Institute for Manufacturing
• Phil Cohen's summary of Deming's 14 points (which seems steeped in the language of removing/reducing variation)

There has also been a thread on another discussionlist (sorry - the name escapes me at the moment) on the relevance (or lack thereoff) of Deming's writings and philosophies in the world of today.

What are your thoughts?

Aikidoka Leadership, Influence and Conflict Resolution

There are a few good books about conflict resolution & leadership that use Aikido style/philosophy throughout. I highly recommend them for anyone interested in the connection between leadership and martial arts philosophy:

• The Magic of Conflict, by Thomas Crum


• The Randori Principles: The Path to Effortless Leadership, by David H. Baum (and Randori Partners)


• Verbal Judo: The Gentle Art of Persuasion, by Dr. George Thompson


• Articles by Judy Ringer on conflict resolution using Aikido principles


• ARTICLE: Aikido & Conflict Resolution: What's the Connection?

There must be some of you out there who have some other links to share on this topic! Leave a comment with your favorites!

Scaling Agility: Distributed Agile Development

Current issues of IEEE Software, CACM, and ACM Queue have articles related to agile distributed development and release management ...

The Sept/Oct 2006 issue of IEEE Software is about Global Software Development. It has several Agile-related articles (like A Practical Management and Engineering Approach to Offshore Collaboration)

This months CACM theme is "Flexible and Distributed Software Processes" with articles on distributed agile development (which are currently available online), including:

• An introduction to Flexible and distributed software processes: old petunias in new bowls?
• Ambidextrous coping strategies in globally distributed software development projects
• Can distributed software development be agile?
• Aligning IT components to achieve agility in globally distributed system development
• Dependency forecasting in the distributed agile organization
• Globally distributed software development and pair programming

ACM Queue an article on Agile/Iterative Release Management entitled Breaking the Major Release Habit.

Other resources on Distributed Agile Development:

• an Agile 2005 presentation on Introduction to Distributed Agile Development


• DistributedAgile.com


• Vince Massol's May 2004 Case Study on Distributed Agile Development


• a July 2004 Forrester Report on The Total Economic Impact™ Of Using ThoughtWorks’ “Distributed Agile” Approach, Single Company Analysis — Financial Services


• Distributed Agile Development, by Dafydd Rees, April 2004


• Agile Alliance articles on Distributed Agile and Offshore Agile Development


• Stickyminds.com article, Going the Distance: Five Tactics to Compensate for Distance on Distributed Teams, by Esther Derby


• 2004 SpiderLogic presentation about an Experience report on Distributed Agile Development


• Knowledge Management for Distributed Agile Processes: Models, Techniques, and Infrastructure from KMDAP2003 (and related paper)


• MKDAP2003 presentation on Proactive Knowledge Distribution for Agile Processes


• Martin Fowler's Using an Agile Software Process with Offshore Development


• Managing Commitments and Risks: Challenges in Distributed Agile Development


• Dependency forecasting in the distributed agile organization


• Briefing of Starsoft Development Labs related to Distributed Agile Development


• the Agile Journal back issues on Globally Distributed Development (April 2006) and Collaboration and Reuse (Sept 2006) [the latter has a few articles about distributed collaboration/agility]


• Jeff Sutherland's Distributed SCRUM paper from IICS'06 on Adaptive Engineering of Large Software Projects with Distributed/Outsourced Teams


• Aug 2005 Stickyminds.com article on Building an Effective Test Team for Distributed Agile


• Malcolm William's 2004 Master's thesis on Distributed Extreme Programming: Extending the Frontier of the Extreme Programming Software Engineering Process


• Follow the Sun: Distributed Extreme Programming Development from Agile2005, by Monica Yap (also see the powerpoint presentation)


• Naresh Jain's Offshore Agile Maintenance (summary, presentation, and experience report all available from this link)


• Distributed Agile, a 2004 presentation by Christoph Steindl


• Internationally Agile, 2002 paper by Matt Simons


• Summary results of March 2003 USC Workshop on Large-Scale Distributed Agile Development


• Support for Distributed Extreme Programming by Frank Maurer et. al., XP2002 (also see a related paper on the same subject)


• eXtreme Programming in Open-Source and Distributed Environments


• Follow-up paper to the above (same authors): Distributed eXtreme Programming paper from XP2001 conference

Also, although it's not specific to Agility, the book Software without Borders appears to have some good reviews by several folks who are well-respected in the Agile community (also check out the online references section of the book.

Scaling Agility: Agile Program Management

Over the past months I've come across a bunch of good links & papers on the topic of "Going Agile" at the program-level:

Michele Sliger (of Rally Software Development) has several good articles and presentations on Relating PMBOK Practices to Agile Practices

• Relating PMBOK Practices to Agile Practices - Part 1 of 4
• Relating PMBOK Practices to Agile Practices - Part 2 of 4
• Relating PMBOK Practices to Agile Practices - Part 3 of 4
• Relating PMBOK Practices to Agile Practices - Part 4 of 4
• A Project Manager's Survival Guide to Going Agile
• The Agile/Waterfall Cooperative

On using Agile methods in organizations with a stage/gate approach to program management, see some of Per Runeson's work in this area:

• Combining Agile Methods with Stage-Gate Project Management
• Integrating Agile Development into Stage-Gate Managed Product Development

Murray Cantor has some good papers on Governance and Variance as it applies to Agility:

• Estimation, Variance and Governance
• Governing the Business Process of Software and Systems Development
• Systems Engineering & Architecting Challenges: Application to Agile Development
  

Some other papers & resources:

• Challenges of Migrating to Agile Methodologies
• Management Challenges to Implementing Agile Processes in Traditional Development Organizations
• Wikipedia page on "Adaptation of Agile methods"
• Agile Project Management Methods for IT Projects (by Glen Alleman)
• Agile Project Management Methods for ERP (by Glen Alleman)
• Agile Program Management: A Critical-Chain Multi-Project Solution (by David Anderson)

Those interested in some advanced agile planning concepts should look at Jeff Sutherland's paper on Scrum II - The Future of Scrum: Parallel Pipelining of Sprints in Complex Projects (and the presentation slides that go with it)

There are several REALLY GOOD whitepapers on Adopting & Scaling Agile at Rally's Agile Knowledge Portal, including the following in particular:

• Five Levels of Planning ... To Agility & Beyond
• Tactical Management of Agile Development: Achieving Competitive Advantage
• A CIO's Playbook for Adopting the SCRUM method of Software Agility

There's gotta be some other good stuff out there and Agile Portfolio, Program and Multi-Project Management! If you know of any - please add a comment and hyperlink or URL!

Scaling Agility: Agile Systems Engineering

Over the past months I've come across a bunch of good links & papers on the topic of "Going Agile" at the program-level for large systems and systems of systems. Some of these relate to Agile program Management and others are more about Agile Systems Engineering (and some relate to both). I'll mention the ones on Agile Systems Engineering in this blog-entry and leave the ones on agile program management for a subsequent entry:

• Barry Boehm's XP2006 Keynote: Product and Process Architectures for Integrating Agile and Plan-Driven Methods
• The Future of Systems Engineering and Software Processes
• A View of 20th & 21st Century Software Processes
• 21st Century Processes for Acquiring 21st Century Software-Intensive Systems of Systems
• Some Future Trends and Implications for Systems and Software Engineering Processes


• Guidelines for Lean Model-Based (System) Architecting and Software Engineering
  
• Agile COCOMO II Cost Estimation
  
• Systems Engineering and Architecting Challenges: Application to Agile Development, by Murray Cantor
• Integrating Agile Methods, and Teaching the Elephant to Dance: Agility Meets Systems of Systems Engineering and Acquisition from the CSE 2005 Annual Research Review


• Agile SYSTEMS ENGINEERING versus AGILE SYSTEMS engineering
  
• Fundamental Principles for Agile Systems Engineering


• Agile PM and Systems Engineering, by Glen Alleman
  
• Large Project Management as a Systems Engineering Discipline, by Glenn Alleman
  
• Lessons Learned Using Agile Methods on Large Defense Contracts
  
• Agile Systems Engineering for Creative Anti-Terror Solutions
  
• Engineering Complex Systems @ MITRE

That's the best I came up with. If you know of other good links on this topic, please send me a comment!

Scaling Agility: Adapting Agile to the Organization

Here is a list of resources I've found that I feel are applicable in figuring out how to scale Agility for a large organization and project. (On the subject of metrics and values, I personally find Sam Guckenheimers work to be of greatest interest):

• A Value-Up Paradigm, by Sam Guckenheimer
• Appropriate Agile Measurement: Using Metrics and Diagnostics to Deliver Business Value
• Scaling Agile Methods (IEEE Software Paper) [also see a related paper, and its presentation slides]

• Scaling Agile Processes (slides), Jutta Eckstein [also see the Intro from Jutta's book Agile Software Development in the Large]
• Supersize me by Scott Ambler
• The Agile System Development Lifecycle, by Scott Ambler
• Scaling Agile Software Development for Larger Projects, by Steven Thomas
• Scaling Down Large Projects to meet the Agile sweet spot, by Phillipe Kruchten (also see corresponding presentation slides)

• Using an Agile Approach in a Large, Traditional Organization, Dot Tudor & George A. Walter, Agile2006
• Agile Can Scale: Inventing and reinventing SCRUM in Five Companies, by Jeff Sutherland
• Agile Software Development Across the Entire Project, by Granville Miller
• System Analysis and Design in a Large-Scale Software Project: The Case of Transition to Agile Development
• Extending Agile Methods
• How BMC is Scaling Agile Development

• Introducing Lean Principles with Agile Practices at a Fortune 500 Company, from Agile2006
• Three-Way Cultural Change Introducing Agile within Two Non-Agile Companies and a Non-Agile Methodology
• The Agile Marathon, by Bob Schatz and Ibrahim Abdelshafi, Agile2006
• Agile at Scale: 7+7 Practices for Enterprise Agility
• 5 C's of Agile Management

• Calculating Earned Business Value for an Agile Project
• Driving Agile Adoption through Audits?
• Seven Agile Team Practices that Scale
• ShopZilla Scales Software Agility

• Lessons Learned using Agile Methods on Large Defense Contracts
• Bridging Agile and Traditional Development Methods: A Project Management Perspective
• Army Simulation Program Balances Agile and Traditional Methods With Success
• A Governance Model for Incremental, Concurrent, or Agile Projects

Additions and corrections are welcome!

Scaling Agility: Seamless Agility across the Enterprise

David Anderson writes about the recent Agile2006 conference in his blog-entry Thoughts for Agile2006:

Scaling Agile. The BIG issue for this year is scaling agile across a whole organization. I see this as having three parts - program or multi-project management and the rollup of schedules and resource plans to a Director or VP level; architecture and enterprise level modeling of a domain and data center; and finally configuration management including build, integration, branch and merge strategies, and work-in-progress batching and related communication.

Ive been dealing with this topic a LOT lately in my own organization as part of efforts to spread amd adapt Agile methods across a large distributed enterprise working with large systems and teams. Ive been researching and collecting lots of resources, including some earlier blog-entries on Agile CMMI and Dancing Elephants and Agile Adoption across the industry.

My perceptions of where the "seams" of the enterprise are that are hardest to introduce Agility into are the close collaboration and alignment required across organizational (lifecycle discipline) boundaries and geographic boundaries (and I find the former to be more difficult to surmount than the latter.)

If I try to categorize them as different areas or aspects that each require the ability to be agile, I come up with something like:

• Process - Adapting Agile to the Organization (making processes responsive to change)


• Product - Agile Systems Engineering/Architecture (making the requirements & architecture be responsive to change)


• Project - Agile Program Management & Governance (making the project be responsive to change)


• People - Distributed Agile Development (collaborating across multiple sites, teams, and timezones)


• Organization - Agile Metrics/Reporting, Governance, and Organizational Design
  


• Environment - Agile CM, deployment, operation/support, etc.

I'll be blogging separately with lists of resources of found for several of the above.

TEA-Time - a metric to elicit TDD behavior?

I've been thinking about a metric that might elicit Test-Driven behaviors in my organization. As a first step to TDD, we definitely want folks to create automated tests as much as feasible and execute them frequently. Once they get that, I've been thinking about what sort of metric might encourage them to actually work in short, test-driven cycles, where requirements are elaborated test-by-test (given a use-case or story, write the first test, write the code to pass the test, refactor, rinse-lather-repeat).

Some of these folks are very much ingrained in a systems engineering V-model lifecycle that does a lot of big-requirements up-front. So ensuring they work to automate tests and execute them frequently isn't enough to enourage them to use an interative approach of fine-grained TDD-style elaboration. An idea I had for what to measure is something I chose to call Test-Execution Availability Time, or TEA-Time (I figure if nothing else, my friends in the U.K will like the name :-).

As proposed, Test-Execution Availability Time (or TEA-Time) would be defined as the mean time between when a system requirement description is first baselined, and the time at which a "sufficient" number of automated tests for the requirement were implemented and ready (available) to be executed.

I was thinking that if a group was measuring this and wanted to behave in a way that minimized TEA-Time, it might encourage them to elaborate requirements in an iterative and incremental fashion, in smaller and smaller "functional slices". One thing I'm not sure of is what "a sufficient number of automated tests" should be in the above.

Any thoughts or comments?

REVIEW: Practices of an Agile Developer

Are you a developer who wants to improve your personal development habits in a way that helps not just yourself, but also incrementally improves your project and your team? If so, then run, don't walk, and get your hands on Practices of an Agile Developer: Working in the Real World by Venkat Subramaniam & Andy Hunt, from the Pragmatic Programmer's Bookshelf.

Want to know more about why? Then read the complete review in the September issue of The Agile Journal (the theme for September is Collaboration and Reuse).

Agile CM on YahooGroups

As mentioned in an earlier blog-entry, I have created an Agile CM Yahoo Group. The description is:

The agile-cm group is for the discussion of ideas relating to Configuration Management for Agile development and of applying Agile concepts, methods and tools to the practice of Configuration Management itself (and CM "Patterns"). This includes aspects of CM that relate to agile development, refactoring & design patterns, agile project-management, Lean, Theory of Constraints (TOC), even SixSigma and CMMI to the extent that they can help CM and related practices to be more "agile".

As I wrote earlier, I hope this new agile-cm group will have a healthy balance of both SCM folks and Agile development folks so we can have some constructive multi-faceted discussions.

How I Blogged my Summer Vacation

Some of you may have wondered what the heck happened to my blog during August and the first half of September. Well - I lost some write-access to my website for a lot of the summer (while my host was recovering from a denial of service attack) and I couldn't login and update it.

I had several blog-entries "queued up" simply needing some final cleaning-up before I made them live, and that got interrupted, then I couldnt access them, then I had some vacations/travel, then I needed to "catch up" when I got back to work, and so on ...

So over the next week or two I'll be "pushing out" the entries I wrote-up in August, using the date they were originally written. I'll also be making available the talk I gave in July at Architecture & Design World 2006 on the subject of "SCM Patterns for Agile Architectures."

In October/November I may not be blogging much at all as I'll be trying to recover from major surgery (I'm giving one of my kidney's to a family member).

Relating SCM Patterns to SCM Principles

Our August Agile SCM column in the CM Journal is about Relating SCM Patterns to SCM Principles. The article is pretty flimsy, barely a skeleton, and that's pretty much entirely my my fault. I meant to write more "meat" about how certain principles are the underlying forces behind several patterns. I wanted to show how the principles are strongly related, much the same way patterns in a pattern language are related. And I wanted to show how that structure shaped the relationships between the patterns as well. Rob did a really good job trying to put together what I had with what he could come up with, but I didn't really give him enough and couldn't easily convey it in a way that made it easy for him to "run with it!"

It's not that I don't see those relationships, I do. And I'm not lacking for words to describe them either. I'm having trouble describing them clearly and concisely. A big part of that is because I still don't like the names of the SCM Principles as I've described them so far. Their names currently relate to the OOD Principles they were derived from. I think that might speak to programmers, but not to folks trying to do version control (even if they also wear "developer" hats). I really want to go back and rework the names of the principles to be more simple and direct.

This is something Ive been working in my mind on and off for alkmost a decade now. To me, it is of profound important - perhaps even the most significant contribution I'll have made to the field of SCM to date. THe interest level doesn't seem to be so high on the scm-patterns list and the cmcrossroads.com forums (but that hasn't deterred me - yet :). I really do think it's not a coincidence that principles of object-oriented design also manifest themselves as fundamental principles of SCM solution design (because I think both are all about architecture - and minimizing and managing dependencies).

I'd really like feedback. On this stuff so if you've had a chance to read thru the June, July and August Agile CM columns, I'm going to create a new YahooGroup about Agile-CM for discussing these and other Agile CM issues. Hopefully this new agile-cm group will have a healthy balance of both SCM folks and Agile development folks so we can have some constructive multi-faceted discussions.