7 ms·

It's rather frightening that a bug as serious as this one got past Apple's QA. It seems like the list of known problems with the new Disk Utility is growing - r

by maxton 9y ago

It's rather frightening that a bug as serious as this one got past Apple's QA. It seems like the list of known problems with the new Disk Utility is growing - recently there was a submission about how High Sierra's Disk Utility did not show unformatted disks.

matt_wulfeck 9y ago
I really hope a head rolls for this mistake. That team needs some new leadership.
- georgespencer 9y ago
  Or maybe: “I hope they improve and nobody loses their job”
  - nevir 9y ago
    Agreed. You can be sure that whomever was involved with the bug will probably never make that mistake again.
    - stinos 9y ago
      You can be sure ... probably So which one will it be? On a more serious note: this really depends on the person in question. Not everyone has that state of mind it takes to be extra wary when you find yourself in a similar situation where it went worng before. I've worked with people who made pretty severe mistakes, were pointed out, nodded 'yes', only to just make the exact same programming mistake a few months later. And again, and again.
      - cakes 9y ago
        Agreed - something I've personally seen drive such a thing in some people are plans/checklists/etc (nothing wrong with having these) where the recognition of severity is overriden with checking as many boxes as possible in an 8hr day as is required.
    - marnett 9y ago
      They asked for new leadership, not new developers. The 'mistake' wasn't a bug in XYZ, but a leader who took feature deadlines ahead of actual functionality. That leader should be axed - that's what GGP was discussing.
      - deleted 9y ago
        [deleted]
    - mikestew 9y ago
      You can be sure that whomever was involved with the bug will probably never make that mistake again. We all like the story of "just spent a million dollars training you", but experience tells me that there is absolutely no assurance whatsoever that any random person won't be repeating that mistake in the future. EDIT: and to be clear, of what tiny bit I know, I blame test more than dev. From the dev side I can see someone making a stupid mistake (that for the record I could just as easily make) swapping the foo with the bar, or some mis-click in IB. But I'm still astounded that this made it out of test without getting caught.
  - whack 9y ago
    Sadly, errors like this are usually symptoms of organizational problems. Code cleanliness, testing and QA, are all very easy to sweep under the rug, and neglect/abuse organizationally. In the short-term, everything still seems fine. In the long run, problems like these keep snowballing. Once a trend like this starts, the only way to reverse it is via organizational shakeups. I hope I'm wrong, and that a bug like this happened purely due to dumb luck. But somehow, I'm doubtful.
    - matt_wulfeck 9y ago
      Exactly why I (the GP) was advocating a change in leadership.
      - georgespencer 9y ago
        I mean… just lol at the extraordinary series of inferences here.
  - mikestew 9y ago
    Without knowing the circumstances of how the bug was introduced, and the testing infrastructure, I'm torn. On the one hand, I could be convinced that some believable scenarios exist where test might have missed this through something other than incompetence and sloppiness. OTOH, I'm having a hard time imagining what that "believable" scenario might look like. You hand me Disk Utility to test, and I'm going to do some exploratory testing to cram some large strings in both fields, yada yada, we all know the drill. You know, take a moment or two before hitting the code editor. I'm just grasping to figure out how I wouldn't find this bug in like five minutes. And that's before formal tests start getting written. There's missing a bug, and then there's "maybe testing software isn't for you". In summary, I very much want to give Apple the benefit of the doubt here, but I'm sure having a hard time of it.
    - Someone 9y ago
      I think that bug could easily slip through once, even with a test script. Let’s say the script says - enter P as password - enter H as hint - click “OK” - unmount the disk - mount it again - check that the dialog shows the hint H - enter P as the password ... Now, if P isn’t obviously a password and H isn’t obviously a hint (let’s say P is ‘foo’, and H is ‘bar’), it takes only one slip of the mind to turn that “check that the dialog shows the hint H” into “check that the dialog shows the string you just entered as hint”, and from there, it’s only a tiny further slip to “yes, that’s a string I just entered”. To me, it seems at least as likely that that gets past a tester once as it is that a programmer writes that bug. It still should be highly unlikely to get throug multiple rounds of testing by multiple testers, though. A better test description would use a more password-like value for P (say ‘tqbfjoald’) and a more hint-like value for H (‘quick and brown’), decreasing that risk.
      - mikestew 9y ago
        A better test description would use a more password-like value for P (say ‘tqbfjoald’) and a more hint-like value for H (‘quick and brown’), decreasing that risk. Maybe I expect too much, but a tester with any experience is going to use strings like "thePassword" and "theHint" to reduce those brain farts. One doesn't have to test software very long before discovering why using "test", "test" as the respective strings for that dialog will bite you. I agree with your hypothesis, but it's one of those mistakes I'd expect out of a fresh-out-of-college person, and I would expect those folks to be testing, say, TextEdit and not security-sensitive pieces. But there are so many unknowns that I still reserve judgement. I'd just like to know what piece of the process broke down such that something like this gets out the door.
- somethingsimple 9y ago
  If this happened because of a single person's mistake, that's an organization flaw. No individual should be punished for this. Instead, the process (or lack thereof) that led to such an awful bug being shipped should be identified so that something like this does not happen again.
- GoToRO 9y ago
  It's called experience. You don't fire people with experience.
- pbarnes_1 9y ago
  Nope. Why? Shit happens.
- FabHK 9y ago
  I like the aviation mind set on mistakes: accidents are thoroughly investigated, the aim being to find out what happened and how, not to pin blame. Then, when facile "explanations" of human error are floated, the investigation goes beyond that and examines how the whole system (training, management, SOPs, organisational structure, etc.) allowed the error to happen and, in particular, to escalate into an accident. Mistakes happen, inevitably – a good system will catch them early enough.
  - cortesoft 9y ago
    One of our rules for all learning reviews after an incident: "Plan for a world where we are all just as stupid as we are today" An action item to fix something can never be "don't make that mistake again." You have to make a change to the system to find and prevent the error, not a change to the people in the system.
bdcravens 9y ago
Perhaps they were busy testing header font sizes in iOS?
- jsz0 9y ago
  I wish they'd spend some time testing font sizes in macOS. I'm either going blind or the font sizes on macOS, especially things like tab titles, are getting harder to read.
  - epmaybe 9y ago
    Aren't these font sizes modifiable in Accessibility? I've turned on things like contrast and reduced transparency just to make it easier to read, and I'm very young.
    - jsz0 9y ago
      The accessibility options do help some but I don't know of anyway to increase the font size. It become a weird mix of fonts that are either way too big or way too small. I use RDM to switch between different scaled resolutions depending on what I am doing to get readable text these days.
- dep_b 9y ago
  Given the amount of crashes I see have existing applications to large titles that also doesn't seem to be the case.
- gowld 9y ago
  Engineers couldn't see the bug because the code was displayed in Narrow Light font weight, color grey
  - paulddraper 9y ago
    Their only mistake was not making it an ever lighter grey.
raimue 9y ago
It clearly shows that a public beta with lots of volunteers cannot replace a small group of employed testers going through a list of user stories, verifying everything works as intended.

by maxton 9y ago

matt_wulfeck 9y ago

I really hope a head rolls for this mistake. That team needs some new leadership.

georgespencer 9y ago
Or maybe: “I hope they improve and nobody loses their job”
- nevir 9y ago
  Agreed. You can be sure that whomever was involved with the bug will probably never make that mistake again.
  - stinos 9y ago
    You can be sure ... probably So which one will it be? On a more serious note: this really depends on the person in question. Not everyone has that state of mind it takes to be extra wary when you find yourself in a similar situation where it went worng before. I've worked with people who made pretty severe mistakes, were pointed out, nodded 'yes', only to just make the exact same programming mistake a few months later. And again, and again.
    - cakes 9y ago
      Agreed - something I've personally seen drive such a thing in some people are plans/checklists/etc (nothing wrong with having these) where the recognition of severity is overriden with checking as many boxes as possible in an 8hr day as is required.
  - marnett 9y ago
    They asked for new leadership, not new developers. The 'mistake' wasn't a bug in XYZ, but a leader who took feature deadlines ahead of actual functionality. That leader should be axed - that's what GGP was discussing.
    - deleted 9y ago
      [deleted]
  - mikestew 9y ago
    You can be sure that whomever was involved with the bug will probably never make that mistake again. We all like the story of "just spent a million dollars training you", but experience tells me that there is absolutely no assurance whatsoever that any random person won't be repeating that mistake in the future. EDIT: and to be clear, of what tiny bit I know, I blame test more than dev. From the dev side I can see someone making a stupid mistake (that for the record I could just as easily make) swapping the foo with the bar, or some mis-click in IB. But I'm still astounded that this made it out of test without getting caught.
- whack 9y ago
  Sadly, errors like this are usually symptoms of organizational problems. Code cleanliness, testing and QA, are all very easy to sweep under the rug, and neglect/abuse organizationally. In the short-term, everything still seems fine. In the long run, problems like these keep snowballing. Once a trend like this starts, the only way to reverse it is via organizational shakeups. I hope I'm wrong, and that a bug like this happened purely due to dumb luck. But somehow, I'm doubtful.
  - matt_wulfeck 9y ago
    Exactly why I (the GP) was advocating a change in leadership.
    - georgespencer 9y ago
      I mean… just lol at the extraordinary series of inferences here.
