Once upon a time, there were desktop applications. Those mighty charms allow all kind of users to perform complex tasks while ensuring a great degree of protection to the developers: given the broad diversity of hardware and software available, they had confidence that their tests could not have been comprehensive for all the platforms. Those grey days have seen the birth of the sentence “but, it works on my machine”.
Fortunately, technology moves fast and most of the client / server desktop applications were replaced by web applications. This should have removed al possible alibis in theory, still we’re facing the dreaded “it works on my machine” even now that “your machine” should be the exact same browser of the one used by the final customer (and hopefully listed in the compatibility matrix on the service architecture document).
I’m not talking about those wide range of possible issues you can face when you move the application from development environment to the quality / UAT one. And I’m not event speaking about the “a customer enters the bar” joke here (that is usually a lack in product analysis / architecture): I’m speaking about the customer actually ordering a beer, still the bar goes up in flames.
You can now think that this is an article about developer’s failures, and how code and delivery quality is falling down, and bla bla. Well, it’s not like that, because remember that if someone in the developer team answers “it works on my machine”, it’s always a leader / c-level fault.
Don’t get me wrong, I’m not clearing developer’s case here:
Any developer, tech leader, architect… well, anyone responsible for a line of code / procedure / piece of software should always remember that he / she was not hired to make it work on his / her machine, he / she was hired to let it work on all customers’ machines
Still, I feel like these kind of answer are usually the sign that something it’s not working correctly in the leading / management of the tech area.
Thou shall explain web complexity
Well sorry for the biblical quotation here, but I feel it’s kind of fitting: it’s a (hard) duty of the management to make it clear to the team that, even if web applications removed the problems caused by heterogeneous hardware and software, a brand new range of possible issues were born. You’d be surprised how many problems I found were due to bad testing: a medium / complex web application usually has different behaviours depending on
- logged user profile
- browser culture
- cookies
A good amount (must say, a very large amount) of errors I’ve tracked were due to the developer testing the same customer behaviour, but with one (or all) of these point differing from the customer’s ones. Web applications added these kind of complexities, and you should be able to train your team to let it understand and react to these during the test phases.
Thou shall call the customer
Anyone who has worked long enough in technology field likes to think to the customer like one of those “Uber Lusers” from Tales from a Machine Room. Well, I can’t deny that sometimes this fits pretty well, but in most cases customers are not “lusers” but simply suppliers of some other internal customers, sometimes probably wishing to see them fail or playing some sort of internal power play. There are obviously toxic exceptions to this rule, but most of the times picking up the phone (skype / meets / whatever) and politely explain to the customer that you’re not able to recreate the issue in your own scenario, and trying to understand what’s going on from his / her side, is enough to understand and solve the issue. Always keep in ming the three most likely to happens reasons for an error to occur are on the customer’s side, but this doesn’t always mean that it’s a customer’s fault.
Thous shall teach corporate identity
Following “last, but not least”, this point is by far much more important that the previous ones: your team needs to understand what corporate identity is, and that every weird answer could damage it, both if the employee reply “it works on my machine” directly to the customer or if he / she use it internally, creating delay and communication problems. Customers hire tech companies to resolve their problems, not to have further problems arise.
Consider also that this kind of answers could lead to a (hopefully wrong) feeling that you’re not totally in control of your application: “it works on my machine” could be easily translated to “I don’t really have a clue of what’s going on, I simply know that in an ideal scenario it should works and that’s all. Also, I’m not able to analyse logs, nor I’m willing to do it even if I had the expertise. Oh, and your browser / phone / fridge / whateverdeviceyoureusing sucks compared to mine”.
Management should always be aware about how much a rough (or a lack of any) answer could affect external perception of the company, and should made that crystal clear to the whole team.
Thou shall spot other variations
The dreaded “it works on my machine” it’s the most famous sentence, but there are a great variety of similar ones, maybe less used but with the same power. Take your time to analyse your team’s answers and spot the ones that could lead to similar problems. Here’s a quick example:
- That’s weird
- It worked yesterday / this morning / last month / any other point in time that is not now
- I haven’t done anything (this is particularly tricky: the side message of this is that there’s a “fire and forget” methodology, where developers are not responsible anymore of anything as long as something goes into production and pass the first round of tests. It’s another word from “extreme laziness”)
- Did you try to reload the page? (ctrl+alt+del anyone?)
- It must be something strange in the data (the worst of all: developer could be right, but he / she doesn’t even take the time to prove it, or at least provide some feedback to IT pro working on data layer to check it)
Stay hungry, stay foolish
Ok, enough with quotation now, but really: always question yourself and your team, obviously in a clean and productive way. Any developer, team leader or c-level dreams about a project going live without any problem, ever, but we know that it’s (almost) impossibile. Shit happens, and the key here is to not be lazy, and teaching our team not to be lazy too.
Customer isn’t always right, but isn’t always wrong neither and, incidentally, customers are the ones that pay your bills. “Staying hungry” and always seek for the cause of a problem instead of trying to skip or avoid it could be difficult and somewhat time consuming, but it came with a great degree of benefits:
- Keep you and your team well trained: “problem solving” isn’t only an empty word you write in your resume
- Keep the customer happy and confident about your company’s responsiveness and your application’s stability and performance
- Keep the sales department happy. Yes, you read that right: spending a couple of hour in solving a problem is way better than trying to explain those hate email from customer’s management and the reason why the last invoice has not been paid.
Photo by Markus Spiske on Unsplash
Be First to Comment