Don't touch my code

There is not such thing as "my code". If there is, there should not be. This is the basis of collective code ownership: everybody can touch anything. Of course, we MUST make sure that our changes do not alter the existing behaviour (unless we're fixing bugs, or altering behaviour is exactly what we're after, of course).

Sentences like "if you touch my code I'll have to spend a lot of my time to correct your errors" are based on the (hopefully wrong) assumption that your fellow developers commit carelessly modified software. Collective code ownership also means collective responsibility, that should go hand in hand with the "leave your campfire better than you found it" habit.

If I touch "your" code (with which I actually mean "the code of which you were the first author") I magically become responsible for it. But be warned: this is a responsability I share with everybody else in the team. Actually I don't even have to touch "your" code to be responsible for it, as I already am. That's it. Do I see something unclear? I'll try to clarify it. Do I see obsolete comments? I delete them. Do I see comments? I'll probably delete them too, provided that the code speaks enough. If it doesn't, I'll try to make it speak. And delete the comments :-)

Sustainable pace?

Always been one of my favourite practices. Too bad I fail to practice it more often than I'd like to... 7 extra hours in three days, up to 2 a.m. on Sunday morning and a holiday spent working. There's really a lot of space for improvement!

Collective Code Ownership Part 2

When I write "everyone is responsible for all the code" I also mean that everyone is responsible for all the tests, so if you only have unit tests and you need an integration test... write it! It does not matter if you didn't write the original code or the original unit tests, it does not matter even if you didn't talk to the original developer. It is your responsibility to write it: navigating through an application just to click a link is (almost) completely pointless, and it sure is a waste of time. That does not mean that end user testing must not take place (how could you assert that "a normal user should be able to foobar the barfoo without previous training" otherwise?), but we should strive to automate as much as possible.

This is even harder to assimilate, because not only you have to touch code written by others, but (heresy!) write tests for code you didn't write. It's already hard to persuade people of how much TDD pays off the initial investment and the mental shift, but it's even harder to push them to use tests as a primary way to discover how a particular piece of code works (I often write tests for third part libraries or also for checking the behaviour of java.lang or java.util classes I'm not sure about). I can understand that people fear changes, and that one could be unwilling to change the way he's always worked, but here we're talking about being afraid of one's own shadow. Try it, and try it seriously, and after you did if you still think it won't work (and you won't) you'll still be able to give it up. And... no, "I have no time" is not a valid answer, because not having tests only leads to wasting more time.

Alas, too often I perfectly agree with Gabriele...

Collective Code Ownership

To quote from Wikipedia:

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.

That also means that everyone has to change any part of the code when it is required. Developers cannot shield themselvs behind a "he did it". Even if you didn't partecipate in the writing, the code should be clear enough to allow you to understand it and change it confidently.

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.

That's true, but... who controls the controller? Just today, after other colleagues were trying to integrate two systems without writing tests (boo!) we wrote a (supposed to be) failing unit test and... it didn't break as it should, as we were testing for equality objects that we clearly knew were different. That was because we forgot to change the equals and hash code methods after adding an attribute to the result class of which our tested method returned an instance, and we didn't have a test on equality on the result class because all the code was generated by the IDE. Nevertheless having a bunch of tests sped the process of finding and fixing the error: if we didn't write a failing test before proceeding we would have spent a lot of time before we managed to find our (not too subtle) bug - time our colleagues actually did spend.

So... always write your tests! That's another supporting example for the "we tried baseball and it didn't work" post: Collective Code Ownership also works because of other practices, such as coding standards, pair programming and unit testing. I'm still convinced of what I wrote, but I certainly agree on the fact that you cannot simply pick random XP practices and hope everything will go well.

Scrum and XP from the Trenches

My friend Manuela suggested me "Scrum and XP from the Trenches", an introductory war story on Scrum written by Henrik Kniberg which I found very interesting.

I particularly liked the idea of a separate place for unplanned items on the whiteboard, as we normally pin them with the others, depending on the feature they address: even if the team knows why it's taking so long to get things done, the management always seems to not to. A huge cluster of unplanned items is a clear signal nobody can ignore :-)

This is another (working) example of the old bit "the simplest thing that could possibily work"... way to go whiteboard warriors!

Henrik and InfoQ provide a courtesy copy of the white paper here (you have to login first).

Gain a better understanding of code

What motivates us to refactor? Joshua Kerievski asks (and answers) himself this very same question. One of the reasons he gives is to "gain a better understanding of code". To quote:

Sometimes we look at code and have no idea what it does or how it works. Even if someone could stand next to us and explain the code, the next person to look at it could also be totally confused. Is it best to write a comment for such code? No. If the code isn't clear, it's an odor that needs to be removed by refactoring, not by deodorizing the code with a comment.

I'd like to stress the second part of the quote. Is this the way we behave? I'd like to say yes, but too often I don't. The most recurring reason for which this happens is that the typical codebase on which you experience this problem has no test harness. I know, I know, I did not only buy the Feathers', I also read and studied it: everything looks neat and beautiful, but sometimes the processes described can be really exhausting, and you obviously come to fear changes (which is against XP values, for example).

Now, to everyone who thinks Star Wars to be just a useless bunch of movies, I'll show you how it can help you experiences professionals through. Powerful master Yoda said:

Fear is the path to the dark side.

The dark side is represented by hacks'n'comments. When you find them, you should follow Darth Sidious' advice:

Wipe them out. All of them.

Extreme as it might look, this is by far the best solution in the long run. And... May the force be with you.

Baseball and XP

I just read this great post which is, even if it is disguised, about customizing agile methods. I quite agree with it if the outcome of customizing is a failure, but I think that if you just adapt a method to your environment and it works, well, I'm not interested in being a "purist". I want to deliver value, and if we find a practice not to be useful we simply don't care about it.

Sustainable pace

I read a discussion about Sustainable Pace, one of XP's practices, in which the contributors try to relate the subject with a fixed number of hours per week. Literature (based on extensive studies) shows that there is no linear relationship between productivity and hours worked, and I quite agree with that; moreover, there's a law (you will forgive me, but I don't have the reference at hand) that states that if you have a certain amount of time to do a job this will expand to fill the whole time slot available. Sistematically working overtime does not increase productivity in the long run (not even in the medium run); one of the (many) reasons is that software production has nothing to do with traditional industrial processes. My personal opinion on that is that more hours do not guarantee an extra productivity; nonetheless under exceptional circumstances (which is to say not every week) extra hours can be invaluable.

Here in Italy the "normal" working week is based on forty hours over five days. A contributor enthusiastically sustains that one extra hour a day guarantees "more than one month of extra development time during a year!"... or does it? I strongly disagree.

It's not unwillingness to work, or (better) unwillingness to get the job done; it's about commitments and balance between work and private life. In an agile enviromnemt you only plan for the next (very) few weeks, so the estimates are much more accurate and, as the project goes on, you have a pretty good knowledge of your productivity: that allows you to commit to a fair amount of work without steadily subtracting time to your private life. An extra hour in the office is an hour in which I can't play with my children, talk to my wife, read a good book, oble a new biscum or burble the tramling (Cockburn readers might get the reference) or whatever. That can lead to a burnout, thus resulting in a great loss of productivity. I already spend more time with my colleagues than with my family, and I think there's really no need to make things worse.

Besides... how many people on their death bed say "I regret I have not spent enough time working extra hours..."?