When I was helping to develop the MVS/XA mainframe operating system at IBM in the 1980s, we had a disciplined process for software development. We knew that a bug fixed in requirements was a hundred times cheaper than if we repaired it after it was out in the field. So we were careful and diligent, writing thorough specifications documents, then carefully crafted design docs, and only then could code begin.
All good software engineers know this is the way to go. Or at least that’s what we’d always thought.
But it turns out we were wrong. And not in a small way. Continue reading