5 ms·

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.

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.

greggman3 6y ago
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.
- ankit219 6y ago
  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.
  - etherealG 6y ago
    Actually the correct fix is correctly flagging the field as a password field, which fixes the capitalisation problem on iOS and Android.
    - ankit219 6y ago
      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.
Normal_gaussian 6y ago
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.
- ankit219 6y ago
  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)
- Sebb767 6y ago
  > 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.
  - Normal_gaussian 6y ago

greggman3 6y ago

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.

ankit219 6y ago
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.
- etherealG 6y ago
  Actually the correct fix is correctly flagging the field as a password field, which fixes the capitalisation problem on iOS and Android.
  - ankit219 6y ago
    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.

Normal_gaussian 6y ago

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.

ankit219 6y ago
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)
Sebb767 6y ago
> 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.
- Normal_gaussian 6y ago