Unintuitive aspects of computing
We've all heard the hype. Computers are here, they want to make our lives easier, solve our problems as we sleep. Some might even pop the coffee pot on, take care of shopping or vacuum your abode.
What people rarely, if ever, communicate are the edge cases, darkened corners which pervade and disrupt our digital utopia.
What can go wrong?
- Things that seem reasonable, don't happen
- Things that seem unreasonable, happen
- There is lack of clarity about how things work
- How things work, often change
Things that seem reasonable, don't happen
The first time I remember encountering this, I was very young and I'd sat down at our amstrad laptop and I was exploring the system of DOS.
I gleefully typed commands which I had little idea about and responded to the machine as a young child might. Do I want to do something? No. Well that wasn't very exciting, so I think I'll try again with yes.
It wasn't long before I became unstuck having formatted the A: drive, which contained the operating system. Far from calamity, I proceeded on, blissfully unaware, I'd just deleted that computers record of the universe... Until my father arrived home and attempted to turn the thing on.
Are you sure you want to do something? A poor excuse for guard rails for the developing mind.
Things that seem unreasonable, happen
1-2 weeks ago, whilst working on bringing data into a new system, I encountered something pretty useless.
If the code running the application changed, all in-progress activity stopped, no record of activity was present, no progress or indicator of a catastrophic failure.
This is what I would consider to be unreasonable, if not utterly stupid behaviour. Immediately I was incensed at the lack of thought that had gone into this. My mind turned to remitting the issue after logging the issue.
Upon reading the documentation of the deployment platform, which to their credit existed; I got a sinking feeling.
To shut down the app, CF sends the app process in the container a SIGTERM. The process has ten seconds to shut down gracefully. If the process has not exited after ten seconds, CF sends a SIGKILL. CloudFoundry app-lifecycle docs
Imagine that you have a friend over for tea, or a meeting with a co-worker. You have a less than favourable exchange, you ask them to leave. They have not left in 10 seconds, so you brutally murder them. I don't think that many will support this set of actions and outcomes.
Multiple expectations of reasonability were violated here.
- We had no log messages that this was happening
- The documentation for this is in an unexpected place
- The documentation for this was not referenced elsewhere
- This seems like somewhere a big red flashing box should appear
- When I raised this with others, "We know" was at least one strategic member of staff viewpoint
Once I knew what was wrong, it took a very short amount of time to work out a strategy to overcome my immediate needs.
There is lack of clarity about how things work
Thankfully the past 20 years of my life, things are improving in this area of software. Things are still not as self-obviate as I would like, but we're getting to an era where people are employed as operators of software.
Operators, often cannot program that software, and may have very little idea about configuring. Perhaps this is someone else job. "Would all amber multi-skill staff please come to the checkouts please."
When I first started at my job, and then a month or so later when a colleague started. We all had questions about how various pieces of the software fitted together.
Consulting the documentation, a phrase YAGNI was strewn with almost blissful abandon around. There is a famous quote about this sort of thing...
If you do not know where you come from, then you don't know where you are, and if you don't know where you are, then you don't know where you're going. And if you don't know where you're going, you're probably going wrong. Terry Pratchett, I Shall Wear Midnight
The result of this attitude was that many members of staff were less productive than they otherwise would have been. Luckily we changed that and write down a lot more, even focusing on how to write things more accessibly.
How things work, often change
The first of many gotchas in computing, is that there is more than one way to do a thing. Our picture-perfect is stained with diappointment of a reality that context is still needed. It's just not communicated.
There are probably a whole set of decisions about when it's right to do a thing, when it becomes inappropriate, or less than desired, many steps to get something in just the right position that it might succeed often enough to be suitable.
Cognitive load being one of the things we seek to reduce, computers often act as designed, but do not communicate or provide simple tooling to see what is happening under the hood.
Even in my role as software engineer, we use terms such as heisenbug, far too often rely on not knowing, but observing. History has lessons about this sort of thing.
What really helps with this is flow-charts, spreadsheets of known event names, tracking column changes outside of code for the auditor, or would-be assistant.
So far as I can tell this is not deliberate, but yet it is so pervasive in an industry created by thinkers, logic. I Hope that at some point, how fast will become much less celebrated than how well a thing was done.
What do I want to do, and have done?
Hoping someone has read this far, even if it's me 6-months from now, less hair, less happy. This is what I would like.
- Make small, focused things
- Have those things report
- Aim not to surprise your users
- Try to frame questions in another light. You may notice, I prefer the humorously absurd
- You might not need things, consider that others will
- Please document as flow-charts decisions, processes
- Please find UX people who are not re-branded graphic artists
- Try to keep a log of where you have been
If you are a systems engineer I have a broader ask.
- Please consider correctness over speed
- Don't roll around when a number gets too high
- Develop serialization formats to convey context of computation
- Persist valid state early, and often.
- Think about how to cope with mistakes and failure.
- Document even unfinished, or undesirable things.
- Try to make things as accessible as you can.