3 ms·

Frequent updates, in the old days, meant that a vendor had poor QA. I think that's probably still the case most of the time today, too.

hulitu 2y ago
See Microsoft and Crowdstrike for details. /s
tivert 2y ago
> Frequent updates, in the old days, meant that a vendor had poor QA. I think that's probably still the case most of the time today, too. The internet has normalized poor QA. The bosses don't give a shit about QA anymore because it's so cheap to just push out a patch. I mean just look at old video game magazines that talked about the software development process: the developers would test the hell out of a game, then test the hell out of it again, because once it was burned onto a $100 cart (in 2024 dollars) it wasn't ever going to change. Now games can remain buggy and unstable for months or even years after "release."
- dasil003 2y ago
  I never worked on games, but I did do a streaming video app for PS3 in 2010, during the time period when it was arguably the best media center box available. Working with Sony (SCEE) on this was eye opening how their QA process was set up. Essentially you formally submitted the compiled app (C++ and Flash!) to them, and then tickets would come back and you'd have to address them. QA was a separate org so you never really met them in person, all issue discussion would happen in-band to the ticketing system. QA had all the power to decide when and if this thing would ship, much moreso than Product or Engineering. I can't say the process made a ton of sense for a downloadable app powered by a multi-platform online service, but it was illuminating as to how the high quality bar of 90s/00s console games was achieved.
  - chrisjj 2y ago
    > then tickets would come back Luxury! With Nintendo you'd often get only one ticket. Any further bugs would cost you further submissions, and months of slippage.
    - dasil003 2y ago
      Thanks for jogging my memory! I believe we did two rounds of QA, the first was unlimited but shallow and high latency, the final QA I believe was called Format QA and there was a quota, if you had more than 6 issues or something you were rejected and had to go back into the queue (for months).
  - specialist 2y ago
    aka acceptance testing aka The Correct Answer™ For the products I managed in the 90s, I put QA/Test in charge of releases. Very unusual. The results were awesome.
- numpad0 2y ago
  Windows XP. High profile zero day cases and Windows Update during 2000s created a "security updates are like dietary supplements" mindset.
chrisjj 2y ago
The differece is it no longer means the vendor's QA is poorer /than average/.
jjav 2y ago
> Frequent updates, in the old days, meant that a vendor had poor QA. I think that's probably still the case most of the time today, too. Back in the 80s and 90s if you had bad QA you'd ship very buggy software and customers hated you because they had to live with it for months and months until the company managed to do another release. And then it was costly to ship off those floppies to every customer. So there was a very real price to pay, in money and reputation. Then it became possible to do updates online. Initially it was a nice way to deliver an emergency fix if necessary, but you mostly continued to do nice QA'd releases every now and then. But as with everything, when something becomes too easy it gets abused. So companies realized why do much QA (or any QA in extreme cases). Just push updates all the time and hope for the best, if customers (who are now QA) scream, push another update tomorrow. Break quick, fix quick. It's mostly unsatisfactory if one values stable quality software.
- hulitu 2y ago
  > So there was a very real price to pay, in money and reputation. Microsoft Corp. would like to have a word with you. /s

hulitu 2y ago

See Microsoft and Crowdstrike for details. /s

tivert 2y ago

> Frequent updates, in the old days, meant that a vendor had poor QA. I think that's probably still the case most of the time today, too. The internet has normalized poor QA. The bosses don't give a shit about QA anymore because it's so cheap to just push out a patch. I mean just look at old video game magazines that talked about the software development process: the developers would test the hell out of a game, then test the hell out of it again, because once it was burned onto a $100 cart (in 2024 dollars) it wasn't ever going to change. Now games can remain buggy and unstable for months or even years after "release."

dasil003 2y ago
I never worked on games, but I did do a streaming video app for PS3 in 2010, during the time period when it was arguably the best media center box available. Working with Sony (SCEE) on this was eye opening how their QA process was set up. Essentially you formally submitted the compiled app (C++ and Flash!) to them, and then tickets would come back and you'd have to address them. QA was a separate org so you never really met them in person, all issue discussion would happen in-band to the ticketing system. QA had all the power to decide when and if this thing would ship, much moreso than Product or Engineering. I can't say the process made a ton of sense for a downloadable app powered by a multi-platform online service, but it was illuminating as to how the high quality bar of 90s/00s console games was achieved.
- chrisjj 2y ago
  > then tickets would come back Luxury! With Nintendo you'd often get only one ticket. Any further bugs would cost you further submissions, and months of slippage.
  - dasil003 2y ago
    Thanks for jogging my memory! I believe we did two rounds of QA, the first was unlimited but shallow and high latency, the final QA I believe was called Format QA and there was a quota, if you had more than 6 issues or something you were rejected and had to go back into the queue (for months).
- specialist 2y ago
  aka acceptance testing aka The Correct Answer™ For the products I managed in the 90s, I put QA/Test in charge of releases. Very unusual. The results were awesome.
numpad0 2y ago
Windows XP. High profile zero day cases and Windows Update during 2000s created a "security updates are like dietary supplements" mindset.

chrisjj 2y ago

The differece is it no longer means the vendor's QA is poorer /than average/.

jjav 2y ago

> Frequent updates, in the old days, meant that a vendor had poor QA. I think that's probably still the case most of the time today, too. Back in the 80s and 90s if you had bad QA you'd ship very buggy software and customers hated you because they had to live with it for months and months until the company managed to do another release. And then it was costly to ship off those floppies to every customer. So there was a very real price to pay, in money and reputation. Then it became possible to do updates online. Initially it was a nice way to deliver an emergency fix if necessary, but you mostly continued to do nice QA'd releases every now and then. But as with everything, when something becomes too easy it gets abused. So companies realized why do much QA (or any QA in extreme cases). Just push updates all the time and hope for the best, if customers (who are now QA) scream, push another update tomorrow. Break quick, fix quick. It's mostly unsatisfactory if one values stable quality software.

hulitu 2y ago
> So there was a very real price to pay, in money and reputation. Microsoft Corp. would like to have a word with you. /s