Sunday, December 11, 2005

Requirements validation anti-pattern

One thing I have seen a lot of is validating requirements with a completed system. This has been sometimes misnamed "User Acceptance Testing".

This typically means that someone shortchanged requirements gathering, by making a guess at what the users need, and having the developers do it.

In its most pathological mode, "User Acceptance Testing" also suggests that the users are doing functional testing as well, and that developers do not need to test their product.

Requirements Uncertainty Anti-Pattern

One strategy I have seen for 'managing' requirements uncertainty is to hire permanent or contract developers so that they are available to respond to requirements changes. I call this the 'embrace and extend' anti-pattern. Instead of minimizing the chances of this risk materializing, or limiting the effect of this risk in the event it does materialize, this approach accepts the maximum penalty for risk materialization from the outset, and actually encourages requirements changes. Why do managers engage in this anti-pattern? What are some alternatives?

"We're not a software shop."

Working as a developer in IT organizations, I hear this objection "We're not a software shop" come up a lot when people suggest things like using revision control, or writing down requirements, or formalizing change management.

Saying that because we are not a software company, we can do a good job of developing software without employing the techniques of professional software developers is like saying that because I am not an athlete, I can win a triathlon without training.