It's possible to change it ... Code ownership

Another day, another story...
I stumble upon one piece of code, that caused an NPE.
It could have obviously been avoided doing a small refactoring so that any client of the code, no matter what, would not get an NPE. Doing so would have meant to delete one method, and possibly break the compilation of any client calling that code, but instead of a runtime NPE a compilation error is way better.

So I asked around, why it was not refactored :
"You can change it, but it will be your responsibility if it make fails other projects"

Nice.
If you are not too scared of being held responsible of another project delay, this would stay in the same state, and the NPE was normally fixed so why bother ?
Or you can do it like in cowboy style ( also known as Rambo style) doing all the work by yourself.

Both cases are not ideal, and the cause was :

• there were no true Continuous Integration and appropriate testing strategy. As a consequence every one fear the change.
• There is a sense of code ownership or I would even say worst : a disownership of the code :" It's not my code"

Because the next step of the Strong Code Ownership  , is the No OwnerShip at all.

The only way to go is obviously the Collective Code Ownership. Doing Pair Programming helps to get that sense, and Code Review, is another way if Pair Programming is not possible.

And then the "Knowledge Transfer" when someone leave the team becomes obsolete and useless.

Knowledge Transfer word is a Team Smell to see that they are not working in an "Agile"  way.