Following up on the ideas I talked about in Writing Software Is a Political Act, I discovered Andrew Harmel-Law’s math blog where I found this picture from XKCD.
This made me chuckle but it also made me think – where does the software engineer end up in this picture of the universe? Are we looking down on the mathematicians or are we looked down on by sociologists?
If we are socio-technical engineers, we know that our organisation and our social structure at will have an implicit influence in the designs of our applications. This means that we need to respect the fact that we won’t ever get our designs “right” and be prepared to limit out work-in-progress to leave plenty of cognitive load spare to adjust.
Low Confidence
However the very act of admitting we have an “unknown quantity or quality” means that we have uncertainty in our work. We are admitting that we don’t have the confidence that the thing we’ve built is necessarily correct or complete.
Think of Agile, Scrum, Lean, SAFe, waterfall, Domain Driven Design, Test Driven Design or any other social or technical framework you care to mention.
All of the many frameworks, both social and engineering, and ways of organising ourselves aim to make the unpredictable, predictable. We want to have clearer software requirements, delivery times and quality so that we can realise efficiency. But we all know, that none of these approaches actually work predictably 100% because we still admit that we can’t predict the future or exactly what our systems must do.
The big assumption is that we can treat writing software like it’s a production line. But any software engineer will tell you that writing software isn’t about turning out widgets in a factory. There is too much uncertainty.
This uncertainty adds individual stress to the situation. Will our software work? When will be the next failure? What are we going to do about it when it fails? When is a piece of work ever “done”?
So we can create as much space and time for our solutions as we like, it’s not going to change the fact that our software is wrong. This is a core part of the philosophy of architectural residuality.
So instead of “purity”, perhaps engineers work in terms of confidence or certainty. While we are reasonably confident that our code works, and we can prove this to a certain extent with testing, we will never be 100% confident.
So Engineers sit somewhere between Psychologists and Biologists or perhaps geneticists on this scale of purity. We try to create something that will satisfy peoples’ demands and we have these tools for making it happen but can’t really ever accurately determine the outcomes.
We operate in a non-deterministic world. To pretend otherwise is churlish.
If we want to be able to turn up and enjoy a day at work, then admit to yourself that ultimately you don’t know if the work you put in today is going to contribute to a complete solution or not. Essentially you’re putting the cat into Schrödinger’s box. From then on its state is indeterminate.