I’ve been exploring various facets of XP lately because I think it has a lot to offer the practice of software development. I’ve recently done pair programming, dealt with something akin to an onsite customer, and done plenty of testing with NUnit.
One issue that I’ve noticed, however, is that XP assumes skilled developers. By skilled I mean knowledgeable of various technical issues, good at interpersonal communication skills (not something developers are noted for), experienced in the art of software development, and motivated to improve themselves, among other qualities.
Surely most of the initial adopters of XP were the grizzled veteran coders, the ones that eat pointers for breakfast and deliver by lunch. Most of these programmers had been down the path of increasing process, only to find more process and less actual development. And none of it helped improve anything. IT projects continued to fail regularly, either by being late, being over budget, under-delivering, or delivering what was specified but which failed miserably when actually used in the wild.
This led to a large group of disenchanted developers, kind of like the 60’s for geeks. Geeks walked around carrying signs saying “write code, not documents!” This was a generation ripe for something as totally off-the-wall as extreme programming. It even had “extreme” in the name! How cool is that?!
The reason XP worked initially is because of the quality of the developers involved. When XP says “do not document unless you need to,” the experienced developers know that they might still need to do things like UML diagrams (agile UML, for Pete’s sake!) or ERDs or CRC cards or whatever works.
But, as XP makes the jump from the early adopters to a larger pool of developers, the average skill level is decreasing. Now when XP says “do not document unless you need to,” some of the developers think that it means to do no design period, confusing the process of design with the documentation of the design. “But,” you say, “XP says it works with skilled developers only!” Let me respond with a driving analogy. When a well-known car insurance company surveyed a group of drivers, 87 percent said that they were above average drivers. We both know that this is statistically impossible. Assuming that everyone that actually is a good driver knows it (maybe it’s printed on their insurance bill), 37 percent of the people that took this survey are dead wrong. Or, worse yet, 74 percent of the bad drivers did not know they were bad drivers (37/50 = 74%). It is the classic problem of being unskilled and unaware of it.
The issue is, how do I know what the is minimal amount of design and documentation? The short answer is “whatever will reduce overall development activity to the smallest amount.” In other words, any activity, or group of activities, that will pay for itself over the course of development. But how does someone that has not been through too much process and too much design know how little they need? It’s like the blind men and the elephant.
Of course, experience is the key. But short of that, the only solution I have come up with so far is to make sure that every developer knows the basics. By “basics” I mean things above programming language syntax but below process and methodology. Development tools such as the UML, object-oriented analysis, design, and development, ERDs, data flow diagrams, etc. You might not use some of these tools very often, but you need to know what their advantages and disadvantages are, and you need to actually have used them to do something, even if it was a "learning project."
Let me know what you think.