71–80 of 117 posts
Earlier quoted context omitted.
Directly linking to jwz from HN doesn't lead to the expected result though :)
Sorry for being obtuse, but could you please explain what I'm missing. I hope to be one of today's lucky 10,000
(Assuming you use a browser that sends the referer header)
Earlier quoted context omitted.
Directly linking to jwz from HN doesn't lead to the expected result though :)
Sorry for being obtuse, but could you please explain what I'm missing. I hope to be one of today's lucky 10,000
I think it's currently this: https://cdn.jwz.org/images/2016/hn.png
Little bit related: When I come into a company as CTO, and there are too many bugs, I just close all bugs older than 6 months. Usually that's more than 10% (and the org wasn't capable or willing to fix them). Hasn't created any problems yet, but everyone feels better immediately (and we implement ways to not reach high bug levels again).
This is also why a recent client dumped a decades-long vendor in an enterprise setting that by proxy implemented this approach through a newly-offshored support team that didn't understand the product and stalled on difficult bugs until the bug reports died on the vine even after repeated executive meetings. Ask the account executive how they felt about losing out on an easy seven-figure annual renewal to a rival who won't likely come up for displacement until after the account exec retires.
To add to the sting, the displacement came at a time that the role of the software product was planned for a big expansion. The tab for more licenses and the work was so high but close enough between the incumbent and challenger that it opened the door...and there went an 8-figure year for the incumbent's account executive. Decades of brand-building and relationship management down the tubes all so some support department head can show off on their scope's bottom line.
We understood these were challenging problems to solve, were patient, and willing to put in the significant person-months of time it would take to help solve them. Client leadership however, was not willing to just get indefinitely shuffled onto the bug queue.
We're not stupid. We know what being blown off looks like. We know when we're talking with a Regex Support organization versus a Semantic Support organization. The lag time between realizing that and acting upon it might take a few years, but once it happens in enterprise software, vendors rarely get another shot within another decade.
Earlier quoted context omitted.
Because if they’re not resolved yet, there’s no client suffering from them in short term. If they suffer from such a bug, someone will raise it again.
Users don't always complain, they sometimes simply go away.
Little bit related: When I come into a company as CTO, and there are too many bugs, I just close all bugs older than 6 months. Usually that's more than 10% (and the org wasn't capable or willing to fix them). Hasn't created any problems yet, but everyone feels better immediately (and we implement ways to not reach high bug levels again).
Earlier quoted context omitted.
Wh... why?
> the org wasn't capable or willing to fix them Probably this. Can't fix everything, and the bugs piling up demoralizes many engineers. Six months is a bit low, I'd go higher, but there's no point having a bug on your board that you're not realistically actually going to fix.
Earlier quoted context omitted.
Sorry for being obtuse, but could you please explain what I'm missing. I hope to be one of today's lucky 10,000
If you click the link you see a picture of an egg that looks like a hairy testicle with a quote complaining about HN. (Assuming you use a browser that sends the referer header)
EDIT: Sorry, I think it might actually just be that because I first visited that page before coming in via HN, I've just been seeing the cached version of the real page, instead of the DDoS-protecting testicle.
Earlier quoted context omitted.
Wh... why?
Because if they’re not resolved yet, there’s no client suffering from them in short term. If they suffer from such a bug, someone will raise it again.
This seems like an unrealistically perfect product.
> If they suffer from such a bug, someone will raise it again.
And this seems terrible for everyone involved. Terrible for the customers who have to nag, stay "on the ball" and make sure bugs get re-filed, and terrible for the developers who have to figure out which old (fake-closed) bug reports actually match the new filings.
Earlier quoted context omitted.
Wh... why?
Can imagine it's for a lot of reasons. Like: - Improves morale - Focuses the team - Makes the task more approachable Etc. The important ones will probably bubble up again in due time.
I'd buy this if the bug was actually gone. But it's not! Closing a bug report doesn't make the bug go away!
> - Focuses the team
A decent bug tracker should have priority levels for various bugs, surely.
> - Makes the task more approachable
I don't understand. Can you elaborate?
> The important ones will probably bubble up again in due time.
This seems like a terrible waste of everyone's time.
