aspose file tools*
The moose likes Agile and Other Processes and the fly likes Code author-neutrality Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Soft Skills this week in the Jobs Discussion forum!
JavaRanch » Java Forums » Engineering » Agile and Other Processes
Bookmark "Code author-neutrality" Watch "Code author-neutrality" New topic
Author

Code author-neutrality

Stuart Ash
Ranch Hand

Joined: Oct 07, 2005
Posts: 637
I have been considering agile/xp practices for a while, and slowly trying to implement some of these in my team.

I wish to discuss the concept of author-neutrality here.

Conventional Tenet: All code has known authors. By and large, each unit of code (typically class) has a main author, who has a sense of ownership.

Agile Proposition: Any code anywhere can be changed by anyone at any time.

I want some inputs on the pros and cons of these two stands, as seen by other practitioners here.


ASCII silly question, Get a silly ANSI.
Reid M. Pinchback
Ranch Hand

Joined: Jan 25, 2002
Posts: 775
There is a differerence between somebody caring about the code in the project as a whole, versus feeling like a piece of the code belongs to them alone. Similarly, a difference between team members thinking that they have joint responsibility for the code, versus feeling like they aren't supposed to (or would rather avoid having to) touch each other's code.

No doubt you could find small projects where the "don't touch my stuff" dynamic worked out ok, but in general what I think you'll find are knots of code that only the author understands, and anybody else would loath the very same code if they had to touch it. When anybody can work anywhere on the code, I think the more likely dynamic is to achieve general agreement on what shape folks want the code to be in. If weaknesses are spotted, they are more likely to be fixed.

In the proprietary model you have to persuade the author to make the changes (which can put them on the defensive; after all, you are complaining about their work) *and* the author has to have the time to make the changes. Even if you aren't worried about the former, the latter means individual people become resource bottlenecks.


Reid - SCJP2 (April 2002)
Reid M. Pinchback
Ranch Hand

Joined: Jan 25, 2002
Posts: 775
If you want the opposite viewpoint, you could argue that the proprietary model allows specialists to do their thing. For example, creating high-performance persistence layers for clusterable J2EE apps isn't something you learn to do overnight. Having somebody who knows how to do it work on the code and descriptor files can make sense.

The downside, and thus the argument in favour of the author-neutrality model, is that the other team members will never learn if you don't get them started somehow - if the specialist leaves your project is scrod. Better if others can at least attempt changes and then ping the specialist to review the results. After a while, no more need to think in terms of specialists.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Reid M. Pinchback:
If you want the opposite viewpoint, you could argue that the proprietary model allows specialists to do their thing. For example, creating high-performance persistence layers for clusterable J2EE apps isn't something you learn to do overnight. Having somebody who knows how to do it work on the code and descriptor files can make sense.


Yes, it can make sense. But to do that, she doesn't need to *individually own* that code, does she? Having common code ownership doesn't mean that I am forced to work on code I can't handle...


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Reid M. Pinchback:

In the proprietary model you have to persuade the author to make the changes (which can put them on the defensive; after all, you are complaining about their work) *and* the author has to have the time to make the changes. Even if you aren't worried about the former, the latter means individual people become resource bottlenecks.


Additionally, you easily can suffer from the "there is a problem in this code, but it's not *my* code, so why should I care about it" syndrom. With common code ownership, all the code also is *my* code, so if there is a problem, it's my responsibility to make sure that it gets solved.
Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18985
    
    8

Where I work we have a couple of thousand programs (written in a language that isn't Java, but I don't think that matters for this discussion). In theory anybody can change any code at any time, but in practice we have specialists who work with a certain subset of programs. So if somebody wants to change the pricing module that uses 33 database tables and is called by any program that wants to know how much we are going to charge Customer X for Product Y today, they are almost certainly going to talk to the person who regularly works with that code. But if they have a change to make to it and they know what they are doing (KEY POINT), then they can make the change themselves. What this means is that both the Conventional and Agile rules apply, and there is a creative tension between them. We don't want people changing our pricing algorithm willy-nilly, but we also don't want to prevent people from making necessary changes.

