"If I have seen farther than others, it is because I was standing on the shoulders of giants."
I think it's important, in the interest of educating the public, as well as improving the state of the art, to share hard-won knowledge. With that in mind, I thought I might share a couple of tidbits from my own experiences, both with the FDD process itself, and with trying to track it.
I feel that the importance of choosing class owners carefully is a bit understated in the existing literature. In classes with Steve one day, he had us form a mock implementation team, and try to assign class ownership, and then schedule chief programmer worksheets and team assignments. The group I was a member of was, I felt, spending far too long trying to decide who should own what classes. The two CPs were trying to wrangle for important classes, because they felt the need to have some architectural control over the whole system. In the interests of getting the phase over with, so we could move on, I put on my Dictator Hat and randomly assigned classes to the teams, including giving the two CPs the classes they'd been eyeballing.
We quickly discovered this to be a big mistake: it turned out that one of the CPs ended up being in almost all of the other CP's worksheets, and in the reverse situation, a third of the worksheets needed both CPs. This drove home the lesson far more intensely than the admonitions made in the class and in the literature: key classes should not be owned by a Chief Programmer.
The second lesson to report is in the realm of tracking feature milestones. It may come as no surprise to hear that features in the same worksheet tend to reach milestones as a single group, or sometimes two. Generally, a worksheet will deal with one part of a functional area (approximately, a feature set, perhaps two). As such, there is typically only one design document, perhaps two, and so a single design review should suffice for a given worksheet. If the milestones are clustered together, that means that data entry also will be clustered together.
In the original implementation of Galileo, milestones were editted on the feature edit page. You could thus enter two milestones for one feature in a single edit, but you'd have to go to each and every feature edit page to update the status of a worksheet. But the path from viewing a worksheet to editting a feature and saving it took far too many mouse clicks. This typically resulting in the CPs doing bulk data entry on friday afternoon, both because it was a painful process, and waiting until a feature had passed several milestones meant only one edit was necessary per feature. This, however, left you little indication of how the week had gone until it was over.
In the second version, we added breadcrumbs to the top of each page, and the ability to get directly to edit pages from any of the table views, reducing almost by half the number of navigations necessary to perform the task. This helped a bit, in that bulk entry took less time, but it didn't discourage the practice.
What was needed was a way to enter milestones on multiple features at the same time. On a spreadsheet, this is easy enough to do by copying and pasting data from row to row. In a web application, this gets a little more complicated.
However, on further consideration, it seemed to be the case that you didn't necessarily -need- to enter arbitrary milestones on multiple features. You just needed to be able to set the -same- milestone (and date) on multiple features. Because walkthrough, design, design review, and code review were usually occuring lock-step, this would be good enough so that only one or two edits were normally required to update the status of a worksheet, instead of one per feature.
So, we came up with an edit page for the worksheet that had a choicebox for the milestone type, the necessary date/comment fields, and a pick list of all of the features in the worksheet (all of which were selected by default). This made the CPs far happier than they anticipated from the initial description, and now progress started appearing in the database on Tuesday afternoon, instead of Friday at 3:30 pm.
Determining Class Owners
Sounds like you exposed a few issues here, and not all FDD ones!
If you've got two CP's "wrangling" over class assignments, then they aint CP's. Replace them. I don't know if the problem was politics, or personalities, or whatever, but it had no place there. They are supposed to lead by example.
But anyway, class ownership is not something that's haggled over by "the team". Software construction is NOT a democracy: someone makes a call and that's it. In this case it sounds like precisely what you did: made a call. But that's how it should have been, someone in the role of dev manager making these decisions.
And the "not-so-random" random approach does highlight one of the factors you'd need to consider when doing this, but there are others. You mention one further down: that CP's shouldn't own key classes. Absolutely! From experience we've found that a CP spends about 50% of their time doing CP stuff, and 50% developer stuff. They are certainly harder to schedule than most other developers.
We do consider things like class complexity, and high-use classes, and balance this with developer experience levels and the number of classes owned. So it's not uncommon to see a more experienced developer owning less classes, but they might be very complex ones or very high use. Conversely less experience developers might end up with loads of classes, but many of them might be low complexity or low use.
There is a balance here though: you can't do it all this way. Junior programmers will never be given the chance to learn and extend themselves doing nothing but boring simple stuff, and at the other extreme even the gun programmers need a balance of classes so they're not going to be sitting idle when the heavy stuff isn't being worked on.
Remeber also that class ownership can change over time! Use common sense - it's not set in stone.
As for them trying to maintain some kind of control - it sounds like there was no clear Chief Architect or Dev Manager roles already assigned. That would have made it very simple.
It also sounds like these folk had forgotten just how processes 4 and 5 - Design and Build by Feature - really work. The CP is the one that forms the feature team, and kicks it off. They lead the design, and are responsible for the sequences that are done by the team. They are the integration point for the development, and responsible for ensuring that adequate testing and inspections are carried out. The surgical team structure from Fred Brooks and Harlan Mills ensures there are plenty of CP to developer communications going on all the time. The bottom line is that the CP doesn't miss out on the fun just because they aren't a class owner for that work package.
Again experience comes into it. In practice, when you're doing the planning in process 3 you already have a features list. I find I use this to guage what will be high-use classes: just eyeball the features and any CP will be able to instantly identify the key classes involved (in practice anyone who's participated in process one will be able to!). From the way the feature lists are written, you can almost being to see "chunks" of features that will most likely be worked together.
Once you have the target MM/YY dates for business activities, you can do a quick mental validation of your planned class ownership. Looking at the plan and the number of CP's the "streams" of development usually become clear, or the PM decides on the approach. Within those the target dates indicate what sequence business activities will be kicked off. Within this framework we can visualise the chunks of features going through processes 4 and 5 - Design and Build by Feature - together. Most often class ownership contention will jump out at you at this stage, certainly for high-use classes that tend to straddle more than one of the "streams" of development. These often turn out to be the key "pink" moment-interval classes.
Code Ownership
The comments you cite concerned developers who were going through FDD training exercise, not developers on an in-progress FDD project. The impact of seeing how badly the scheduling problems got was quite profound. I think this situation is a good example of where experience is sometimes the best tutor. When next I find myself in the presence of people learning FDD, I hope to be able to recreate a similar scenario.
As for the issue of code ownership, I think it's a more productive arrangement to say that the 'owner' is the person (or persons, more on that later) responsible for a piece of code, NOT the only one who is ever allowed to touch it. In some situations, time constraints may be such that it's sufficient to propose a change to a class to the owner, and get approval to implement the discussed changes yourself. In the case of junior programmers, such a philosophy is advantageous, because rather than carving off a block of files for them to own, and risk giving them more than they can handle, or not enough to keep them occupied and growing, you can simply assign them piece work in other developer's classes, where they can get hands-on mentoring.
One of my better managers over the years (one Bill Bohlman) had a favorite saying, "Anything worth doing is worth TWO people doing." This was not so much a summation of the XP philosophy of pair programming (though he was fond of XP), as a belief that no one person should be allowed to be either a productivity or informational bottleneck to the company. In my opinion, FDD's code reviews don't adequately address the problem of information exchange. Similarly, the code ownership and worksheet scheduling don't address the bottleneck problem sufficiently.
I think in a real world, where people get pulled onto multiple projects, don't keep precisely the same hours, and occasionally find employment elsewhere, there's significant danger in assigning code ownership to a lone individual. You'd be better off giving two developers ownership of a package, and let the ownership of the specific files be fluid. Even in the case where you are mentoring another programmer through altering your code, three participants are well below the communication breakdown threshold, and if you're careful about who you pair, you should also be able to avoid problems of conceptual integrity.
-Jason
Optimise for the bigger problems
Conceptual integrity is hardly a problem to be solved at the level of an individual class. Scaling a project and maintaining the conceptual integrity of the whole is one of the great challenges Brooks wrote about in Mythical Man Month and for which Mill's Surgical Teams can be a solution. This is (in part) the inspiration for FDD's Feature Teams and Chief Programmer role. The CPs, as a matrix structure (and in concert with their role in the startup phase processes) directly address conceptual integrity of the whole (amongst many other things that CPs address).
It's hard for me to see what your point exactly is. If it's simply that a pair is less of a bottleneck than ONLY ONE class owner, then ok what do you do if both of the pair are not around, or they themselves work different hours, or...? It's easy to contrive scenarios that break any commonsense guideline - such as class ownership.
When I teach this, I never say there can't be more than one class owner. I also explain that class ownership, of course, can and does change over time. Commonsense always applies. It is simply a point of bias. I am, and FDD is, heavily biased to the concept of class onwership versus the concept of team or collective ownership. You get much better consistency of interface and implementation when using the concept of class ownership. This is far from a new concept. The concept of module or component ownership has been known and practised for decades. Go visit the better programming labs that do systems development (e.g. IBM). If you've got a problem or query to do with object distribution facility on the AS/400 you go visit the NF component owner (for example). Not any one of the 800+ OS/400 developers or whoever happened to touch it last.
I'd much rather use "management commonsense" in assigning class ownership and in people management to deal with issues of working hours and so on, rather than lose the very essence of encapulsation in practice - the class owner.
Finally, the inspections in FDD involve many more eyes than a "pair" and in many, many more combinations (feature teams are forming and reforming all the time). It's very hard to see how this results in less information exchange as compared to a "pair".
?
You aren't easily blocked by a class owner not being around. You have the CP that actively mentored that class owner and led the inspections and you have any other class owners involved in the inspections. Note that it's not even necessarily a one to one relationship between a CP and a class owner...
?
A matter of definitions
I guess one of my points, neatly stumbled upon at this late date, is that the definition of ownership varies significantly, even within the FDD literature. The other is that even a team is not all-seeing, reviews notwithstanding.
Ownership, in the realm of property, means a high level of sovereignty, moreso than being, for instance, the curator. Many groups in the software community have adopted this connotation, but the (or perhaps just my) confusion does not end there. In the section on code ownership in the Palmer-Felsing book, the cons list for ownership implies just this definition. Additionally, the high level of attention paid to how code ownership impacts Feature Team formation implies that the code owner should must be available for membership in any team that requires his or her code.
It's also not clear to me that the CP is in a mentoring role with the class owner. In my limited experience, each team has at least one member who is as technically adept as the CP, if not bearing the same organizational or interpersonal skills. In these cases, the owner is deferring to the CP on conceptual integrity alone. There is no mentoring, their experience and relative autonomy means they are responsible for a disproportionate fraction of the work done by the team. The CP's exposure to a not insignificant fraction of the code being written is thus limited to the reviews.
In our organization, the rigor of these reviews is directly proportional to how critical the code is, and so the team is very familiar with 20% of the code, yet much of the remainder is largely known only to the author, not because they have never shown it to anyone, but because the introduction was informal enough that the information is ultimately lost in the noise of day-to-day responsibilities, and over time. When all these factors are taken into account, it is likely that the CP won't have a clue as to what's really happening in half of the code their teams have written throughout their employment.
A CP is a mentor. A class owner owns a class.
What FDD literature has different definitions of class owner? (from memory) Chapter 6 of the JMCU book does not define it, nor does (from memory) the FDD chapter in Highsmith's book. I've not read the Palmer book, but since you mention it is defined there then that is the only definition within the FDD literature.
Your description of the Palmer definition sounds right to me. I don't see it at odds with what I've told you.
The class owner is the owner of the class. They are selected for features that involve that class. There can be, although it is not the majority case, more than one owner for a class. Class ownership can change over time.
A CP is absolutely in a mentoring role with the class owners for that feature team. This is absolutely fundamental to the whole structure and to FDD. This is one of the other reasons for the CP and Feature Team structure. It has been reported many times over the years the wide variations in performance of programmers. Anywhere from 10-50 times for the good ones. In FDD, the CPs are the good ones and the nature of the CP to Developer communications and the role the CP is playing (actively mentoring the developers, the integration point for the design inspection, the integration point for the code inspection, the integration point for the promote to build) is that I want as many interactions as possible from CP down to Developer to transfer as much of that 10-50 times performance as possible.
In the early drafts of chapter 6 of the JMCU book, the non-coding part of what a CP does was described as 40% of their time (I don't think this ended up in the published version). I think you'll find experienced FDD CPs such as Paul Szego might say it is closer to 50%.