- mikestew 9y ago
  Without knowing the circumstances of how the bug was introduced, and the testing infrastructure, I'm torn. On the one hand, I could be convinced that some believable scenarios exist where test might have missed this through something other than incompetence and sloppiness. OTOH, I'm having a hard time imagining what that "believable" scenario might look like. You hand me Disk Utility to test, and I'm going to do some exploratory testing to cram some large strings in both fields, yada yada, we all know the drill. You know, take a moment or two before hitting the code editor. I'm just grasping to figure out how I wouldn't find this bug in like five minutes. And that's before formal tests start getting written. There's missing a bug, and then there's "maybe testing software isn't for you". In summary, I very much want to give Apple the benefit of the doubt here, but I'm sure having a hard time of it.
  - Someone 9y ago
    I think that bug could easily slip through once, even with a test script. Let’s say the script says - enter P as password - enter H as hint - click “OK” - unmount the disk - mount it again - check that the dialog shows the hint H - enter P as the password ... Now, if P isn’t obviously a password and H isn’t obviously a hint (let’s say P is ‘foo’, and H is ‘bar’), it takes only one slip of the mind to turn that “check that the dialog shows the hint H” into “check that the dialog shows the string you just entered as hint”, and from there, it’s only a tiny further slip to “yes, that’s a string I just entered”. To me, it seems at least as likely that that gets past a tester once as it is that a programmer writes that bug. It still should be highly unlikely to get throug multiple rounds of testing by multiple testers, though. A better test description would use a more password-like value for P (say ‘tqbfjoald’) and a more hint-like value for H (‘quick and brown’), decreasing that risk.
    - mikestew 9y ago
      A better test description would use a more password-like value for P (say ‘tqbfjoald’) and a more hint-like value for H (‘quick and brown’), decreasing that risk. Maybe I expect too much, but a tester with any experience is going to use strings like "thePassword" and "theHint" to reduce those brain farts. One doesn't have to test software very long before discovering why using "test", "test" as the respective strings for that dialog will bite you. I agree with your hypothesis, but it's one of those mistakes I'd expect out of a fresh-out-of-college person, and I would expect those folks to be testing, say, TextEdit and not security-sensitive pieces. But there are so many unknowns that I still reserve judgement. I'd just like to know what piece of the process broke down such that something like this gets out the door.
somethingsimple 9y ago
If this happened because of a single person's mistake, that's an organization flaw. No individual should be punished for this. Instead, the process (or lack thereof) that led to such an awful bug being shipped should be identified so that something like this does not happen again.
GoToRO 9y ago
It's called experience. You don't fire people with experience.
pbarnes_1 9y ago
Nope. Why? Shit happens.
FabHK 9y ago
I like the aviation mind set on mistakes: accidents are thoroughly investigated, the aim being to find out what happened and how, not to pin blame. Then, when facile "explanations" of human error are floated, the investigation goes beyond that and examines how the whole system (training, management, SOPs, organisational structure, etc.) allowed the error to happen and, in particular, to escalate into an accident. Mistakes happen, inevitably – a good system will catch them early enough.
- cortesoft 9y ago
  One of our rules for all learning reviews after an incident: "Plan for a world where we are all just as stupid as we are today" An action item to fix something can never be "don't make that mistake again." You have to make a change to the system to find and prevent the error, not a change to the people in the system.

bdcravens 9y ago

Perhaps they were busy testing header font sizes in iOS?

jsz0 9y ago
I wish they'd spend some time testing font sizes in macOS. I'm either going blind or the font sizes on macOS, especially things like tab titles, are getting harder to read.
- epmaybe 9y ago
  Aren't these font sizes modifiable in Accessibility? I've turned on things like contrast and reduced transparency just to make it easier to read, and I'm very young.
  - jsz0 9y ago
    The accessibility options do help some but I don't know of anyway to increase the font size. It become a weird mix of fonts that are either way too big or way too small. I use RDM to switch between different scaled resolutions depending on what I am doing to get readable text these days.
dep_b 9y ago
Given the amount of crashes I see have existing applications to large titles that also doesn't seem to be the case.
gowld 9y ago
Engineers couldn't see the bug because the code was displayed in Narrow Light font weight, color grey
- paulddraper 9y ago
  Their only mistake was not making it an ever lighter grey.

raimue 9y ago

It clearly shows that a public beta with lots of volunteers cannot replace a small group of employed testers going through a list of user stories, verifying everything works as intended.