Now of course the pricing algorithm is one end of the spectrum. At the other end of the spectrum is for example a daily exception report that's sent to managers. If a column heading is spelled incorrectly on that report then anybody can fix it without discussion.

We are undergoing a Sarbanes-Oxley audit at the moment, and the auditors are not pleased with the "agile" part of our methodology. They would prefer that our software be partitioned into areas with people responsible for the changes made in those areas. I believe the reasoning of the people who make up these audit checklists is that they want any change to the code approved by some identifiable and responsible person before it becomes live code. The concern, I expect, is that I could put something into the pricing algorithm that gave my brother's store a good deal and that nobody else would notice. (In our system one would do that by changing database entries rather than code, but it's hard to explain things to auditors.) Anyway, we will probably deal with this requirement in some creative way that allows us to go on getting our business done, but the message is that "agile" is going to be hard to do in publicly-held North American companies.
Reid M. Pinchback
Ranch Hand

Joined: Jan 25, 2002
Posts: 775
Originally posted by Ilja Preuss:
Yes, it can make sense. But to do that, she doesn't need to *individually own* that code, does she?


No, doesn't need to. Didn't claim it. Don't believe it. Just contrasting the viewpoints, which was the poster's original request. Not much point in playing devil's advocate if you only talk to one side of the issue. Also durned boring for the devil.
[ March 17, 2006: Message edited by: Reid M. Pinchback ]
Jeanne Boyarsky
author & internet detective
Marshal

Joined: May 26, 2003
Posts: 31054
    
162

Originally posted by Stuart Ash:
Conventional Tenet: All code has known authors. By and large, each unit of code (typically class) has a main author, who has a sense of ownership.

Agile Proposition: Any code anywhere can be changed by anyone at any time.

Technically the agile code has known authors. You just have to go into version control to see who they are. I bring this up because we've been talking about "how do you know who touched a piece of code" lately.

We've been doing more of a mix lately with respect to this. Anyone can touch the code, but there is a primary author who knows the most about it. This is a decent mix as it allows specialization and ease of support when someone goes away for a month (or presumably if someone leaves.)


[Blog] [JavaRanch FAQ] [How To Ask Questions The Smart Way] [Book Promos]
Blogging on Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, OCAJP, OCPJP beta, TOGAF part 1 and part 2
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Paul Clapham:
In theory anybody can change any code at any time, but in practice we have specialists who work with a certain subset of programs. So if somebody wants to change the pricing module that uses 33 database tables and is called by any program that wants to know how much we are going to charge Customer X for Product Y today, they are almost certainly going to talk to the person who regularly works with that code. But if they have a change to make to it and they know what they are doing (KEY POINT), then they can make the change themselves. What this means is that both the Conventional and Agile rules apply, and there is a creative tension between them. We don't want people changing our pricing algorithm willy-nilly, but we also don't want to prevent people from making necessary changes.


Well, changing the pricing algorithm willy-nilly isn't Agile, it's insane...

Having specialists isn't anti-Agile. Only having specialists who own their code and/or refuse to work outside their speciality is.

The concern, I expect, is that I could put something into the pricing algorithm that gave my brother's store a good deal and that nobody else would notice.


Don't you have automated system tests, owned by the customer, to prevent that?
Stuart Ash
Ranch Hand

Joined: Oct 07, 2005
Posts: 637
Reasonable ideas... Thanks folks.


Originally posted by Jeanne Boyarsky:

Technically the agile code has known authors. You just have to go into version control to see who they are. I bring this up because we've been talking about "how do you know who touched a piece of code" lately.

We've been doing more of a mix lately with respect to this. Anyone can touch the code, but there is a primary author who knows the most about it. This is a decent mix as it allows specialization and ease of support when someone goes away for a month (or presumably if someone leaves.)


I think I'll start with something hybrid like this, and slowly move on to something more purely agile..
Scott Ambler
author
Ranch Hand

Joined: Dec 12, 2003
Posts: 608
We are undergoing a Sarbanes-Oxley audit at the moment, and the auditors are not pleased with the "agile" part of our methodology. They would prefer that our software be partitioned into areas with people responsible for the changes made in those areas. I believe the reasoning of the people who make up these audit checklists is that they want any change to the code approved by some identifiable and responsible person before it becomes live code. The concern, I expect, is that I could put something into the pricing algorithm that gave my brother's store a good deal and that nobody else would notice. (In our system one would do that by changing database entries rather than code, but it's hard to explain things to auditors.) Anyway, we will probably deal with this requirement in some creative way that allows us to go on getting our business done, but the message is that "agile" is going to be hard to do in publicly-held North American companies.




The real problem is that your assessors are imbeciles. Instead of looking over their pathetic little checklists, why can't they simply look at the check-in history in your version control tool to see who changed the code? Or aren't they skilled enough to do such a basic task?

The good news is that the US Government is slowly coming to the conclusion that Sarbox isn't such a great idea after all. Within a couple of years I expect to see a major overhaul, and one of the first things to go will likely be these clowns that you're referring too.

- Scott


<a href="http://www-306.ibm.com/software/rational/bios/ambler.html" target="_blank" rel="nofollow">Scott W. Ambler</a><br />Practice Leader Agile Development, IBM Rational<br /> <br />Now available: <a href="http://www.ambysoft.com/books/refactoringDatabases.html" target="_blank" rel="nofollow">Refactoring Databases: Evolutionary Database Design</a>
Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18985
    
    8

Originally posted by Scott Ambler:
The real problem is that your assessors are imbeciles. Instead of looking over their pathetic little checklists, why can't they simply look at the check-in history in your version control tool to see who changed the code? Or aren't they skilled enough to do such a basic task?

- Scott
On the one hand you're right. On the other hand I can't really hate them too much, because I used to be one of them. I can still recall being handed the checklist for the "DP Security" reviews that the consulting company did, and being sent off to a client (about which I knew pretty much nothing) to administer the checklist. I'm pretty sure they lied like hell to me, too, but that didn't really matter too much because the checklists got done, approved, and filed.
Warren Dew
blacksmith
Ranch Hand

Joined: Mar 04, 2004
Posts: 1332
    
    2
I've seen agile teams with two different approaches to "author neutrality".

One is that no one owns the code. When someone needs a change to a library call, he changes the call to make his own client code work, often breaking other code in the process. Since no one owns the library code, no one has the job of fixing this breakage. After a while, the code base devolves into a random mess of bugs. This form of joint code ownership is far inferior to individual code ownership.

The other is that everyone owns all the code. When someone needs a change to a library call, he changes the call, then makes sure not only the code he's working on, but all the other code in the project also works - since he owns that other code too. He can get help from other people if he needs it because they all own all the code as well. This form of joint code ownership can work really well.
Stuart Ash
Ranch Hand

Joined: Oct 07, 2005
Posts: 637
Originally posted by Warren Dew:
I've seen agile teams with two different approaches to "author neutrality".

One is that no one owns the code. When someone needs a change to a library call, he changes the call to make his own client code work, often breaking other code in the process. Since no one owns the library code, no one has the job of fixing this breakage. After a while, the code base devolves into a random mess of bugs. This form of joint code ownership is far inferior to individual code ownership.

The other is that everyone owns all the code. When someone needs a change to a library call, he changes the call, then makes sure not only the code he's working on, but all the other code in the project also works - since he owns that other code too. He can get help from other people if he needs it because they all own all the code as well. This form of joint code ownership can work really well.



LOL, yes, it's the possibility first scenario that makes you cynical about taking up author-neutrality. But I might summarize that it will work only when taken up responsibly as in the second case, and ideally in concert with other stuff such as daily integrated build and unit tests.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Stuart Ash:
LOL, yes, it's the possibility first scenario that makes you cynical about taking up author-neutrality.


Well, yes - there is a big difference between no code ownership and collective code ownership. The former will lead to disaster, the latter is quite effective.

ideally in concert with other stuff such as daily integrated build and unit tests.


Don't forget Pair Programming!

Daily integration would be far to infrequent for my taste. In fact our two hours are far to infrequent.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Code author-neutrality