Hacker News new | past | comments | ask | show | jobs | submit login

I was on the team that wrote the requirements for the original version of Radar, in 1988. At that time each department was using it's own flat file database for bugs. Also at that time, there was a very large testing group. All testers at Apple were together: more than 400 testers. We had a strong culture of testing. We had pride in ourselves and our company. This was pretty much thrown away when the group was disbanded in 1989. Professional testing culture was replaced with the attitude that only developers mattered. Hurray for "Total Quality Management" and later Agile, I imagine. I was gone by '91.

We originally designed Radar so that bugs would be verified as closed by the person with most interest in seeing this happen: the tester assigned to that part of that project. Then management swooped in with an edict that bugs must be verified as closed by whomever originally reported them. This is a stupid idea, because it creates the perverse incentive that no one should report a problem if they are outside the team (because then you are committing to verify the fix, which just means more work for you that has nothing to do with any of your main responsibilities).

When I pointed out that the system would now discourage people on different teams from helping each other, the sponsoring director said "that's what pink slips are for." Direct quote. Soon after that I resigned from the design team.

Without reasonably skilled and principled leadership, you just don't get quality software. And "quality is everyone's job" is just an empty and childish slogan. Excellence is not transmitted through slogans and wishful thinking. You have to assign responsibility, provide resources and time (which means lowering velocity of new development), and follow-up.

The fundamental reason why it doesn't happen is the technology market is not efficient. Quality is, in fact, not as important as career testers wish it were. You can get away with doing terrible work and not lose your job. The fact that Apple pays no significant penalties for having buggy products insulates it from our slings and arrows.






I worked at Apple from ~1995-2002. The status quo described here, where the original bug reporter has to verify and close the bug was a beautiful thing. Nobody saw it as a disincentive to file bugs. It's not "extra work" to confirm that the team you begged to improve software had actually done what you suggested. The alternative, that software teams internally determine that the bug has been "fixed" without understanding nuances of the original report, is much worse. I love Apple's standard that the original bug reporter should be responsible for closing a bug, and I only wish that the privilege extended to third-party bug reports made via Bug Reporter.

I disagree. The person who wrote the bug is in the best position to decide whether the problem was actually fixed.

I could easily see it go either way; it really depends on the bug. Some obvious issue, like "this button should do X but it does Y" can be verified by almost anyone. But some issues need the attention of the original author to really verify the bug. Maybe what needs to be done is someone in QA needs to attempt to verify the bug, or "pre-verify", and then it goes back to the originator for final verification, who can also verify it, or simply close it if they feel like QA did a good job.

That sounds like a good idea. As long as the originator has the option of having the last word, internal attempts to verify can only help.



Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: