The video below contains foul language. If you are a sensitive viewer, please skip it 🙂 In case you are wondering, esteemed attorney, Mr Denuto, here is dealing with a bug (explicit bug to be precise)
It’s 2019, and every day you are using tech. Be it internet banking, taxi apps, emailing solutions or work software. Sometimes your tech tools work beautifully. So you feel stirrings of love, and wonder how you ever did without them. Other times, you may find yourself pounding the keyboard or feeling defeated. (Meanwhile techies try soothe your pain using words you have never heard of like implicit bug and enhancement!)
This article is for you if:
This article is written by someone who wears two hats. One, as a user of tech. And two as an operator in a tech startup. As a result, for my sins, I has lived through most phases of the product development lifeycyle, and seen, from both sides, various forms of human tech frustrations on a daily basis. Hopefully this article helps you!
If you, like me, are prone to technology-fueled angst, this article’s objective is to help you avoid the red mist.
I’m laying out the 3 “issue” types you will encounter, and categorising these into “whose neck to throttle”. “Whose neck to throttle” gives some parameters around what behaviour is fair and reasonable. In other words, whether it is appropriate to direct your angst outwards, or whether the circumstances are a bit more nuanced / less black and white.
And some context, the reason why software businesses are in this space: they love seeing the computer help people, and are passionate about eliminating human pain and frustration. Certainly, not the opposite.
While no software engineer tries to create bugs, these can happen, undetected. Therefore the issue is theirs to deal with.
The system is not doing what it should be doing / giving you unexpected behaviour. A great example of this is Microsoft’s dreaded blue screen. Or Excel bombing out while you are deep into some complicated sums, and you haven’t saved.
The two issues that follow below are fairly standard in software. While the software developer holds the power to solve it, no one party is to blame here. The way out here is empathy, good communication skills and patience.
Defined as existing functionality that is operating as designed. Whether there is a bug or not is subjective. Some users may like the feature, others may have a different opinion. Where the pain comes in: the feature may be operating in a way that is different to how a specific user feels the feature ought to be operating. Or the tech solution is unreasonably difficult to understand and places “cognitive load” on you, the user. For more information and examples, see here.
Non-existent functionality which you would like, but which isn’t there. For example: it would be great if you could click a button in an email and your phone would automatically dial that number. Or if your internet banking could integrate with your email, and set up your monthly payments for you, with reference numbers.
Again, whether explicit bug, implicit bug or enhancement – we understand, to you or me as user, the initial pain is the same.
So, the initial pain is a given. Hopefully however this article helps you manage your pain appropriately in the short term. Likewise, for the medium term, good software engineers, acting on your feedback will aim, in amongst their many other to dos, to build enhancements and try resolve the implicit bugs (without the trade offs hurting you).
Spare the software engineers a thought. In dealing with cases in the grey area above – solutions aren’t as simple as they seem, and there are often very good reasons for things working as they do. Software businesses are constantly having to think trade offs. For example:
Meanwhile, of the above happens while dealing constantly with the gnawing frustration that good tech takes so damn long to build! Coping with these opposing forces pulling in different directions is the (very) “hard thing about a hard thing”, and is responsible for huge levels of debate within software businesses. But when you get products right, it’s hugely rewarding and pleasing for all.
“What happens when the Unstoppable Force meets the Immovable Object?” – quote from Superman
(The first image on LHS has had some of the text converted from America to Africa-relevant terms. It covers the product at the top, and the journey through users segments at the bottom from left to right, as the product matures over time.
The second, more conventional, image on RHS provides numbers and a bit more colour on personas of those segments and their perceptions / mindsets)
The technology adoption lifecycle concept, graphic above, comes all the way from 1957 (arising from a study by the North Central Rural Sociology Committee, Subcommittee for the Study of the Diffusion of Farm Practices). The philosophy was adopted and embraced heavily by, among many others, Steve Jobs of Apple. Depending on where you as a user live in the tech adoption lifecycle spectrum, you will have different user frustration tolerances.
Early on in a product’s life cycle, products are maturing and will be fraught with a higher proportion of issues affecting the product’s users (i.e. you). This ranges from either explicit or implicit bug / s to enhancement / s.
If you are one of these (or come from a tech background, or both) as the diagram above indicates, you will be more relaxed about issues early on in a product’s life cycle. Because a) the excitement of new tech over-rides the frustrations associated with early stage products, and b) you know, given time and the product developers having the right DNA, that the product will mature.
If you fall into one of these user segments… We would recommend you either abstain from using products in a relatively early stage of development, or invest heavily in learning the art of deep breathing.
We unpack why our industry is lagging in data – to its great detriment, and despite the obvious incentives. We also share knowledge not commonly known outside of data engineering circles (likely “common sense” to CRE professionals). Then we provide a roadmap explaining what can be done about it
Don’t know what you don’t know. Me too! Well at least that was the case before I tried writing this article. To save you time, here I condense and share my learnings about fibre. Hope you find this efficient summary of info enlightening and helpful.
The days of your back office salary being a grudge purchase are over! As tech automates increasing levels of “hands work” away, these efficient team members, who (crucially) understand CRE, can move into the “head work” that makes your business more competitive. This article explains how.
