Does class ownership really work? Suppose implementing a feature affects classes A, B, and C which are all owned by different class owners - different people in this case. Each class owner makes the modifications necessary to his class, adding methods and attributes, changing signatures, etc... Each developer promotes his work to the shared workspace.
- Who assures that this workspace compiles?
- Even when doing extensive design in the DBF process, how assure that these 3 classes will cooperate as needed?
- And most importantly, who is responsible for testing this feature?
- In short, does class ownership really work?
Rudy
Does class ownership really work
It works becouse all code owner participate in all phases of DBF. In the end, of DBF methods inputs/ouputs, exceptions rules, etc, are agreed and all code owners fully understand how messages are to be called. Note, that lifecycle BBF/DBF is for each feature within selected in the WorkPackage. The feature team is also small, so communication is focused and easy to manage.
Each, programmer as a copy of the code in the shared area. So he can compile and do whatever. As new classes are developed, the programmer can get them from the shared area to his sandbox, compile and check if everything is correct with his class and if dependicy rules are being followed.
It may also happen, the the programmer is reponsible for all classes in a sequence diagram, or several sequence diagrams. The art is in defining who owns/responsible what like in everything.
Having said this, this strategy does not work if staff is volatile. That is, the same programmer is assigned to work on multiple projects. Also is not resilient to holidays, flews or any other kind of phenomena requiring his absence. This can mitigated if you establish that code ownership and class can be 2 to one relatioship.
Nuno Lopes
Chief Programmer
Don't forget the role of the Chief Programmer. He is not just there to say, you code this, you this and you this, and I code this. He actually supervises the all thing (team work).
Nuno Lopes
Team work and the CP
Bottom, line the Chief Programmer is responsible for the delivery of a full working feature. He is the pivot and the manager of the Feature Team. He does whatever it is needed to assure the delivery.
I believe that the CP is the most important role in development. In small to medium development projects, the CP is often wrongly called the Project Manager becouse it is a coincidence that in this scenario only one CP and one PM is needed (Custom Development Consultants often use this label). Technically CP is more adequate in my view, but it does not ring a bell to customer's in small projects (2-4 people). But in bigger projects, the separation between the CP and the PM scales better, that is CP's have the opportunity to focus on actually they are good doing (cracking problems while steaming development).
This is just my view, but as I told you before I have not much experience with FDD. Other here have years of it.
Hope it helps,
Nuno Lopes
Your help has been great!
Nuno, your posts have been really helpful. I really appreciate your help, actually I was starting to think that you are the only one responding to my questions. Thank you very much!
Rudy
Responsibilities in DBF
It may also happen, the the programmer is reponsible for all classes in a sequence diagram, or several sequence diagrams. The art is in defining who owns/responsible what like in everything.
I agree, and this is all known ahead of time. We known who owns which classes - we used this information to determine the team mebership when we kicked off this work package. Other than class-specific responsbilities it's all up to the CP. They do the administrative work, and are responsible for the overall completion of the work package. They may delegate some of the work to other team members, but they're responsible for it.
Having said this, this strategy does not work if staff is volatile. That is, the same programmer is assigned to work on multiple projects.
I don't agree here - remember a work package is usually no more than 10 days to complete, most often less. So staff volatility during an iteration is very, very rarely a problem in my experience.
Also is not resilient to holidays, flews or any other kind of phenomena requiring his absence.
Now we're talking just the usual staffing issues you have to deal with no matter what the methodology. In these cases I've found that explicit class ownership is a huge advantage here: you have an incredibly accurate picture of what work that person is doing. You know their class ownership, and what feature teams they belong to at present. For each team there's a crystal clear spec of what work needs to be done - and it's well understood by all of the other team members as well!
So how do you deal with it? Common sense - for anything that cannot be delayed someone else has to take over that responsibility. But now we've got some huge advantages from FDD here as well. For a complex or significant class we can re-assign class ownership, either temporarily or longer term. In other more trivial cases we may want to reassign just the requirements of a single feature team for a class, e.g. to the CP of the affected work package (who might delegate to another team member).
This can mitigated if you establish that code ownership and class can be 2 to one relatioship.
I diagree with this as a general practice, and certainly don't recomend this approach. If the reason is to mitigate the effects of staff unavailability then I believe it's the wrong approach.
You have to remember the amount of communication that's already going on within an FDD project during the DBF+BBF iterations. A developer owns several classes. They participate in many feature teams at once. These teams are forming and re-forming every two weeks or less. For each work package I'm participating in a domain walkthrough and design with the other team members lead by a CP. I participate in the review of other team members work. I work with different CP's and developers on each team. There's a HUGE amount of information transfer going on here - and it's common that I have quite detailed knowledge of several of the other classes with which my classes most often interact.
Now from a CP's perspective I'm always making time to simply "walk around" and chat to developers on my feature teams every day. Sometimes there's something specific to discuss, sometimes a more general chat about the work or maybe nothing at all. But in addition to the formal communications I go out of my way to keep the CP to developer communication lines open, and that's of course on top of all the times a team member will wander over to me for some info.
So I feel that a 2-1 class ownership as a general shape detracts from the benefits of class ownership too much, and offers little benefit.
Having said all that, there are rare cases when we might split class ownership, but for different reasons. Sometimes we just end up with a huge or complex class. For example we may have one aspect of the class that deals with some very scary computational complexity. In this case we might assign that aspect of the class to a different developer.
Another rare case is huge classes - they are evil and should be avoided at all costs, but sometimes you end up with them anyway. We might simply divide up the class for practical purposes - distributing the workload and reducing developer contention on the one class owner. This is difficult, and may require tuning to the ownership within that class over time, but it can be done.
Regards, Paul.
Thanks!
Thank you Paul for tunning my perception of the problems mentioned.
Nuno Lopes
Developer Collaboration in DBF
Hi Rudy,
yes - class ownership does work, and works well.
* Who assures that this workspace compiles?
This is not usually a problem. Remember that before we get into the Build By Feature (BBF) step we've already completed our sequence diagram(s) for all of the features in this work package. This means that we have a stub method of each of the new methods that will be added, each with complete (and inspected) documentation of the parameters, what is returned and what exceptions may be thrown. When a team member is coding up the implementation of the new methods in their classes these stubs will all exist, and so compilation is not a problem.
Sometimes, rarely, we find additional helper methods are needed or small tweaks are made that require some additional methods to be added that were not forseen during the design. This is one case where we might share these changes via the feature team area.
Even when doing extensive design in the DBF process, how assure that these 3 classes will cooperate as needed?
It's preciesly the design that ensures the classes will cooperate. All of the class owners participated in the design. The design is fully documented: we have a sequence diagram, design notes (including any other alternatives discussed), and fully documented stub methods in the code itself. This is all lead by a chief programmer, someone with the experience to ensure this activity is completed properly. Finally the design itself is formally inspected, and in the case of a complex design the CP might invite other developers or CP's from outside the feature team itself to ensure adequate review.
# And most importantly, who is responsible for testing this feature?
The bottom line is that the CP must ensure adequate testing had been carried out, but they often delegate some of this work (if not all).
There's usually two types of testing that go on at this level. The first is unit testing, which is the responsibility of each class owner to perform. The way this is done, and how formally, is something well discussed and documented in mountains of other liteature so I won't try to summarise it all here. We usually end up with some documentation of what tests have been performed and the results from each class owner for the unit tests, ideally implemented in a fashion that can be easily included into a regression test suite.
The other kind of testing is sometimes known as "string test" - we're not doing a full integration test here, but we we do want to ensure that this set of changes we've made do work together. This is something that the CP is responsible for ensuring the completion of, but often delegates this task to another team member.
Note that due to the wide variance in testing approaches FDD doesn't state precisely in what sequence testing should be done, e.g. before or after code inspection (or both). However it is an explicit exit criteria from this process, and is mandatory.
* In short, does class ownership really work?
Yes - I've used it successfully for many years now on large commercial projects.
The more interesting case for class ownership is on small project, say with only 2-4 developers. In these cases we still adopt class ownership, but find that most often we fall back to a situtation where class ownership is distributed almost along "module" or "package" lines. This is fine - it's still an invaluable technique IMO. But recognising that this is happening shouldn't freak you out - it's just common sense.
HTH, Paul.
This is a very interesting di
This is a very interesting discussion here. I am new to FDD. After reading the comments, I have a impression that 'class ownership' means one or some people 'owns' one class.
Q1: what do we mean by 'own'?
Does 'own' mean 'take full responsibility of ...', 'know the details of ...', 'do not want other people touch ...', 'make decisions about ...', ..., or 'take blame if things go worng in ...'?
And we have CP, who 'ensure' design quality, testing, compilation ...
Q2: How is it possible CP(s) knows all devils in the details?
Q3: If my new codes don't compile, or get a failed test, what should I do? Go to the people who 'owns' the code? Go to CP? Go to the code and modify it?
Honestly, I don't think this will work.
This is a very interesting di
Interesting point.
I'll only try my best to answer Q3.
If your code does not compile becouse of some other domain object that you have not participate in his build up, you must be working in the UI Layer, otherwise feature implementation division was not done correctly. If you are working in the UI Layer and you are calling the "erroneous" domain object you are executing a feature* (say create Order). If the feature does not function talk with the CP scheduled to implement that feature (it should be your CP doing that, or put it on the Bug Reporting Application and your CP reviews it and the talks with the other CP). This is what I think if we are dealing with teams greater then 4 or 5 (otherwise only one CP should exist).
As for Q1:
"Owns" means resposible for. How a company interprets the notion of responsibility is not a concern of FDD IMHO.
Q2.
CP is the only one responsible for an erroneous feature. He managed the implementation of that feature.
Nuno Lopes
Why class ownership can be really important!
We all have been developing software for some time using different caps (programmer, analyst, project manager, product manager, business director, support, pre-sales). Myself probably the least experienced on this list (12 years), and now I don't code that often.
Has a peace of software get more and more complex (from 10 classes to 500+, from 1 business rules to 3000+) I believe class ownership become more and more important to assure quality (bug free code, etc). It's nearly impossible for anyone in development to know every peace of code in a class (especially in a fast development environment), how to change so it does have impact on features etc.
A class can participate in multiple features, so how can we assure that a change in the class does not have an impact on any other feature (the CP for sure cannot)? Class owner
Suppose that class ownership is not enforced. That is anyone could change a class as he sees fit. Factor methods, change test methods, etc, change a existing method to fit a new feature, etc. The common scenario is that we the Team is responsible for the class, sounds good. I ask what team? The 3-15 people developing the application? Quite commonly what happens is in reality only one to three people actually have worked with the class and understand it. Jumping from this to class ownership is actually a small step, is a matter of organisation. Organization that is enforced in the Plan By Feature phase, plus WorkPackages.
Nuno Lopes
Communicate and Learn
re: Q1. I would say all of the above. Although "make decisions about" is often in concert with a Chief Programmer.
re: Q2. Very, very easily. Remember the granularity of a feature. These things are small. You're usually talking about 3 or 4 classes in a sequence diagram, where the first couple of classes often do little more than delegate down. Then, remember that the CP is the integration point for the design inspection and also the code inspection (as well as the integration for promote to build). Thus, there is substantial knowledge transfer via the two inspections. Also, the CP is also actively mentoring and coaching the class owners. The split of time is roughly 50% for his own work and 50% for mentoring programmers in his feature teams.
re: Q3. I'm unclear on the exact scenario you have in mind. If you have a problem with class A you go to the owner of class A.
The concept of component or module ownership has been known and practised for a very long time and is extended to class ownership in object systems.
If you do not use class ownership, when you assign a feature to someone then they must touch four classes (for example) in the system. They must have knowledge of four classes in the system. Think of very high use classes - such as LoanApplication in a Lending system. There would be a class with dozens of methods and attributes each written by a different person at a different date and time!!! (if not using class ownership)
Encapsulation is one of the founding principles of objects and is about a class being able to hide how it does what it does, and vary how it does what it does as long as it preserves its interface to all other objects. Well, class ownership naturally fits this fundamental requirement of objects. With class ownership you get better consistency of implementation and better consistency of interface.
Furthermore, it is a way to scale and mantain conceptual integrity. When I worked with approx. 1000 developers at IBM's Rochester Programming Laboratory doing operating system development, there is no way I could know all things about particular components. Take the old System/36 as an example - $MAINT is the librarian in that operating system and one of the most heavily used and important components (modules). Marguerite Doman was $MAINT and I could go to her with questions beyond what the published APIs and SPIs said.
You can't scale if everyone has to know everything about everything else. But even without large scale, maintaining the conceptual integrity of the whole is challenging. Concepts such as class ownership and feature teams (directly taken from the work of Fred Brooks and Harlan Mills) are the antidote.
Class ownership doesn't mean that ownership can never change, nor does it mean that you can't have more than one owner, but it does naturally complement encapsulation and that localisation of knowledge means better consistency of implementation and interface.
The concept of module or component or class ownership clearly does work and it is a long standing practice.
Jeff