{ by david linsin }

May 12, 2008

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.

14 comments:

Anonymous said...

Hey David,

nice to read your post. When we had a Scrum training a while ago, the collective code ownership issue was one of the first we got into discussion about.

I also would never recommend everybody to know everything about a system. We split up software systems into modules to manage complexity. If you try to be up with the latest details of every of them you simply get lost in it.

I guess collective code ownership as many of other paradigms of Scrum are not ment to be carved in stone. I think its good to know what the guys of the other module's team are doing. Not in every tiny detail but to get the big picture.

Nevertheless I agree to your thoaughts about code beauty. Once you get devoted to thoroughly tested, designed and documented code it is hard to read other code without commenting on it and perhaps offending people. But guess what: perhaps it is some kind of challenge to spread this attitude and help others to write more beautiful code.

Regards,
Ollie

David Linsin said...

> I guess collective code ownership as many of other paradigms of Scrum are not ment to be carved in stone.

That's what I like about the notion of agile methodologies - adaptability. If I'm getting it right, it's okay to just pick the portions that you think are useful, as long as it stays agile.

> ...perhaps it is some kind of challenge to spread this attitude and help others to write more beautiful code.

I feel you! Exactly what I'm trying to do!

Anonymous said...

Hi David. I understand where you're coming from, but I think the reason for your concern is you haven't fully assimilated Agile/Scrum practices yet.

I've been using Scrum for about a year now and I'm Team Leader for a Scrum team here (currently 4 people although it varies).

You consider that Collective Ownership = No Code Ownership and I'd say that if you do you need to give your team-mates a bit of a slap. Where I work it is literally that, the team owns the code. If there is a bug, there's no "go and see John" or "that's Jane's fault" - we just fix it.

We have pride in our code (the last project we launched has been an amazing success within the department and the company) and don't consider it abandoned after completion.

We also aim to deliver bug free code, hence another part of Scrum/agile development - testing with each user story.

Like you, we consider the code our girl - but just one that we all love, share and all have responsibility for! Man, that sounds dirtier using your analogy :-)

David Linsin said...

> Like you, we consider the code our girl - but just one that we all love, share and all have responsibility for! Man, that sounds dirtier using your analogy :-)

That's the thing with analogies, they just sometimes paint too much of a picture :-)

> If there is a bug, there's no "go and see John" or "that's Jane's fault" - we just fix it.

I think that's a great definition of collective code ownership and I really appreciate you pointing it out. The more I think about it, the more I come to realize that the whole team needs to pull together. I'm really excited to see how this will work out in our team.

Anonymous said...

> If there is a bug, there's no "go and see John" or "that's Jane's fault" - we just fix it.

I haven't used an agile process before, but this seems rather stupid to me. You don't have to blame anyone, but if something doesn't work right and I happen to know that it's Jane's "area", I shouldn't waste half my day looking into it when she could probably fix it in 15 minutes. You don't ask your mailman to fix your doorbell just because he's the one that noticed it's broken. You call the guy that knows how to fix doorbells.

If I tried to get to the bottom of it myself, it'll take MUCH more work and the chance that I'll introduce a NEW BUG will be higher.

Plus, I WANT to know when I created a bug. You can't learn from your mistakes if you aren't aware of them.

Anonymous said...

noob

David Linsin said...

> but if something doesn't work right and I happen to know that it's Jane's "area", I shouldn't waste half my day looking into it when she could probably fix it in 15 minutes.

If I understand it correctly this is exactly what Collective Code Ownership is trying to prevent. You get to work on every area of the application so that everyone can do anything.

Anonymous said...

In our project, we established collective code ownership a while ago and it helped us to gain more speed and flexibility. Many problems with code quality have improved because a single developer can no longer turn an area into a complete mess with nobody noticing.

Despite collective ownership, it's still common behavior to ask the original author for advice if you make major changes to a piece of code. When it comes to design, we always include one developer who's most proficient in the given area. And since we work on a high-performance system, there are critical core classes that nobody may touch without discussing it with the team.

Having used this model for about half a year, my conclusion is that it works well for teams with equally talented developers. You can compensate for a single weak programmer, but you certainly don't want to use collective code ownership if talents diverge.

