-
Truths & Lies
As Niels Bohr put it, the opposite of a truth is not a lie, it’s simplification.
A perfect thruth’s inverted companion is the perfectly reflected lie. No such lie can exist that does not also carry with it the truth. Misinformation is not missing information, it is just information that needs extra attention in order to decode. It is only when information is discarded that we really start lying, and start to miss out on things.
This is a mantra to live by, professionally as well as privately. Any approach to software development, beit traditional, agile, or other, will be subject to evaluation and scrutiny if we hold this statement true.
It is of course, in the terminology of Martin Fowler, the traditional engineering methods with their roots in natural sciences and hard systems thinking that lie foremostly subject to special attention, with their prime focus on functional analysis and strategies of decomposition.
Abstraction through such approaches is not just interpretation, abstraction is a disciplined simplification of a problem area, to make it fit into a possible, visualized problem solution. It is the simplification imposed by this abstract visualization that we must never hold as neither truth, nor lie.
But is it at all possible to uncover every aspect of a particular situation to avoid discarding information, to avoid lying? I don’t think so. But the question should not be whether decompositioning approaches, functional analysis and abstraction are valid or invalid as tools, the real question must be what degree of validity we are attributing the artefacts produced by performing such abstractions and interpretations, and to which extent we’re going to base our development on these kinds of artefacts.
No software development project can take place without the use of any of these disciplines, no matter how extreme. We cannot escape having to use these approaches, so we need guidance in ensuring that when we lie, we do so about the most insignificant things. We need people. We need to stay social. We need to continuously question ourselves, our interpretations, and what we hold to be true. We can only do so through continuous sparring and feedback with and from the people who are going to take what we create into actual use. It’s not what we do that makes us great developers, it’s what we learn underway.
Stay true
|