Project Constraints

Ages ago in "Code and other Laws of Cyberspace" the idea of "The New Chicago" is mentioned. It says that behaviour is regulated by four things: the market, the law, social norms and architecture (or nature, the world you are in). In the original context it is described as a way that behaviour is limited in cyberspace and society and that the law can effect the other three to cause indirect behavourial change.

It seems equally appropriate in the context of a project. There are ideas that you can apply in a project that are (or at least should be) constrained in the same ways: laws, markets, social norms and architecture. In a project each constraint does not seem to have an equal effect on the smooth running of a project (they certainly could of course).

Laws don't usually have an impact on the constraints of a project. While people may break the law during the project or whatever and may have to go to court, get arrested, etc. the impact, at least in the projects I've been in, are quite minimal. They may effect certain requirements on the project (compliance to certain laws for instance) but generally they are well known or least able to be handled in a fairly straight-forward manner. No one generally argues whether a certain law should be abided by and usually people are available to ensure that the laws are readily adhered to.

Similarly, market forces have only a few effects on project cohesion as many decisions are already made for you - language, operating system and other infrastructural decisions are not usually up for grabs in a project. While some people may wish to do C# on Linux or Ruby instead of Java most people and projects limit scope in this way and resources are usually selected (or self-selected) on this basis. You don't usually find a .NET programmer amongst 10 Java programmers trying to convince them that Microsoft is the way to go.

The two key areas that do seem up for grabs and do cause problems are with norms and architecture.

The type of teams really dictate the level at which these two things can change and the methodology you use to achieve it. A well run XP project seems to allow a more participatory effect (mainly through pairing and pair swapping). If new ideas are accepted and tried then overall the team seems to have more of say. Certainly, the norms imposed on individual developers seems much higher in an XP project.

The opposite effect, somewhat of a project anti-pattern, is where a developer (or worse more than one) will go off and find a proposed solution and try to apply it to the entire project using a different norm or architecture. The rest of the team, quite rightly, does not feel ownership of the new technique or code. The effect of this is the opposite of what XP is trying to achieve - code ownership and cohesion. The key pushback to this is that no code goes into the project unless it has been paired on. If it is a project that does require a lot of investigation then each member of the team should get the ability to devise a solution to be considered.

There is of course limits placed on any project to change - moving languages or paradigms (OO, procedural, functional, etc) that XP has to abide by too. But in some ways XP seems much more honest (or from some perspectives limited) especially considering the "Extreme Programming Bill of Rights" where these kinds of changes will effect estimates, quality and progress.