A Question of Correctness
How are “uncertainty” and “correctness” related?
Doesn’t uncertainty mean my definition of correct may change? Could I have totally correct direction, but still have uncertainty?
John is referring to the way I try to pinpoint the exact “pain” Agile is expected to address by an executive considering an Agile implementation. Specifically:
Agile is all about effectively addressing uncertainty, I say. I stress that Agile does not address complexity per se. It might indirectly help with complexity if it leads you towards deeper thinking about Complex Adaptive Systems. For example, you might consider evolving the product architecture in the course of your Agile project instead of pre-defining it. However, Agile is not a “medicine” for complexity pains.
Nor is Agile about correctness. A hyper-productive Agile team could actually go fast nowhere implementing a poorly conceived product. The “real time” feedback loops of the project team might help uncover that a product is mis-conceived. However, independent of the team feedback, you still need to determine what correctness means to you and how you would assess it as the product evolves.
The answer to John’s good question is that correctness is a matter of the level of abstraction as defined in Hardware Engineering: A DEC View of Hardware Systems Design. Suppose you are coding a service enabling passengers to check in for flights. At the functional level, the correctness of the coded service is fairly unambiguous and (hopefully) will be established through testing. The check in service might be correct functionally, but still subject to change. For example, an airline could aspire to enable its passengers to check in through any mobile device whose volume of sales exceeded one million units. Such an aspiration will necessitate fairly frequent changes to support new mobile devices as they cross a threshold of popularity.
So, yes: one could have a totally correct direction, but still have uncertainty.