The Three Laws of XP

I was just readying David Tchepak's inspiring new year's resolution and also re-read his linked article "There is no U in Collective Ownership" and I thought that it sounded very much like an adaptation of Isaac Asimov's First Law of Robotics. So, just for fun, I wondered if all three laws couldn't be adapted as laws for practicing coders.

1. A Coder may not harm the code base or, through inaction, allow the code base to come to harm.
2. A Coder must follow the guidance set up for the code base except where such practices would conflict with the First Law.
3. A Coder must protect their livelihood as long as such protection does not conflict with the First or Second Law.

While this is mostly in jest, I do think this works as a pretty good set of guidelines. The overarching principle here is that code quality must be the highest goal, followed by consistent application of team standards and finally, that not wanting to rock the boat is no excuse for letting quality slip.

Of course the hard and subjective term here is code quality. It's easy to slip into academic excercises of aethestics and call them quality, just as it is easy to label horrible spaghetti code as pragmatism. My personal test for quality is best expressed by the following questions:

• Does it solve the problem at hand?
• It it easy to test?
• Is it the simplest possible thing that could work?
• Does it avoid code duplication?

It just happens that following the Uncle Bob's SOLID patterns is a good way at achieving all these.