Do you care about your code?

In my current project we are using Scrum as development process. It's my first real experience with Scrum. In my previous projects we used a semi agile process, which was a little bit more lenient. Although it worked quite well, I'm thrilled to work with Scrum and try something new.

So since I'm new to Scrum, I started to read up on the basics of agile software development and found this particular core principle of Extreme Programing, which kinda strikes odd to me: Collective Code Ownership.

...abandons any notion of individual ownership of modules. The code base is owned by the entire team and anyone may make changes anywhere...

The second part of the statement seems to be okay: You can work on any module or any class on the entire code base. There is nothing wrong with that. I think the first part though, just cuts responsibility or accountability and leads to an "I don't care about my code" mentality of developers. Some people also call this "No Code Ownership", I rather call it "Careless Code Ownership".

When I write code, no matter if it's a module that someone else has to work with or something that goes straight to the customer, I try to release it as bug free as possible. That usually means as well tested as possible. By taking care of what I produce, I try to avoid being the target of blame, if something doesn't working as expected. I guess it's just me - being devoted to what I do. Obviously, that doesn't mean it always works out perfectly, everybody makes mistakes and so do I.

Being passionate about your code has advantages and disadvantages. You starting thinking of your code as kinda like your girl, which means you take care of it, maintain it properly and try to protect it from other developers screwing with it (no pun intended). Even long after changing projects, I sometimes scan through SVN diffs that I still receive after changes of one of my classes were committed. Most of the time I refuse to comment, cause it's just too much of a hassle to explain what I think is wrong with those changes. If you are that strongly tied to your code, it's sometimes hard to "let go".

I think it's beneficially to have none formal code ownership, in terms of developer feeling responsible for their work. There is someone that can help you, if you have questions. There's a safety net in case of something goes wrong, after you made changes to "foreign" code. And last but not least, there is someone you can learn from. If another developer is looking at your changes, he can tell you what you should improve and what's good about your solution. To me that's the most important reason, because you should never stop trying to improve.