The Trouble with Traceability

I've taken many of my thoughts from my previous blog-entries on traceability and expounded & expanded upon them in my May 2005 "Agile SCM" column of CMCrossroads Journal. The article is entitled The Trouble with Tracing: Traceability Dissected. It describes:

• Ten Commandments of Traceability
• Nine Complaints against Traceability
• Eight Reasons for Traceability
• The Seven Functions of SCM:
  
• The Six Facets of Traceability
  
• The Five Orders of Traceability
• The Four Rings of Stakeholder Visibility
  
• Three Driving Forces for Traceability
  
• Two Overarching Objectives: Transparency & Identification
• One Ultimate Mission: Fostering a Community of Trust
  

On a separate note ... I recently realized that the order/date on which I first author my blog-entries has been very different than the published date of the entry. I was saving them, but not publishing them.

Normally I may take a day or two to "clean-up" an entry (add the URLs, fix the formatting and fight with the WYSIWYG blog-composer) and publish them within a couple days of creating them. But we had a grave illness (and then death) in my family that consumed most of May for us, and I didnt realize until recently that my blog-entries for the last half of April and most of May hadnt been published yet.

So for that I must apologize. And I'll try to do better about publishing more regularly (ideally at least weekly).

Situational Ownership: Code Stewardship Revisited

I had some interesting feedback on my previous blog-entry about Code Stewardship. Most apparent was that I utterly failed to successfully convey what it was. Despite repeated statements that stewardship was not about code access, it seems everyone who read it thought the code steward, as described, was basically a "gatekeeper" from whom others must acquire some "write-token" for permission to edit a class/module.

I am at a loss for what to say other than that is not at all how it works. The code-steward serves as a mentor and trail-guide to the knowledge in the code. Consulting the code-steward is not about getting permission, it is about receiving knowledge and guidance:

• The purpose of the protocol for consulting the code-steward is to ensure two-way communication and learning (and foster collaboration). That communication is a dialogue rather than a mere "token" transaction. It's not a one-way transfer of "control", but a two-way transfer of knowledge!

Perhaps I would have been better off saying more about how Peter Block defines stewardship in his book of the same name (Stewardship: Choosing Service over Self-Interest, see an interesting review here and another one over here):

• Stewardship is being accountable to the larger team or organization by "operating in service, rather than in control, of those around us."
• "We choose service over self-interest most powerfully when we build the capacity of the next generation to govern themselves"
• Stewardship offers a model of partnership that distributes the power of choice and resources to each individual.
• Stewardship is personal - everyone is responsible for outcomes; mutual trust is the basic building block, and the willingness to risk and be vulnerable is a given.
• Total honesty is critical. End secrecy. Give knowledge away because it is a form of power

When practiced properly, collective code ownership is in fact an ideal form of stewardship (but not the only form). Stewardship may ultimately end-up as collective-ownership if given a sufficient period of time with the same group of people.

However, early on I would expect stewards to have a more direct role. And I believe the form of code-ownership that Feature-Driven Development (FDD) practices may seem fairly strict at first, but is really intended to be the initial stages of code-stewardship in the first two quadrants of the situational leadership model.

I beleive the form in which stewardship should manifest itself is situational, depending on the skill and motivation of the team and its members. In Ken Blanchard's model of situational leadership, there are four quadrants of leadership-style, each of which should be used on the corresponding combination of hi-lo motivation and hi-lo skill for a given task:

• Directing (hi directive + lo supportive, for "enthusiastic beginners")
  
• Supporting (hi directive + hi supportive, for "disillusioned learners")
  
• Coaching (lo directive + hi supportive, for "reluctant contributors")
  
• Delegating (lo directive + lo supportive, for "peak performers")
  

If we apply the concepts and principles of "stewardship" using the appropiate situational leadership-style, the outwardly visible result may appear to transition from individual code ownership, to code guardians/gate-keepers, then code coaches/counselors, and finally to truly collective ownership.

So I would say it is the presence of stewardship which is the key to succeeding with either individual code ownership or collective code ownership. If stewardship is present, then both can succeed; If it is absent, it's likely that neither will succeed. And the collective and individual "styles" are the extreme ends of the spectrum, with "code counselors" as the style in between those two extremes.

Dreamy SCM Patterns Superheroes!

My SCM Patterns co-author and I received an honorable mention in the letters-to-the-editor section of The June 2005 issue of Software Development Magazine. The April issue had an article about the software development "dream team," giving nicknames and characteristics of these fictitious "software super heroes."

