Hi,

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




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 Jan, 2009 - 07:08 AM

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.

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.

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.

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 Jan, 2009 - 10:07 AM

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 Jan, 2009 - 02:54 PM

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

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.

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.

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.

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 Jan, 2009 - 04:20 PM

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

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



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.

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

http://www.extremeprogramming.org/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.

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.

I can atest to that.

Beck would be so proud.
Ganssle wrote and lectured a bit on this concept back in 2000 & 2001. Interestingly many of his comments paralleled the thoughts expressed in this thread - the pros & cons are many.
I don't see XP being applied today for it's intended rewards. I embraced it in those years because many customers were not knowledgeable enough to define a scope adequately, and XP allowed us to deal with the constant change that resulted.
Today it protects employers from coders who practice their craft with self-preservation as their main objective. I believe those who embrace XP tend to be skilled and confident.

Extreme Programming is really nice and helps to reduce software development time. However, for it to be successful, the developers that are part of an XP team needs skilled (or really willing to learn fast), and motivated.

We use XP at work...the morning meeting is redundant and does suck...the day long sprint planning is even worse. Its like asking you to define requierments and design 5 or 6 different projects in one day...so what happens? Everything is totally under scoped. A lot of times it results in one developer just sitting down start coding. Then, yes, you have to go back and fix their bugs. We all create bugs..it is inevitable. Because of business and time constraints...there is never any time for optimization and to do something the 'right' way.

We have only been doing this for a little over a year. It has got a lot better since then. Our company is small, our project managers are the ones who deal w/ clients. They QA everything. The team basically does it all, requirements, design, code, test...everything. A couple of things we have done, someone mentioned branches earlier. We use svn, so when we go to do a story, we copy our own branch and code that story into the system. Then, once we are done, we make a new database and copy of the story branch and send it out to the PM and another developer to QA. The other developer generally looks at the svn check in to see the code. Once it is approved it goes into the merge list...and about every week we have a 'merge party' where we merge all the story branches together...same goes for bug fixes. That process is a pain...but it is helping, and we have been fighting for more time to define and design.

Yes I have worked on code that was written over three years ago. One time, deleting a record wasn't working for a certain module. I dug way down to the procedure for it...and in the procedure was a comment "TBD: Make deleting groups work" heh. The last checkin on the file was from 2 years ago...no client that we worked with before used it.

Anyway, you have to be able to work on code you didn't write...it is apart of software engineering. Especially in my job...we have a high turn over because we are a small company and can't pay like the big guys...so once our developers get the time under their belt they move on to 15k salary increases. Although the turn over on our team has slowed down since we started Agile methodologies. Before you have PM's fighting for developers.

i think that not all code should be shared for free, take photoshop as an example, that took a long time to write; the authors deserve the right to keep it to themselves so others cant make a similar version based off their code.