In a recent blog post, Marc Clifton who writes a lot at CodeProject, has been exploring a lot of the assumptions and underpinnings of XP. I have been doing something similar with my own company, so this got my attention. He seems to be arguing against the assumption that rapid iterative cycles is a good idea because the cost of customer involvment to test and approve the release is high, too high for many businesses to repeat any more often than absolutely needed.
For, the issue comes down to a few salient points. I have this discussion with developers and our internal users pretty frequently. Developers often don’t want to take the time to write adequate unit tests or do adequate system tests. It adds to the already crunched work load. Developers tend to test what works better than what they haven’t thought of. Developers may not understand the full business requirements beyond the part of the system they are building. Users on the other hand, have almost no tools with which to work other than those that the system gives them. For users to test, they usually can’t do queries, can’t compare results on a screen to expected values stored somewhere else, often don’t know much about the system beyond the part they work in daily, they learn how systems work by wrote, so any change is often seen as *breaking* the system rather than improving it. Assumptions they have not questioned in a long time may have changed, and users often don’t have the tools to verify that the changes they are experiencing are natual consequences of the change, or are in fact bugs. The point of this is to say, *nobody* likes to test and take responsibility to say that a release is ready to go. Users want the developers to do it. Developers want users to do it. Everybody is trying to look good. Yet, testing must be done, and done well or serious problems can occur and usually do.
As a manager, I have to say that x number of features or bug fixes will cause y amounts of testing and that work, like all work, must be effectively managed. Developers have the best tools for testing code at thier disposal. Users have the most understanding of expected behavior. The only way to effectively manage the release of code then is to have these two groups working together closely and often so that the communication of expected results, unintended consequences from users to developers happens frequently enough so that the work can be managed effectively. Waking up on QA release day to find out I now have weeks of new testing, rework, redesign and bug fixing to do does not strike me as a well thought out strategy for managing my employees. My worst nightmare is when bugs are found too late so that earlier releases have to be bug fixed in a way that’s not compatible with the current release or development release. With every branch, you potentially have double the amounts of testing and approval to work on. By using short release cycles, you can reasonably maintain a goal of doing new releases and bug fixes in sync, accomplishing both goals with one set of testing.
One thing Marc doesn’t say, but that *might* be implicit in his views is that the developers somehow know what to do without that user involvement. That implies a really good set of specifications. In the case where a company does work with contractors to get programming done, this is nearly hopeless. If a company isn’t good at software development, they are almost certainly not good at writing specifications. Most often, the person assigned the task of either writing the specs, or with working with the contractor to produce the specs, has not worked with software development enough to understand the fine details of how to express what needs to be done in a way that will inform the developers adequately about the solution. Contractors on the other hand have a stake in getting good specs, but in reality have conflicting interests. They need to get the job done, and unless they are paid by the hour, most likely want to just get busy coding. The situation is similar to the testing situation, the developer wants the users to write good specs, and the users just don’t have the tools or background to do it well and expect the developers to somehow pull the specs out of them. It isn’t until the users get thier hands on the new work that they have any idea if both parties are on the same page with the requirements. Again, the only answer I as manager have come up with that works, is to say that the users and developers must work together early and often. It takes real time, and it must be managed.
Failure to address these points is just putting your head in the sand. You don’t have to accept the XP way to get the job done. But you do have to accept the basic facts of the different skills that users and developers have. Building systems is a social engineering practice, both in deciding what the system must do in terms of organizing people and processes into a working whole, and in how to learn, create and execute those processes. This is why the idea of programming as an engineering practice seems so completely wrong to me. There are engineering aspects of the execution of a program design certainly, but in design and execution of a software development process, it’s purely a people thing.