Tech frustrations! Explicit or implicit bug, enhancement – why should you care?

PropTech Tips

The video below contains foul language. If you are a sensitive viewer, please skip it 🙂 In case you are wondering, 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:

  • You’re learning to use new tech. You will definitely be encountering moments of frustration (lessening fortunately as the learning curve flattens out)
  • You’re using existing tech. But, as these systems evolve, issues slip through the net and land in your lap

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!

Types of issues

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.

Software provider to blame

While no software engineer tries to create bugs, these can happen, undetected. Therefore the issue is theirs to deal with.

Issue type 1. Explicit bug

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.

Grey area – no-one to blame

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.

Issue type 2. Implicit bug

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.

Issue type 3. Enhancement

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).

Sidenote

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:

  • If we add these extra steps to meet your needs, we will also add system complexity which could irritate or intimidate you.
  • By doing this we will make these guys happy, but upset those guys.
  • If we build this feature, until it’s done, we have to put the building of that feature on ice.

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.

Types of issues meeting types of users

“What happens when the Unstoppable Force meets the Immovable Object?” – quote from Superman

CRE tech adoption lifecycle

(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.

Innovator / early adopter

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.

Late majority or laggard

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.

Related posts

Menu