Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

This is a pretty generic question but one I've been wondering about for a while: is there a standardized, generally accepted, or even just systematic way that people write code as a group?

For example, in a project written in C++, does one developer write one class, which he passes off to the next developer with a quick explanation of what each method does?

share|improve this question
    
It is not a bad question at all. It is a bit broad though. –  Emmad Kareem Jun 24 '12 at 6:13
4  
4 starving men. One steel cage. A razor sharp hunting knife. It ain't pretty. –  Wyatt Barnett Jun 24 '12 at 14:03
add comment

4 Answers

I've never seen a formalised, standardised way to do this - but I've seen two common patterns.

Feature Ownership - each developer takes exclusive responsibility for a particular feature of the system, and implements this through all appropriate layers.

Key Advantage: one developer, with a full understanding of the entire feature, can work through all layers in a consistent fashion.

Key disadvantage: Because many different developers end up working on the each component, you can end up with a distinct lack of consistency unless you have good conventions in place.

Component Ownership - each developer takes exclusive responsibility for a specific component/layer (UI, services, data access, data schema etc). Features are implemented by collaboration between devs.

Key Advantage: each component is written by a single developer, ensuring it has a consistent style and "unity of vision".

Key disadvantage: There are always some components requiring more development than others - resulting in an unbalanced load on certain developers.

Though, these are exclusive - even if a particular team subscribes primarily to one, some things tend to be done the other way.

In my experience, feature ownership has been more successful in the long term than component ownership, primarily because system knowledge is more spread out, helping to address key person risk. But, that's just my experience.

share|improve this answer
    
+1, good and concise. On the naming: "Component", I am not sure about this name. A component to me would mean some kind of self contained thing with defined inputs and outputs such as a dll. What your describing sounds to me more like a "layer" or a "tier". –  Emmad Kareem Jun 24 '12 at 6:20
    
@EmmadKareem - good point. I wasn't using the term "component" in any technology specific manner. I did consider using "Layer" or "Tier", but that (in my mind) excludes things like the database and xml schema. –  Bevan Jun 24 '12 at 6:26
1  
+1, though ownership should last as short as possible. With us it is until shipped (or one release extra). After that everybody is expected to be able to work on it. –  Marjan Venema Jun 24 '12 at 9:18
    
@MarjanVenema - I agree that that's a good choice, though I've seen shops where code ownership was permanent, whether through policy or because other devs were afeared of going there. –  Bevan Jun 24 '12 at 9:52
    
Yes, I have been in such shops as well. Not nice to be the one stuck with the xxx part of the code base, but aside from that, it is also a very bad policy from a business risk perspective. If something happens to the sole code owner, you are definitely in a pickle. And unfortunately when something does happen, it usually is at the very worst moment it could ... And even if everybody stays healthy and with you, it doesn't scale very well when you have to switch gears in order to get a release out the door. –  Marjan Venema Jun 24 '12 at 14:16
add comment

in Agile, the answer is however the team wants it to work

could be features, could be stories, could be tests, could be tasks, could be paired, could be...whatever.

some dev shops transfer code ownership at shift change and use three shifts in time zones 8 hours apart for continuous development

some dev shops assign entire subsystems to one person

there are many ways...

share|improve this answer
1  
+1 Indeed, there is no "one size fits all" method (contrary to what some managers still believe...). People - developers, managers and clients alike - are different, project requirements vary, circumstances change constantly. Successful processes must keep adapting to all these. –  Péter Török Jun 24 '12 at 8:20
add comment

I'm making this a separate answer because while it has some of Bevan's answer at its core, I'm expanding on it a bit. I, too, have never seen a formalized way of doing this.

Mine is an Agile shop building a SaaS app, with a team of 4 developers and a tester, working on 2-weeks sprints. When the team decomposes stories, we create a parent ticket and children tickets that roughly work out to be model changes, view changes, and controller changes (broadly speaking) to achieve the goals of that story.

When it comes time to work, one developer grabs the parent ticket, and for the life of that work within the sprint, they become the "owner" of the code that goes into realizing that story. However, it is quite common that other people on the team work on the child stories depending on personal strengths (e.g. UI, database, an extra dose of business logic knowledge). The "owner" of the parent ticket is the go-to for questions about that feature or component (whatever the case may be) until all the children are completed and the owner works through the whole item at the parent level and is ready to send it as a bundle to the code review status.

When items go through code review, they do so at the individual child level as well, and the only rule is that no one reviews their own code (obviously). So, while Developer A might be the owner of the parent ticket, he could have worked on Piece 1, 2, 3 while Developer B worked on Piece 4, 5, and Developer C on piece 6, 7. Developer A would be able to code review 4, 5, 6, 7, Developer B could code review 1, 2, 3, 6, 7, Developer C could code review 1, 2, 3, 4, 5. When the code makes it through Code Review, it goes to test.

The tester tests each child independently if it has its own acceptance criteria, and the parent as a whole (which definitely has its own acceptance criteria). Here's where "ownership" comes into play again -- the owner of the parent is responsible for any fixes in the parent or its children. "Responsible" in this case may mean "having a conversation with whomever worked on a problematic child" but it is the parent owner's to get right.

The thought with all of this, and it's worked ridiculously and shockingly well with my team, is that everyone is always both an owner and a helper, everyone practices collaboration and communication constantly, and everyone is then familiar enough with every piece of the system that after the release anyone can be an owner of anything for the short period of time that owners have a role (e.g. within a sprint).

share|improve this answer
add comment

The short answer - No, there are no standard ways of doing anything, but one thing which nearly all projects start out with in common is that almost everything will be 'unknown' near the beginning.

With reference specifically to your question about delegating responsibility for individual classes (or any other implementation details for that matter) - those kinds of decisions can't always be made up-front because developers often don't have enough information at the time the work is divided. It's fairly common to have no idea what classes are going to be created until development has begun and there exists some kind of working baseline/prototype.

More typically, developers might just agree upon periphery details for whichever part of the system they are responsible for, so that other developers have an idea of how the bits will integrate together, without worrying about how it's actually going to work.

In practice, it usually means defining communication boundaries (internal or external) which will be used to connect the features/components/modules - e.g. interface types, message structures, data formats, input/output streams, shared data types etc. The final split of responsibility may or may not mean that multiple developers work on the same classes/functions; it may also mean that classes which featured in the original design are scrapped and overall architecture is later changed (but hopefully the basic interfaces and communication mechanisms will still be largely usable)

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.