Comment by ankit219 | Hacker News Reader

Comment by ankit219 | Hacker News Reader

Parent Full thread

Almost all the developers I work with never started working on a bug until i gave them the right steps to replicate it - even if the bug is reported by a user. A very stupid example i can think of is this: the developer designed a login form on web and mobile with the password field as expected, but forgot to uncapitalize the first letter of entry in password. Like if your password is abcdef, on mobile keyboard (unless you are careful), it would be entered as 'Abcdef' and would not work. The issue was reported thrice and he said that there is no error, and did not fix. Then later it struck me (and i tried it on safari while he tried on the mobile responsive version of chrome) that it is this issue. Not saying the developer should not start working right away, but the expectation is that if they actually paid attention to what was reported, it would not have taken this much time to figure out what the issue was. There needs to a midway which varies from org to org depending on their workload.

> is it more probable that this work should be minimised

I guess this is where automated tests can come in. You fix something and see if passes the unit tests. But then everyone has their own approaches. For him, fixing a similar bug twice is worse than finding all possible mistakes at once.

I like to use two principles:

* smoke means fire

* a contained smokey fire is sufficient to hide the start of a wildfire

This means:

* keep your errors at 0. If it "can't be kept at 0" you're either too far gone or thinking about the issue incorrectly.

* user complaints are errors. Just because they aren't clear doesn't make them any less so.

There is a perception that users go out of their way to make unfounded complaints. In my experience, getting any complaints is the issue.

There is also a perception that some errors aren't important. If you have a channel to recieve an error its because it has business value. If a dev I was managing ignored a p/w entry bug due to non-dupe / assumed user error without significant digging and user interaction I'd be livid. Most businesses will lose significant value if users perceive the act of logging in as difficult.

> If it "can't be kept at 0" you're either too far gone or thinking about the issue incorrectly.

Okay, how do you handle a network failure, a full disk or a faulty RAM stick?

I see your overall argument, but at some point you've got to accept that you can't handle everything.

keeping errors at zero does not mean errors don't happen, it just means you resolve them all, you don't ignore any. Perhaps it should be 'keep errors at 0 or 1'.

So if you're small, a RAM issue is something you deal with manually and rarely. As you get bigger you'll transition to automated failovers that still get looked at individually. Then you'll scale up to the point where these aren't freak occurrences. Now its important for you to have a strategy to identify the issue and its follow on issues, and resolve them. Its also past time you think deeply enough about your setup to be able to contain them so you can stop surfacing them as errors - they are now part of a normal business process. You want to make sure that too many are surfaced as an error (and too few), and any effects you can't currently recover from automatically are also errors.

Its perfectly possible to "keep errors at 0" without ignoring any output.

I agree with you on most parts, but not about keeping your errors at zero. In a fast moving environment, there will be mistakes or things that are missed. ideally, bugs should not have any attached meaning - yes there was an issue and now it is fixed. Good thing we found it today compared to a few days later. That is it.

Getting complaints from users is a good thing, but yeah missing them or not fixing them when you come across them is. As a user, I would be overjoyed if I reported a small issue, and the company fixed it quickly.

Being livid is natural, but I was pretty sure the developer himself knew he screwed up this time, so no point expressing it. Plus as I explained in the earlier comment, this escaped for so long because we did not have many cross device users. So did not affect that many users. Just for my experience, I check this every single time i test a website before it goes live. (and also check with other keyboards than just Gboard)

I think that, but then our feedback report include things like "How do I change my outlook password?".

I don't work at Microsoft.

Sounds like you aren't being clear about your role to the user.

After your suggested fix, how does a user enter the first letter of their password in upper case if that's what they want?

Maybe you were expecting the dev to go through all the passwords and fix them so the first letter of all passwords is lower case? Oh but if they were following best practices they don't know the password, they only know its salted hash.

Since the app was already shipping without the first letter being auto-lowercased that would suggest there were plenty of passwords with the first letter already upper cased, also something you can't test for easily if all you have is salted hashes.

Sorry, it requires more context. The reason this issue wasnt highlighted before was 1/ Many of our users were on laptop and did not use mobile site as much 2/ There was rarely a switch for those who used the mobile site (as in they rarely used desktop, else we would have caught it sooner). The fix was a longer one. We obviously had to have the same convention for a password in desktop and mobile web. For mobile users, after we made a fix, if they had trouble logging in, we asked them to capitalize the first letter of password and try again- when they logged in, we made them change the password and if they could not, they reset it. At the point we found it, we were pushing mobile site to users as an internal growth activity, and we were able to navigate it. It wasnt the best UX to be fair, but we potentially averted a bigger disaster at the time we did it.

PS. Yes, we were hashing the passwords.

Actually the correct fix is correctly flagging the field as a password field, which fixes the capitalisation problem on iOS and Android.

We also had to take care of the few folks who signed up with wrong password(in the sense that they never intended the password to start with a capital letter.). Changing the field value was a part of it - applicable for all new users. The complication was the people who already went through the flow and would have trouble logging in now.

Reply on news.ycombinator.com