Last week the company I work declared that “XP is the answer to our development process”. I have never worked in an XP environment before so it will be interesting to see how well it works. But before I jump into this I wanted record some thoughts I have about XP and then as time goes on I will comment on them if I gain any insights.
It’s all maintenance
It recently occurred to me that XP has one fundamental difference from most other methodologies. Most other methodologies, that I am familar with, make a distinction between initial development and maintenance. XP on the other hand, fundamentally, says, “It’s all maintenance”. In XP initial development is the time between creating the first file and the first unit test running correctly. After that it’s all maintenance.
In some ways I really like this idea. The idea that you can just implement a simple solution and then later fix any problems that really occur is quite seductive. It should be cheaper over all, and controlling cost is an important and often overlooked part of our jobs as engineers, because you do not waste any time solving “problems” that, in actuality, will not occur in production. On the other hand, as systems evolve they tend to collect cruft. I fear that even “ruthless” refactoring will not be enough to overcome the cruft.
Vision
It seems to me that the most important single input to the software development process is a strong, and shared if there is more than one person involved, vision. In the surgical teams proposed by Brooks in “The Mythical Man-Month” this vision is solved by have only two programmer of which one is the chief programmer who unilaterally settles differences in judgment. XP tries to solve the vision problem by having a metaphor. For simple system it is possible that a metaphor would be sufficient. I think the risk with using metaphor for a software system is the general risk associated with metaphorical reasoning, that you will take it too far. To prevent that from happening I think you need a deeper understanding of the problem and solution and the metaphor is used, primarily, for communication purposes.
This deeper understanding is where I think architecture and design come in. Let me be clear, I do not think up front design usually solves the problem. In fact, I have never seen a “correct” design. In my experience designs are usually broken in fairly fundamental ways which only become apparent once you start implementing the design. However, I think that the act of designing as a team is very important. It is a way of developing a shared vision and a deep understanding of the problem and some approximate solutions. The complete exclusion of design as a process in XP raises the risk of team lacking a shared vision, especially if team membership is fluid.
Pairing
There are many studies that show that there is amazing variance in the performance of programmers. Some show productivity differences of up to 28:1 (that is, the best programmers are 28 time more productive than the worst programmers). It is probably safe to assume that programmer productivity follows a bell curve so most programmer are in the middle some place. Pairing would tend, I think, to rob you of the increased productivity of you best performers. At first glance this seems really bad but it would have the effect of reducing the variance in productivity which might make a project more predictable. I think the question is, is the advantage of reduced productivity variance worth the fact that you achieved it by lowering the median productivity? I think you would have to decide that on a per team and project basis. For some projects it might be well worth the cost.
The other side of pairing is the inherent personality conflicts that will arise. In addition to the personality conflicts there is the chance for technical conflicts. In a team of peers, like XP seems to espouse, there is no final arbiter for technical decisions. This seems to leave space for conflicts to arise if a pair of people cannot come to a consensus about a particular solution. Perhaps this is not really a problem but if it is the only way to solve it is with some sort of ownership which would completely break XP.
Post a Comment