cost, and that’s collateral damage to the business. And I don’t know what that cost is here; usually it’s an intangible cost. But you probably have some sense of the level of frustration and so on, not knowing that no vehicles are going to crash or that nothing is going to sink the project.
ROBINSON: So I guess it would be safe to say that your costs are astronomical. [laughter]
MARKOSIAN: The execution costs, yes … Any questions?
DOYLE: One of the things that we had done was to have people specialize in a particular survey, and often you end up with one programmer on a complicated survey. But a lot of these testing things might suggest that we need teams; we need more than one on a project. Are you recommending that we change our staffing to that, instead of having person 1 on one project and person 2 on another, we have two people on the same projects, or something else?
MARKOSIAN: Well, I think … I can’t really answer that because I don’t know enough about the application. In the applications I’ve been describing here there have been multiple people working on one project …
DOYLE: And the minimum number you’ve listed is two programmers …
MARKOSIAN: Right, right. Well, one would expect, then, this has come up before, that there’s a lot of experience that should be shared among the developers, even on different projects. And that’s what I don’t understand well enough, to advocate a position there.
SMITH: I risk making things too light here, but there’s a saying that the optimal number of programmers on a project is two. [laughter] For example, Unix was originally built by two people at Bell Labs, and all the Bell executives said that they didn’t know it was happening … and if they had known, they would have stopped it.
ROBINSON: For the productivity of the pair programming, where do you measure their productivity? Is it the amount of code that actually makes it to release-level quality?
MARKOSIAN: No, their effectiveness is in producing code of acceptable quality … well, yes, it’s … certainly, the metrics that are used such as lines of code—and we could look at those, function points is another metric—all have their problems. In the area of XP, I think that the focus is on quality and in meeting deadlines, and in reducing risk, so the best metrics for that, I don’t know. Any other questions? Okay, thank you.