Anonymous said...

tieTYT> if something doesn't work right and I happen to know that it's Jane's "area", I shouldn't waste half my day looking into it when she could probably fix it in 15 minutes.

david> If I understand it correctly this is exactly what Collective Code Ownership is trying to prevent. You get to work on every area of the application so that everyone can do anything.

Absolutely! Obviously there are always going to be some people more proficient in certain areas than others, but everyone should know how the system works and be able to change things without it all falling over (more on this in a minute).

tieTYT> If I tried to get to the bottom of it myself, it'll take MUCH more work and the chance that I'll introduce a NEW BUG will be higher.

That's where the Scrum focus on automated testing/documentation comes in - no task is done until it has automated tests and documentation. Therefore if you introduce a new bug it will either a) be caught by the test suite or b) be an opportunity to enhance the test suite when it's found to ensure it's properly fixed.

Also, given collective code ownership, the code should be clean enough that anyone can read/amend it without having major unforeseen knock on effects. With that many eyes on code, ugliness tends to get noticed much earlier on.

tieTYT> Plus, I WANT to know when I created a bug. You can't learn from your mistakes if you aren't aware of them.

Every day you have a 10-15 minute stand up meeting where you discuss what you did yesterday, what you plan to do today and anything that may/will stop you from doing that.

During the what you did yesterday something may come up like "I fixed a bug in the Shmazoogle parser when unicode characters are present". That's then an opportunity for Jane to say after the meeting (the meetings are short updates not in-depth technical chats) "What was the bug? What was the fix? I wrote the unicode portion of the Shmazoogle parser?".

Note in the meeting (or indeed at any time) was it "Jane, there's a bug in the Shmazoogle parser that you wrote". There was a bug, it was fixed and automated tests prove it is now fixed. If Jane wants to know what happened she'll hear it was fixed (unless it was a 2 minute fix that isn't brought up at the meeting) and can choose to get more involved in finding out why if she likes.

As I've been using Scrum for about a year now, maybe I really ought to write a blog post about my experiences... Hmmmm...

David Linsin said...

unmaintable> Having used this model for about half a year, my conclusion is that it works well for teams with equally talented developers. You can compensate for a single weak programmer, but you certainly don't want to use collective code ownership if talents diverge.

That's an interesting observation. I'll keep that in mind. I think the skill levels in a team are always very diverse. However, I believe with enough passion and devotion you are able to balance that difference. I might be wrong, but it should be possible to drive a team with a single devoted developer, no matter how "junior" your other team members are.

Anonymous said...

I think it's a matter of encapsulation. If there are several bad programmers on a project, it's IMHO a much better strategy to use strict code ownership. Like that you can protect the areas written by the capable part of the team, so end-game cleanup and debugging efforts can be directed towards the other areas.

From my experience, you will never be able to turn a sloppy, untalented programmer who's only interested in a 9-5 job into a high performer (or something adequate). If you have these kinds of people, it's like birthday and Christmas combined when you finally get rid of them. You can try to convince them to write unit tests, give them metrics, ask them to read "Refactoring" or "The Pragmatic Programmer", it just won't help much.

Good for you if you've never seen that in a project :)

Cheers,
Matt

David Linsin said...

unmaintable>If there are several bad programmers on a project, it's IMHO a much better strategy to use strict code ownership

That's how I've always worked on previous projects and it worked out okay...I'll report on my current "agile-driven" project when I know say more.

unmaintable>You can try to convince them to write unit tests, give them metrics, ask them to read "Refactoring" or "The Pragmatic Programmer", it just won't help much. Good for you if you've never seen that in a project :)

Believe me when I say, I feel you! Just read through some of my previous posts on "coding philosophies", then you'll know what I mean.

Anonymous said...

I dont think there is such a thing as bad programmers, only inexperienced ones.

Scrum Process said...

Interesting blog. It would be great if you can provide more details about it. Thanks you


com_channels

  • mail(dlinsin@gmail.com)
  • jabber(dlinsin@gmail.com)
  • skype(dlinsin)

recent_postings

loading...