clarity of purpose

Paul makes a nice comment here regarding whether the “build vs. buy” simple example scales. His example revolves around less clear requirements for the “widget.”

“We still don’t know what we want, but now we don’t know how to get this package to do it for us either.”

Of course, one of the problems in this example is not knowing what is needed. My example of the millisecond resolution timer software package was based around very clear requirements and a very clear “domain of requirements” (I just made that up, but it sounds good). That is, not only did the commercial off-the-shelf (COTS) package meet my precise needs, it also supplied other features useful to me. Features like self-calibration for improving accuracy.

When the purpose isn’t clear, it can be difficult to find a package that meets your needs (or find too many). In addition, it can also be a case where you end up looking for a way to employ whiz-bang features just because they came in your COTS package.