Mr. Hanka suggests that the only verification is an “over-the-shoulder” audit by a pair programming partner. Pair programming entails more than just watching the code. The person driving — writing the code — is working tactically, i.e., focusing on the current method, for example. The person's partner, however, is thinking strategically, i.e., how the code fits into the class, and will interact with other classes. The partner also enforces coding standards, suggests alternative approaches, ensures that the tests are written first and generally ensures that the code being produced is of the highest quality. Having a partner is a real-time code review!
Beyond the pair programming aspect, coding Extreme Programming is supposed to be performed test-first. The unit tests are written as code, and the actual production code is written in order to make the test pass. The verification is right there in the unit test! XP prefers automated unit tests, such as the xUnit frameworks, which allow developers to perform a vast amount of testing at the push of a button.
Verification is also performed in the form of the customer's acceptance tests. These tests, too, can be automated, even written in code. However, an external automated testing tool would work fine.
The acceptance tests are based on the User Stories, which are high-level requirements. The User Stories are always documented in some form — XP suggests putting them on index cards, an idea borrowed from CRC cards. There is no reason why a technical writer could not begin working on the manual based on the User Stories and acceptance tests.
Note as well that at the beginning of each development iteration, the user stories are further broken down into the actual engineering tasks that the developers must perform in order to implement the stories. These, too, are documented in some persistent form, such as index cards.
So Mr. Hanka's assertion that “In eXtreme programming, there are no written specs: the customer communicates them by word of mouth, and documentation is mentioned only in passing” is simply incorrect. What XP says is that you should only create as much documentation as is really required.
I realize that for ISO 9000 and DO-178B there are stringent specification and documentation requirements in order to provide traceability, but that doesn't preclude the use of Extreme Programming. What XP asserts is that, in most cases, we are unable to correctly predict all of the specifications required, and that we must create an environment in which we can quickly adapt to the changes which invariably occur.
The practices of Extreme Programming is based on many established best practices from the field of software development. XP just says, “take them to the extreme”:
- If code reviews are good, take them to the extreme (real-time, i.e. Pair Programming)
- If testing is good, take it to the extreme (write the tests first, and test all the time)
- If iterative development is good, etc.
Regarding life or safety-critical issues, it depends on how XP is applied. When XP speaks of a release, that doesn't necessarily mean that the software goes into production. I certainly wouldn't want to fly knowing that the ATC collision-avoidance user story wasn't going to be implemented until the next release!
One of the facets of Extreme Programming is local adaptation, i.e., making it work in your environment. That could mean augmenting the amount of documentation in order to meet regulatory requirements. However, simply because XP eschews up-front design and documentation doesn't mean that some measure of it can't be performed. Even the RUP says that you should be performing the architectural and design work incrementally. The bottom line is not to throw the baby out with the bathwater simply because the XP practices as written don't fit your organization.
I suspect that many people mistrust the XP approach because of a hang-up about waterfall model thinking.
Waterfall model is excellent at taking already worked out solutions in one domain and transferring them to another domain, e.g., computerization of previously manual payroll processes.
However, many other structured thinking approaches, e.g., the ISO-900x stuff, have incorporated the presumption that waterfall applies without consciously realizing that incorporation.
In situations where waterfall does not apply, this presumption of its applicability leads people astray.
Many, many systems presume waterfall without either explicitly stating that presumption or providing evidence or justification for it. Many times waterfall is not applicable, so a conscious review would indicate the presumption of waterfall to be invalid.
Any system which does not presume waterfall fights the prejudice that the unconscious presumption of waterfall creates — and it isn't just ISO-900x; standard accounting practices, standard reliability practices, and all design and analysis techniques for areas which are already well worked out presume waterfall.
This is as it should be for fields which are mature and solving problems for which solution methodologies pre-exist. We do not want bridge designers to get creative and try to design totally new kinds of bridges.
For areas wherein maturity is not yet achieved, the assumption that the techniques of reusing already known solutions in an already known process is an insidious error. But error it is.
Just as applying XP to a batch-process payroll programming project would be silly, so is applying waterfall to programming for a system of a new kind for which no prior equivalent ever existed.
You should not hammer on screws, nor should one attempt to screw in nails.
Kevin G. Rhoads
In describing pair programming, Dave Rooney states his Utopian view of what he would “like” to happen but I suspect that it doesn't happen in real life that way. Does anyone really think that one programmer thinks strategically and the other thinks tactically? Maybe in some cases but I think not in the majority of cases.
Does anyone think that the observing programmer enforces code standards? Again, maybe in some cases but I think not in the majority of cases.
He also says that the second programmer ensures that the tests are written first and the code is “of the highest quality”. Does anyone actually believe that statement? Gimme a break! He assumes that the watching programmer is some sort of guru/manager type. What if he is an inexperienced novice? Then he is almost certainly not doing any of the things Mr. Rooney asserts.
If his logic were true, then the waterfall model would work perfectly every time because the waterfall's promoters also have their own Utopian views of how it “should” be done. However, just like the over-hyped XP methodology, the waterfall often fails because it is not “done right” in practice.
Anthony DaSilva Jr.
I have a fair amount of experience with XP. One of the biggest problems I've seen is that some engineers are more than willing to let their “partners” do all the work. If the skills and drive of the partners aren't similar, XP hurts overall productivity.
Patrick M. Berry
Berry Embedded Software, Inc.