In this month's letters section is an letter from Curtis Yanko entitled "Team Member Missing" ... Curtis writes:

I just read 'The Dream Team' (Apr 2005), and while I found it informative and entertaining, I couldnt help but feel a little empty. I expected Software Development, of all magazines, to recognize the importance of the configuration manager. This superhero would mix Martin Fowler's appreciation of adapting the right amount of agility for any given team with Stephen Berczuk and Brad Appleton's understanding of SCM patterns. Automated builds and continuous integration are what will really allow this Dream Team to make super-human progress!

Many thanks Curtis!

Single Codebase - How many Codelines?

On the YahooGroup for the 2nd edition of Kent's Beck's book Extreme Programming Explained, Kent described a practice he calls Single Code Base:

There is only one code stream. You can develop in a temporary branch, but never let it live longer than a few hours. Multiple code streams are an enormous source of waste in software development. I fix a defect in the currently deployed software. Then I haveto retrofit the fix to all the other deployed versions and the active development branch. Then you find that my fix broke something you were working on and you interrupt me to fix my fix. And on and on.

There are legitimate reasons for having multiple versions of the source-code active at one time. Sometimes, though, all that is at work is simple expedience, a micro-optimization taken without a view to the macro-consequences. If you have multiple code bases, put a plan in place for reducing them gradually. You can improve the build system to create several products from a single code base. You can move the variation into configuration files. Whatever you have to do, improve your process until you no longer need them. [... example removed ...]

Don't make more versions of your source code. Rather than add more codebases, fix the underlying design problem that is preventing you from running from a single code base. If you have a legitimate reason for having multiple versions, look at those reasons as assumptions to be challenged rather than absolutes. It might take a while to unravel deep assumptions, but that unraveling may open the door to the next round of improvement.

Kent is equating creation of a new codeline with establishing a new code base within the same repository. He does so with good reason: creating a new codeline for supporting a legacy release and/or multiple customer variants is indeed creating a new project instance, complete with its own separately evolving copy of the code.

I posted a lengthy response to Kent's initial description of a Single Code Base. I feel I understand Kent's position intimately well. At the same time I think that having to support one or more legacy releases is a business constraint that is far more unavoidable then Kent's post seems to suggest. I summarized my opinion as:

1. Transient branches are fine (even ones that last more than a few hours) and do not cause the waste/retrofitting described. But you do need to follow some rules regarding integration structure and frequency
2. Variant branches are "evil", and should be solved with good architecture/factoring or else configuration that happens at later-binding-time
3. Multiple release branches are often a necessity in order to support multiple releases. And supporting multiple releases is highly undesirable, but often unavoidably mandated by the business/customer

Under the heading of "Transient Branching", I include patterns like Private Branch, Task Branch, and "organizational coping" branches like Docking Line, and the Release-Line + Active-Development-Line pair. Another example (tho not short-lived) is Third Party Codeline. And of course if any branching is done, then proper use of a Mainline is essential (I think Mainline does for branching what refactoring does for source-code).

So while I vigorously agree with the desire against adding new codelines for supporting multiple releases, and that it's certainly good idea to question if it is truly necessary (and to fight "like heck" against using branches as a long-term solution to handling multiple variants), I think challenging the multiple maintenance constraint too vehemently isnt a great idea however once you understand the business need that is driving it.

We might still disagree with doing it, but at that point I think we need to "bite the bullet" and do it while perhaps exploring softer communication alternatives to persuade the business in the future. Part of that can be getting the business to:

• Fully acknowledge and appreciate that each additional supported release/variant is a bona fide new project with all the associated impliciations of added cost, effort, management, and administration. (Often a new variant-line or release-line adds 40%-80% additional effort to support and coordinate).
• Agree that if Multi-Tasking an individual is something that decreases productivity and flow by increasing interruptions and context-switching, then Multi-Project-ing the same team/codebase is an even grander black-hole that sucks away resources and productivity for many of the same reasons
• Agree that when we do decide to support an additional release/variant, the new project should have some sort of charter and/or service-level-agreement (SLA) that clearly defines the scope and duration of the agreed upon effort and its associated costs.

For some additional reading, see DualMaintenance and UseOneCodeLine on the original Wiki-web, and BranchingAndMerging, ContinuousIntegration and AgileSCMArticles on the CMWiki Web