I'd like to revisit (and hopefully reassert) the FDD view on version control, and configuration management.
In FDD we use the term "promote to build" as the final step in BBF, which directly refers to the action of promoting (re-labeling) a file in the CM system. Modern CM/VC systems such as Perforce and Microsoft Visual Studio Team System do not include the capability to do promotion groups and labeling. In a Perforce whitepaper, they explain that promotion groups lead to "bushy trees" which they describe as an anti-pattern.
I've seen some teams doing FDD advocate the notion that each Feature Team makes a branch for each Chief Programmer Work Package. This seems wrong to me. The claim is that modern tools make merging much easier than it was in earlier years and that the transaction cost of a branch and merge is almost zero.
I continue to observe teams that branch and merge suffer poorer quality than teams I observe practicing exclusive locking, class ownership and using promotion groups with FDD. In general teams using any engineering method and practicing non-exclusive lock and branch and merge seem to suffer poorer quality.
So, does the FDD community re-assert that class ownership is still the right model? and that configuration management using promotion groups is still the right model? and if so are there a number of modern CM/VC tools which would not be recommended for use with FDD teams? Are there any other suggested work arounds for FDD teams who may be forced to use a tool which does not support promotion groups? Or have modern tools obviated the original recipe for this from the Singapore project and do we need to embrace a new paradigm and rename "promote to build" as "merge the branch"?
David
Too many assumptions
Hi David,
I think if you check the process descriptions this is covered. To summarise, all FDD says about version control is:
- use some
- ensure your designs are checked in as well
- if possible, you can utilise it to implement Feature Team Area's
That's about it. I don't know how "we" get the "direct reference" to labelling files. This is not part of FDD. It's one approach that may be used given a particular toolset. I can't even say it's the most common approach based on what I've seen.
As for Singapore - Steve Palmer and myself spent some time trying out different ways to implement feature team areas given the constraints of that project. The idea was crystal clear, and not new. The first attempt involved shared directories on a LAN, with one directory per feature team. Later we looked at what tool support we could use, if any. Jeff delegated this task - he wasn't concerned with that level of detail. It didn't matter. Steve and I were left to work it out, with the famous "sort that #$%@ out" hand wave from Jeff ;) There are other threads on this site that discuss approaches to implementing Feature Team Area's - which is the real issue here.
To quote the FDD process description:
"The Chief Programmer creates a Feature Team Area for the features(s). This area is either a directory on a file server or a directory on their PC that is backed up to the server by the CP as required or utilises work area support in your version control system. The purpose of the Feature Team Area is that work in progress by the feature team can be shared and is visible amongst the feature team but is not visible to the rest of the project."
All the CP's and developers were accutely aware of this, as it was part of their daily life on that project. I'm not surprised you don't recall this - you didn't actually play any FDD role on that project, and so never had to worry about it.
Paul.
Premature branching is the root of all evil
(with apologies to Tony Hoare)
Branching for development activities is wrong. Very wrong. It indicates parallel development. Which means that 2 or more people are messing with the same piece of code. If that doesn't make the hair on the back of your neck stand up, then you're scaring me. Go find another career, please.
And I mean "messing with", not "coding". How can you be? You carefully consider the design - with object models and sequence diagrams and design meetings that carefully consider the alternatives. You document the design. Each class owner then carefully looks at how to implement their piece of the design, taking into account all the project and organisation's standards and "habits" and idioms and with full knowledge of what the rest of the class does, how it does it, and why it does it that way. And you creafully design your unit tests to get good coverage of the code, maybe even measuring it, and automating the tests so they extend the regression test suite.
And then... you go to "deliver" the code, and there's a conflict. So you have to merge two lots of changes. Here's what usually happens (I see it all the time): in the middle of checking in a dozen or more files, the tool helpfully announces that you need to merge something. It tried, but it's too hard, so you'll need to do it. And up comes a window with two (or even three!!!) versions of the code, side by side, that you can see a massive 40 or so lines of at once. And there's lot of pretty colours and controls and you whiz through resolving differences like mad. And you're done. Then it happens to another file. #@$%!!! So you do it again, but this time you can't make sense of it. So you just pick one lot of changes and cross your fingers. Then another file! Aaarghhh....
Usually by time you're done it's a wonder the code even compiles, let alone does what you want. And sometimes it doesn't even do that. The number of times the build has been broken due to an "automatic" merge that produced crap? PLENTY!
The bottom line is: it just doesn't work! But the really disturbing this - why are you making two lots of changes at once, to the same file? If you have class owners, then this would mean the one person is trying to do two different work packages at once - both involving the same file. Huh? We don't do that - that's what the CP planning is all about. So how do we avoid this? Simple - just don't do it! Really!
So it doesn't work, and it's a dumb idea. Then again, maybe this is just a case of premature optimisation? Hmmm...
As for FDD and Singapore - this aint a new paradigm (the "to branch or not" debate has been going on for ages, well before then) and the direction we took was not a recipe developed in Singapore - it's old as well. Very old. My first exposure to the concept was in the IBM labs - and I believe it was decades old then.
Class ownership and the feature teams (and feature team areas) are central to FDD. What tools you might decide to use (or not) hardly changes whether the approach is valid, if it makes little difference whether you use the tools or not.
Paul.
So your view on continuous integration is...
So, clearly in the USA there is debate amongst people who tried or used FDD and have exposure to other agile methods. There have been plenty of comments at my website and in my Yahoo! group observing that "very few FDD teams practice class ownership."
Would you assert that continuous integration and build verification testing is not the answer that allows branch and merge in FDD? In FDD it still makes most sense to have class ownership, period?
Is there anything special about FDD that means it works best with class ownership or do you feel that class ownership (based on analysis and design) ought to work best in general circumstances?
Why do you think there is a trend with modern tool vendors to only support branch and merge and not support alternative methods of configuration management?
David J. Anderson
author of "Agile Management for Software Engineering"
http://www.agilemanagement.net/
That's not FDD
Hi David,
the bottom line is that you're not doing FDD if you aren't doing class ownership. It's fundamental - many, many techniques rely on this. One example: feature teams - we figure out who's going to do the work for a feature based on who owns the classes that will be impacted. Another example: CP planning and scheduling. There are plenty of long threads on this site you participated in that discuss the finer points of the "flow" of DBF/BBF and how the CP's plan ahead to ensure the pipeline is full.
My guess is that someone not doing class ownership hasn't had a proper introduction to FDD. If you think you get it - but think that class ownership is optional - then you don't get it. The only variation on this is when projects get really small (which is also discussed elsewhere on this site), in which case the ownership can be assigned in larger chunks, e.g. entire packages.
So yes, class ownership does make sense in FDD. Continuous integration and verification testing make no difference - for the same reasons I said before: the tools are irrelevant. Despite what many tool vendors would tell you, the tools are meant to support the way you want to work - and NOT the other way around. I practice both of these things on all my projects (given the choice), but I don't ever want to do branch and merge.
There is something about FDD that makes class ownership work: everything! FDD isn't some arbitrary set of practices that look good on paper to an academic. They are built from over 20 years of Jeff's experience, and that's from "standing on the shoulders of giants". It is a set of techniques that work well together - and this is the key. The pracices complement each other in ways that aren't immediately obvious (some of these take years to fully appreciate, or maybe I'm just slow).
Class ownership works because we did the initial modelling, and the way we did it. Feature teams work because class ownership is possible, and because we have a features list. The naming template as a guideline for feature naming makes all of those things easier. CP planning is possible becase of both class ownership and the features list (with the breakdown). The reporting, which is almost free, works because all of thise things. The list goes on and on.
Would it work in general circumstances? I don't know, and I don't really understand the value of the question. If you want to start picking apart the individual pieces of FDD and trying them out on a real live project - go ahead. But there's no guarantee that this is useful, or even going to improve your chances of success. So why do it?
If anyone has done this, or you are one of the "plenty of others" that do this "FDD without class ownership" I'd love to hear from you. Relate some real experiences and I'd love to compare and contrast. What worked for you? What didn't?
As for tool vendors - you make an assertion that this trend exists, but I'm not sure what data that's based on. I don't see it, and would be interested to hear why you think this is so.
Paul.
No - we don't
I don't know who you mean by "we" here, but: No. Promote to build does not mean re-labelling. That's just one possible implementation in one specific case, but this is not the level of the process. And from there you leap to a promotion group. What's that? Paul correctly quoted what the FDD process says about this and that's the right level. You seem to be mixing in tools and some wrong assumptions - such as asserting FDD requires promotion groups. Tools are a separate issue as Paul has also correctly pointed out.
Anyway, I can't add much to the details of this discussion as Paul is right and he has more of the details than I. For me those details are a "hand wave" (tm). Steve Palmer and Paul Szego worked out the details of an implementation in Singapore, but even there it changed over time. It was done with just a file share on a file server originally.
All I did was know the shape of what I wanted and the outcome. It was influenced by my experience in IBM labs and by Paul's experience in IBM labs where they understand very well (have done so for a long, long time) these issues.
Frankly, the notion that anyone could put forward the idea of branching per feature or workpackage is frightening.