Unpredictable Requirements

Moez Chaabouni, CIO of Hondros College, wrote a letter to the editors of CIO magazine that I really liked. I'm posting it here verbatim because I'm sure I'd butcher his message if I tried to paraphrase it.

To argue the difference between missed requirements vs. changing requirements is futile. From a customer vantage point it's unimportant, and just serves as semantics to widen the gap between IT and its customer base.

The point is that IT and software engineering deals with a lot of unpredictability. It's not a bad thing. It just is. Regardless of how mature and formal the software engineering process is, developing software is closer on the predictability scale to “waging a war” than it is to “paving a road”. Too many unknowns, changing/missed requirements, changing technology, unproven architectures, unproven tools, unpredictable staffing market, fickle customer base, and the list goes on. A comparable effort to a software project would be the creation of a concept car.

The automotive industry has it right. They come up with a concept car first, then take the effort and time (another project) to make it consumer ready. We often, in creating software, do not take this two step approach. We can't afford it. So we keep turning up concept projects and tweak them as we go to make them more palatable to the consumers.

There is no magic bullet here. The use of software engineering best practices such as incremental and iterative development, getting closer to the customer, understanding the business, and managing change/requirements are necessary but not sufficient. The question we have to ask ourselves is the following: Are we willing to pay the price tag for what it would cost to develop robust industrial strength software, or are we plagued forever to produce toy products?