[anirelles]

Hi,

I was reading about Extreme Programming and I found this rule :

Quote

Collective code ownership

Collective code ownership means that everyone is responsible for all the code; this, in turn, means that everybody is allowed to change any part of the code. Pair programming contributes to this practice: by working in different pairs, all the programmers get to see all the parts of the code. A major advantage claimed for collective ownership is that it speeds up the development process, because if an error occurs in the code any programmer may fix it.

By giving every programmer the right to change the code, there is risk of errors being introduced by programmers who think they know what they are doing, but do not foresee certain dependencies. Sufficiently well defined unit tests address this problem: if unforeseen dependencies create errors, then when unit tests are run, they will show failures.

Is it really a good practice? Have you ever used it? To me it sounds weird, the day you need to understand some code who do you call if nobody is the ownership? Can someone who didn't write the code can really make a good change without consulting who wrote it?

Furthermore I think it can introduce some conflicts in the team. Developer generally don't like to have own code be modified by other.

What do you think?

This post has been edited by skyhawk133: 10 January 2009 - 08:08 AM

[Core]

In my opinion XP introduces some pretty interesting practices (that also refers to Agile development). However, some of them don't think are suitable for all situation.

The presented principle (collective code ownership) is not very good when you need to fully track all the changes in the code. And unit tests do not check for code optimization (so, what would be if someone introduces a 30-line piece of code instead of using a standard 1-line call), so if everyone will change the code the way they want, it will actually cause some specific problems.

In my opinion, in a team, the tasks should be split between team members, so everyone is responsible for his piece of the project, that will later be integrated in a project build.

[F!st!cuffs]

Yeah but there is software like team system, cvs, and tortoise that was created for this exact purpose. It tracks who edited the code and when so if something happens with it you can check the log and find out who messed up.

[BigAnt]

Quote

Can someone who didn't write the code can really make a good change without consulting who wrote it?

This really applies to all programming in general, not just XP, and it depends on the complexity of the code, if the original author of the code is even still around and so on.

Many times you will have to maintain the code and make changes without the the writer because they are fired (Maybe cause they wrote horrible code that you now have to fix), have moved on, or maybe even died.

[Core]

F!st!cuffs, on 10 Jan, 2009 - 08:37 AM, said:

Yeah but there is software like team system, cvs, and tortoise that was created for this exact purpose. It tracks who edited the code and when so if something happens with it you can check the log and find out who messed up.

That is a little bit different kind of software. It is not actually directly related to collective code ownership, more to parallel development. Using Team System, for example, every team member can be responsible for a specific code branch, but this does not necessarily mean that he can modify any piece of code in the project.

This post has been edited by Core: 10 January 2009 - 11:07 AM

[skaoth]

Quote

Can someone who didn't write the code can really make a good change without consulting who wrote it

If you consider yourself a software engineer, you should be able to. I guarantee that this will happen in the real world.
You will be asked at some point to modify existing code that you didn't write.

This post has been edited by skaoth: 10 January 2009 - 03:54 PM

[homemade-jam]

I thought extreme programming was programming in extreme places like extreme ironing.

[anirelles]

Thank you all for your comments. I actually work in a company that use this rule of collective code but ownership still exists. The most important part of the application is only understood by one person and I can have serious trouble if I modify something. Anyway.

I am a simple programmer and I was wondering wich methodology I would use if I had in charge a project. I strongly believe in the importance of unit test, continuous integration and frequent iteration to have feedbacks from the client. On the other hand, to me, Agile Methods looks like a lot about micromanagement (daily meeting + little tasks) and I clearly don't like to work in these condition.

[WolfCoder]

skaoth, on 10 Jan, 2009 - 03:53 PM, said:

Quote

Can someone who didn't write the code can really make a good change without consulting who wrote it

If you consider yourself a software engineer, you should be able to. I guarantee that this will happen in the real world.
You will be asked at some point to modify existing code that you didn't write.

My dad, a long time ago when he was modifying a program, had to fix the most horrible code he has ever seen. The code is so horrible, to this day even with his terrible memory he can still remember the full name of the original author of the code.

[Arenlor]

This is why there are coding standards. Otherwise if I looked at a piece of code written by someone else they could use the same exact things I do, but in totally different ways.

[buckrogers1965]

Pair programming is definitely required when you are trying to solve very difficult problems. We once had 5 people in a room all working on the same problem, and it was amazing how many things we tried and how many different ways that many people can look at a problem. There are some problems that are nearly impossible for a single person to solve by themselves.

But day to day just a code review after you write the code is needed before check-in is fine. I think that just like anything else, pair programming is best in moderation.

This post has been edited by buckrogers1965: 25 January 2009 - 05:20 PM

[Auzzie]

Well when i was a developer for the MMORPG Magellan Wars, there was a team of 6 of us on development, we were all given access to the FTP and told here is a list of To-Do's work out who is doing what one. On many occasions we had to use the same file so it was a case of constant uploading and communication between the team members so we dont cause a problem.
All of the code we had to work on was originally made by a Korean development team and out of the 6 of us, none had worked or even had a way of getting in touch with the original team so not only did we have to work with a 300+ file system but we had to translate it too

[tivrfoa]

change other's code can be very boring, but many times it's necessary.

Quote

(daily meeting + little tasks) and I clearly don't like to work in these condition.

daily meeting . should be weekly meeting =D. kidding. The meeting has to be very objective and fast, otherwise it becomes boring.

but pair working is the big problem, because it's a double-edged sword. I mean, when both programmers are in the same level, it's a really good experience, but when your pair is a newbie, it's a really terrible experience. I lose my will to work, because I will do the job (almost 100%) and he'll take the credit too.

[Core]

Quote

I mean, when both programmers are in the same level, it's a really good experience, but when your pair is a newbie, it's a really terrible experience. I lose my will to work, because I will do the job (almost 100%) and he'll take the credit too.

Usually, this is not the problem of working in pairs.

http://www.extremepr...rules/pair.html

One person codes, while the other one thinks of ideas on how the code should be implemented or refactored. In this way there is some increase in the programming experience for both of the developers. I don't think that completely new people that don't understand what and how to do will actually be capable of working in an XP environment because of all the principles it applies.

[rikki_max]

I would personally say the best way of programming in a group would be that everyone gets a list of what to do then they do it. of course the idea is that everyone works on a different section of the program like only one person works on a file at one time. But then if you have to work on the same file as someone else then you go to make shore you are not altering a part they have done and adding it to theres then uploading.

all in all this system may have problems but it can save a huge amount of bugs from happening.
For every 1 bug fixed there's another 10 as the story goes.