• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Code author-neutrality

 
Ranch Hand
Posts: 637
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Ranch Hand
Posts: 775
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 M. Pinchback
Ranch Hand
Posts: 775
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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...
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
Marshal
Posts: 28193
95
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 775
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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 ]
 
author & internet detective
Posts: 41860
908
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.)
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 637
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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..
 
author
Posts: 608
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
 
Paul Clapham
Marshal
Posts: 28193
95
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
blacksmith
Posts: 1332
2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 637
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic