Hacker News Reader

Comment by deanCommie | Hacker News Reader

"Well, it looks like we pranked ourselves this year. Due to a bug, the Mic Drop feature inadvertently caused more headaches than laughs."

It wasn't a bug it was a feature. Maybe I'm too much of an engineer but I HATE when PM's/managers/PR representatives just classify all unexpected and undesired behaviour as "bugs". A "bug" implies I made a mistake. I didn't make a mistake. I developed EXACTLY what you told me, after numerous rounds of confirmation and feedback loops. It's not a bug if it's doing exactly what it was supposed to.

View on HN

In the pop-out compose, it _replaced_ the send&archive. In the regular compose/reply/forward, it added another button to the side. I'm thinking the "bug" is that in the pop-out, it replaced the send&archive, so people _inadvertently_ clicked it out of muscle memory.

Nah, the bug is that it actually triggered on the normal send button as well, for some people.

https://twitter.com/waxpancake/status/715770400555315202

The actual bug was apparently a little more nuanced than 'for some people'. If you tried the mic drop button in an empty email, it would fail to send. If you then used that same email draft and sent it regularly, the effect would still apply.

https://twitter.com/cabel/status/715769273545785344

The tweet i linked contains those details. ;)

That's a pretty bad bug! I imagine a pretty standard behavior would be open a compose window, notice the new button and click it out of curiosity (safely, since you have a blank email), and then go ahead with your normal email.

That is brutal.

I guess this kind of thing is why we no longer have flight simulators in our spreadsheets and so forth.

It's hard to screw things up too badly with something like the flight simulator. It's just a hidden toy completely disconnected from the rest of the program.

But when you start messing with the user's content as a joke, god help you.

> It's just a hidden toy completely disconnected from the rest of the program.

Hopefully!

For fun, on our site one of the developers made it so that if you entered the Konami code, every image would be replaced by random cat pictures. This was immediately ripped out of prod a few weeks later when a client asked why there were a bunch of cat photos in their dashboard. Still no idea how they triggered it.

We all felt very stupid and unprofessional.

I once did this on an internal app, we had a hotkeys library installed, so I added the GTA cheats to raise and lower your wanted level. It just added a temporary notice in the top right of your screen, nothing major. Turns out that if you mashed the keyboard, the library didn't properly handle 6+ character combinations, and would fire the callback anyways.

The send & archive button is optional and doesn't show up in everyone's gmail interface.

Bugs absolutely can originate in the analysis and design phases. In fact, they tend to be the most expensive ones.

Yes, the word "bug" isn't restricted to only implementation, but it certainly has that connotation. In deanCommie's case, it sounds like the PM is using the existing connotation of the word "bug" to assign blame to the implementation when it correctly implements the broken design.

When the list of "bugs" are used in performance metrics which affect your career, correctly assigning blame becomes important.

Agreed, bug can lack nuance. We have subtypes for our bugs in our tracker and try to use them liberally. Generally spec defect (as opposed to code defect) is only used when someone closes a bug "by design", at which point you say the design is wrong.

I like that flow: open bug > close as by-design > reopen as spec-defect > change spec > re-implement new spec

It's an effective way of putting power in the hands of people impacted, for better or for worse. I've certainly reopened "by design" bugs in areas I don't own because I think the design it wrong. Done with tact (and usually a note explaining/alerting the person) it generally goes over well.

Well, to be fair, I suspect PM's/managers/PR representatives HATE when angry engineers go on knee-jerk rants about how a bug which they know nothing about is a "feature"... :-)

A bug doesn't necessarily mean bug in implementation/code.

Bugs can happen at any stage of the development cycle. Typically the farther away a bug is found from the stage it entered the more expensive it is to fix.

EDIT Wording, pre-coffee.

You don't have any responsibility for what you build? Maybe it's on you, too. (As a PM, I HATE when engineers are full of confirmations and feedback loops but cop the 'not my fault, I just build exactly what you tell me' attitude the moment there's something to fix)

The PM is responsible for the requirements. If my PRD fails to be explicit or is not involved in the QA process, the PM needs to take ownership. Yes, everyone is responsible for the UX, but the PM especially.

Yeah well, when I find a bug I go to my PM and I say "Dude, I messed up. Here's the problem. Here's what you need to tell the customers to do/not do. Here's what i need to fix it."

When there's a problem with requirements and the users are screaming, and the system isn't doing what they want (but exactly what they built), the PM comes to me and says "We fucked up. You need to drop everything and fix this right away."

This has been the case with almost every PM I've ever worked with.

Reply on news.ycombinator.com