For your own code, the white space code formatting sensitivity and other python 'features' are pretty much more annoyance than value. When you are subjected to it, it's annoying as all get out.
The benefit comes when having to contend with someone *else's* code who has had to put up with it. So basically it's a big self inflicted aggravation for the greater good of collaboration.
To me, the people who go all frothy at the mouth over python produce hard to read code in their language of choice. People who do not use python, but don't go bitchy when they have to deal with it tend to also write pretty readable code in their own language. The intent in python is simply to force the issue by making it hard for the interpreter to follow when it is also hard to follow for a human. This can be added to a project in any language that has central automated repository, but python just enforces it at the lowest level, no matter how lazy the coder/maintainer want to be about it.
There are unfortunately downsides, but there are downsides everywhere. I have encountered confusing code in brace delimited blocks because indentation was screwed up (and while pre-emptively feeding every chunk of random code through an indent program is possible, it's not something that always comes to mind).
FWIW, the same argument about editor would apply to the 'tedium' of braces. Many editors when contending with languages you hit '{' and enter and poof, proper indentation and close brace inserted.
The problem is that we can point and yell 'stupid' at whatever we want, but reality is that whitespace is mangled by a lot of things, so use of a language very sensitive to whitespace as a 'learning' language has some challenges. If I made a language that required vowels in the keywords to have umlauts, I could run around and say it's stupid that a lot of keyboards don't have keys for that built in, or I could admit that I made a choice that ignores that reality.
That said, I've seen a lot of C/Java/etc code just get really really mangled because it still compiles and people get slack about whitespace because it doesn't matter. Then if you go in and indent it, some maintainers will get mad because they don't want 'ownership' of a line to change in annotation just because someone changed indentation. So there's some upside to being a pain in the ass about indentation to force the issue. Of course the same could be done with a style check in continuous integration, but that's extra work that a lot of folks would skip.
Even if the font is fixed with, the width of a 'tab' is not universal. If your text editor says tabs are rendered as 4 spaces, and you mix in some spaces (may not be your fault, might have been someone else in the codebase, though continuous integration on python projects generally set up to reject tabs).
It's not necesarrily a terrible idea, for for a project that's commonly interpreted as 'easier', the whitespace based grouping causes a lot of headaches. To say the headaches are worth the result and you'll get used to it is one thing, but to pretend it doesn't cause headaches is silly.
Defend your trademark you mean. Aspirin was a trademark, but the drug would have been able to be produced genirically either way by now (as acetylsalicylic acid).
Meanwhile, Xerox is not a genericized trademark, though some think it is. Escalator, cellophane, kerosene, and others are generic trademarks.
Though the sentiment is correct, failure to protect trademark risks forfeit of the protection. Patents do not have that feature, a company is free to submarine a patent all day long (though waiting until it's very popular to start using it increases the likelihood that an army of people will find *something* to invalidate the patent, there's very little that's truly novel, at least not things that are independently invented over the timespan of a patent lifetime).
I personally don't like dealing with books when I can get it electronically (I prefer an e-ink device, which is even lighter than a book, and looks as good as a book), but some people just prefer a book..
Given the distinction described, programmers being just implementation and 'developers' actually understanding the needs and wider context, programmers really should be on the decline, and there shouldn't be room for a 'software developer' to need 'programmers' as time goes on.
Already the divide has been largely responsible for some of the most infuriating software I've had to use. The people actually creating it have no clue about the wider context. Meanwhile you have 'architects' that don't know the first thing about how the code works or can work or most critically how it wouldn't work. Somehow enterprise industry has latched onto the model of 'architect' versus 'implementer' and never shall the two cross and it makes for some terrible software.
Sometimes it makes a mountain out of a molehill (don't need a massive team to maintain what amounts to be a simple script, and often giving it a massive team makes it senselessly more complex) and sometimes it does address some issues of tedium associated with a genuinely complex project. For the first part, people should not confuse 'importance' with 'complexity'. People presume that something very important warrants a large team, which is often wrong. For the latter, the large team may be warranted, but no coders should be exempt from understanding the context for their work. I've seen that last bit happen all the time, to the point of bad coding decisions resulting in the programmer resenting the paying customer for what ultimately is the programmer's lack of understanding the use case rather than the customer 'not being smart enough to deal'.
For never ever putting an 'appliance' directly on the internet. Particularly when it comes to closed source. It's attractive to think you can get something ready to roll specific to your needs, but it also means putting a huge maintenance burden on the provider of that appliance, with a huge potential set of code that could be compromised, and a higher latency for getting fixes (some appliances need to wait for their image provider, who waits for a well-known distribution to publish, who might wait for upstream to have a fix, on their best days).
At least with software that pulls in only the parts that are truly unique to the use case, then a vendor only is responsible for their own mess, which is a bit easier.
Too bad the trend is appliance-ification for *production*, using a docker pull or download a canned VM, instead of managing an image directly. These are slick and cool ways to evaluate and stand up something quick in a 'trusted' isolated environment (though one should always be vigilant regardless of 'internal' or not, the risk/benefit is different). When you go to an internet facing service, more care should be exhibited.
I agree (and my work system is woefully not up to date and I have no privilege to fix it, and tear my hair out over a number of known bugs that have been fixed, but my company has not seen fit to push updates for them). However the link would be helpful if some person who is in charge of managing deployment of updates is aware there is a fix to be had. So the story is valid to show (it's not like it's a non-story because update is available), but it should have indication of fix for those empowered to do so.
processor speed has improved since it was first designed
Note that even as it is today, I have observed such flash heavy sites that a web browser can bring a pretty modern system to its knees. If you are implying that even slower flash would be acceptable because systems are faster, that would be a bad call. The issue is that for the most part, the role flash served can now be served with HTML, Javascript, and CSS, which do have open implementations. Rather than re-implementing the flash runtime, making every effort to port web content away from flash would go further toward sanity.
To the extent flash needs to be a thing for sake of preservation (btw, same theoretically applies to Java applets, which don't work in most modern browsers), it should be some guarded thing limited to browsers, not some ubiquitous thing that can spring up in embedded html like email clients and help systems.
The issue is that as they are being run, that's the only likely scenario to occur at all:
"didn’t know how to trust that drivers would make room in the ceaseless flow, so the human minder had to take control to complete the maneuver." "We don’t want to get into an accident because that would be front-page news."
The state of affairs is that the autonomous cars give up when faced with a situation they aren't 100% positive they wouldn't cause an accident in the attempt. They only go up to 25 or 35 mph depending on the operator. I recall one incident when it got hit making a left turn and it was the cars fault, but the autonomous system had disengaged, giving it a pass. The question should have been why did it require a human operator to perform the left turn. If all you do is go in straight lines, make turns when things are overwhelmingly safe to do so, only ever go under 35 mph, and the instant any required maneuver could be a risk, surrender to human driver then it's easy to have such a pristine record.
They also aren't 100% blameless in getting rear ended: "coming to an abrupt halt, for example, when they sense a pedestrian near the edge of a sidewalk" A human hanging out near a curb will cause it to abruptly hit the breaks when a human driver currently would see that pedestrian and better judge their intent. Of course in theory everyone should be giving everyone else a long following distance, but abrupt stops to avoid what a human discerns as a non-existent threat is not good for safety or traffic flow.
There's a middle ground to be had. Sure there are a lot of ubiquitous bending of rules that should be addressed (amending or enforcing). Speeding is among those. There are an essentially infinite set of 'exceptional' circumstances that are relatively rare in occurrence, but critical when they occur. Having laws to cover that would require an infinite set of laws. One could say you could get close enough with more and more complex laws, but at some point the law becomes outright impossible to understand, well before the laws cover all the circumstances.
all of the robot crashes have been minor fender benders
Note that, for example, Google's cars are never going faster than 25 mph. So it's a little disingenuous to say they only get into fender benders when a human in the same situation would likely not have anything more than a minor fender bender either, even if they were very bad at driving.
For sales tax applied 'fairly' across the board, it drives up the prices for those who can barely scrape by as it is. Income tax has a way to provide relief to those with low household incomes. If you start trying to target 'conspicuous consumption' type things with a premium tax, you get back into a game of crazy loopholes to sidestep elevated taxes.
There are tons of problems with US tax code, but a focus on income versus consumption is not a deficient thing.
But if you have a pure red, green, or blue, then you have a very limited range for that color. This is why for photo realistic, it's no big deal, in nature you don't really see concentrations of just a primary color, and not usually in a gradient . It's when an artist sits down to create the content and chooses much more simplistic colors and patterns, which interestingly enough causes a unique problem for the medium when only 256 levels are available to represent any particular primary.
Now dithering up to fuzz away the bands in a gradient is pretty much imperceptible, but the compressor sees a more 'noisy' source than if the band width is reduced by a factor of 4. Of course ideally a compression algorithm simplifies the model the same way at a certain compression level, but at best it's considering the dithering to be detail that can be discarded if necessary rather than that specific pattern of detail not mattering one bit.
They suggest that they are going to have an automated process to transcode content a few ways and use some automated quality check to decide what meets the threshold. Or they are trying to make changing from CBR to VBR sound more impressive than it is.
Maybe better implementations of existing algorithms, but they have to tread carefully about new algorithms.
I assume today they use H264 and the re-encode would just be newer implementation of H264 encode/different settings than they used before.
They could get more from jumping to HEVC, but netflix is on crap tons of smart TVs and such.
Of course that's not to say they transcode to HEVC and client advertises whether it's H264 or HEVC and netflix just keeps both H264 and HEVC live on their CDN, if capacity is no big deal.
It's obvious it saves bandwidth, and if Netflix were having someone manually babysit instances of a transcoder that would be ridiculous. Every transcoder is automation friendly and assuming they've done it all right it's a matter of kicking off a massive parallel job to chew on the library using their idle capacity. It's a common thing to do when you have low priority workload and gobs of servers. Now if they are having people hand review the result of the transcode for video quality issues that would be expensive, but I doubt they would. They would cherry pick a few representative scenes of content and verify their batch job looks good and fire away. Then they would rely upon user issue reports to catch anything they may have missed.
Actually I doubt they'd reduce the color precision from 24 bit (it's not 32 bit).
In fact, content with lots of synthetic content can sometimes be smaller by being 30 bit instead of 24 bit (think how often synthetic content puts in gradients, with 24 bit those gradients are more dithered than 30 bit, and the compression algorithms struggle a bit more with what appears to be 'noisy' content from dithering compared to less noisy undithered content).
Of course this is using general purpose algorithms that are used for both animated and photorealistic alike. There may be some gains in theory from a codec focused exclusively on animated content, but in practice no one seems to think it's worth the trouble to pursue.
For me the human testing is largely in scenarios where a human is involved. Sure they will sometimes hit a case that the test cases managed to miss in coverage, but most of the bugs are usability, documentation, etc.
It varies based on what you are trying to deliver. My experience is that without the QA team, the product that releases even if it doesn't do things like crash or hard failures, that users are likely to not be happy with it. I work on software for target users that have skills most software developers do not possess, and conversely most of those target users can't write software well. Same for my previous job. It's one thing when you are writing something pretty universal, it's another when you are trying to target a highly skilled industry that is not software development. A captive audience to bridge the gap and provide context is just needed for good product.
In my work, we draw QA team members from the target industry. They do have the domain knowledge of the target market. I have also been at a place that offered a deal to one or two clients for steep discounts or free in exchange for volunteering some of their people for occasional meetings on in development code.
The problem with just waiting for the end users is that most of the clients I see would just buy a competitor software rather than contribute any work to make the one I work on better. That's the rub when your user input is roughly out of the knidness of their hearts/loyalty. What bug input you do get is low quality (except for things that are pretty black and white crashes with a stack trace, the stuff that gets gathered in an automatic way), and users are likely to just move on.
For example, if Yahoo and Google offered the same rough service, and yahoo was confusing or didn't do what I expect, I wouldn't click a 'file issue here', I'd just go to google.
I wasn't so much about unexpected data input, but a user not knowing what the hell to do to get what they want. Functionality they don't figure out.
Which can be replaced by an easy issue submission process embedded in the program itself.
Yes, just make your users your testers, great idea. Maybe for a community free effort, but for a commercial deliverable, that's *not* where you want things to be.
humans having a hard time using an interface, this is generally obvious to the developers too
Developers are frequently not very much in tune with their target end user perspective. Hence why I see my fellow developers get frustrated with testers and even clients, wondering why the users can't do things the way the developer thinks they should do.
you transition the frustrated programmers who have been stuck in QA
Most traditional QA people I deal with are not programmers, they represent roughly the level of skill of what real end users would be.
you need less (or no) QA people at the end
If you have *no* QA people at the end, you are putting way too much faith in your automated testing. It's true that in practice the 'end' QA goes smoother when you have automated testing in CI, but the tests are not perfect and the real world will involve real humans and you need real human perspective that isn't up to their eyeballs in the implementation. When you build the software, you lose a lot of perspective of how your end user would use it. You more and more strongly assume your end user has all your experience and understands the underpinnings and make quirky design decisions as a result. Having an outside perspective to bring you back to earth is important.
The argument is actually pretty bad. By all means add more automated testing and hopefully make the QA process smoother, but skipping it entirely (they fired the QA team) is a recipe for disaster, and the only thing they have to measure the effectiveness of this is the number of issues in their issue tracker, which was *fed* by the QA team. It's like a company firing all their warranty people and bragging about how their warranty claims have gone to zero. The filed issues may be lower, but that does not speak to the final product.
This is a double edged sword in my experience. The testers are using the software much like a human would, and they do unexpected human things like the end user would be doing. This particularly helps identify usability issues, which isn't really an automation sort of thing. It's also a lot of fuzzy stuff that is usually not specifically laid out in the spec.
robustness towards matching the spec
Sometimes single minded march toward matching the spec is a bad idea, because the spec is bad and needs to be revisited. Sometimes this plays out in development, and sometimes this plays out in QA when humans clearly have a harder time with the interfaces than expected. Also generally speaking for me a spec is pretty high level, open to interpretation, and refined throughout the process as the details of the implementation get fleshed out.
While 100% was hyperbole, I think the point stands: if you remove QA then the number of *known* issues is going to go down. Whether your number of *actual* issues go down it's another matter.
I view this as the nightmare scenario, management hears words like automated testing as part of CI and then assumes automation has taken care of everything and they don't need the QA people. When the QA people's input into the issue tracker goes away, the numbers of issues in the graphs go down. Management gives themselves a pat on the back as a problematic metric has improved, without too much thought as to why.
Slashdot Mirror
For your own code, the white space code formatting sensitivity and other python 'features' are pretty much more annoyance than value. When you are subjected to it, it's annoying as all get out.
The benefit comes when having to contend with someone *else's* code who has had to put up with it. So basically it's a big self inflicted aggravation for the greater good of collaboration.
To me, the people who go all frothy at the mouth over python produce hard to read code in their language of choice. People who do not use python, but don't go bitchy when they have to deal with it tend to also write pretty readable code in their own language. The intent in python is simply to force the issue by making it hard for the interpreter to follow when it is also hard to follow for a human. This can be added to a project in any language that has central automated repository, but python just enforces it at the lowest level, no matter how lazy the coder/maintainer want to be about it.
There are unfortunately downsides, but there are downsides everywhere. I have encountered confusing code in brace delimited blocks because indentation was screwed up (and while pre-emptively feeding every chunk of random code through an indent program is possible, it's not something that always comes to mind).
FWIW, the same argument about editor would apply to the 'tedium' of braces. Many editors when contending with languages you hit '{' and enter and poof, proper indentation and close brace inserted.
The problem is that we can point and yell 'stupid' at whatever we want, but reality is that whitespace is mangled by a lot of things, so use of a language very sensitive to whitespace as a 'learning' language has some challenges. If I made a language that required vowels in the keywords to have umlauts, I could run around and say it's stupid that a lot of keyboards don't have keys for that built in, or I could admit that I made a choice that ignores that reality.
That said, I've seen a lot of C/Java/etc code just get really really mangled because it still compiles and people get slack about whitespace because it doesn't matter. Then if you go in and indent it, some maintainers will get mad because they don't want 'ownership' of a line to change in annotation just because someone changed indentation. So there's some upside to being a pain in the ass about indentation to force the issue. Of course the same could be done with a style check in continuous integration, but that's extra work that a lot of folks would skip.
Even if the font is fixed with, the width of a 'tab' is not universal. If your text editor says tabs are rendered as 4 spaces, and you mix in some spaces (may not be your fault, might have been someone else in the codebase, though continuous integration on python projects generally set up to reject tabs).
It's not necesarrily a terrible idea, for for a project that's commonly interpreted as 'easier', the whitespace based grouping causes a lot of headaches. To say the headaches are worth the result and you'll get used to it is one thing, but to pretend it doesn't cause headaches is silly.
Defend your trademark you mean. Aspirin was a trademark, but the drug would have been able to be produced genirically either way by now (as acetylsalicylic acid).
Meanwhile, Xerox is not a genericized trademark, though some think it is. Escalator, cellophane, kerosene, and others are generic trademarks.
Though the sentiment is correct, failure to protect trademark risks forfeit of the protection. Patents do not have that feature, a company is free to submarine a patent all day long (though waiting until it's very popular to start using it increases the likelihood that an army of people will find *something* to invalidate the patent, there's very little that's truly novel, at least not things that are independently invented over the timespan of a patent lifetime).
Note there are drm free ebooks too.
I personally don't like dealing with books when I can get it electronically (I prefer an e-ink device, which is even lighter than a book, and looks as good as a book), but some people just prefer a book..
Given the distinction described, programmers being just implementation and 'developers' actually understanding the needs and wider context, programmers really should be on the decline, and there shouldn't be room for a 'software developer' to need 'programmers' as time goes on.
Already the divide has been largely responsible for some of the most infuriating software I've had to use. The people actually creating it have no clue about the wider context. Meanwhile you have 'architects' that don't know the first thing about how the code works or can work or most critically how it wouldn't work. Somehow enterprise industry has latched onto the model of 'architect' versus 'implementer' and never shall the two cross and it makes for some terrible software.
Sometimes it makes a mountain out of a molehill (don't need a massive team to maintain what amounts to be a simple script, and often giving it a massive team makes it senselessly more complex) and sometimes it does address some issues of tedium associated with a genuinely complex project. For the first part, people should not confuse 'importance' with 'complexity'. People presume that something very important warrants a large team, which is often wrong. For the latter, the large team may be warranted, but no coders should be exempt from understanding the context for their work. I've seen that last bit happen all the time, to the point of bad coding decisions resulting in the programmer resenting the paying customer for what ultimately is the programmer's lack of understanding the use case rather than the customer 'not being smart enough to deal'.
For never ever putting an 'appliance' directly on the internet. Particularly when it comes to closed source. It's attractive to think you can get something ready to roll specific to your needs, but it also means putting a huge maintenance burden on the provider of that appliance, with a huge potential set of code that could be compromised, and a higher latency for getting fixes (some appliances need to wait for their image provider, who waits for a well-known distribution to publish, who might wait for upstream to have a fix, on their best days).
At least with software that pulls in only the parts that are truly unique to the use case, then a vendor only is responsible for their own mess, which is a bit easier.
Too bad the trend is appliance-ification for *production*, using a docker pull or download a canned VM, instead of managing an image directly. These are slick and cool ways to evaluate and stand up something quick in a 'trusted' isolated environment (though one should always be vigilant regardless of 'internal' or not, the risk/benefit is different). When you go to an internet facing service, more care should be exhibited.
I agree (and my work system is woefully not up to date and I have no privilege to fix it, and tear my hair out over a number of known bugs that have been fixed, but my company has not seen fit to push updates for them). However the link would be helpful if some person who is in charge of managing deployment of updates is aware there is a fix to be had. So the story is valid to show (it's not like it's a non-story because update is available), but it should have indication of fix for those empowered to do so.
processor speed has improved since it was first designed
Note that even as it is today, I have observed such flash heavy sites that a web browser can bring a pretty modern system to its knees. If you are implying that even slower flash would be acceptable because systems are faster, that would be a bad call. The issue is that for the most part, the role flash served can now be served with HTML, Javascript, and CSS, which do have open implementations. Rather than re-implementing the flash runtime, making every effort to port web content away from flash would go further toward sanity.
To the extent flash needs to be a thing for sake of preservation (btw, same theoretically applies to Java applets, which don't work in most modern browsers), it should be some guarded thing limited to browsers, not some ubiquitous thing that can spring up in embedded html like email clients and help systems.
The issue is that as they are being run, that's the only likely scenario to occur at all:
"didn’t know how to trust that drivers would make room in the ceaseless flow, so the human minder had to take control to complete the maneuver."
"We don’t want to get into an accident because that would be front-page news."
The state of affairs is that the autonomous cars give up when faced with a situation they aren't 100% positive they wouldn't cause an accident in the attempt. They only go up to 25 or 35 mph depending on the operator. I recall one incident when it got hit making a left turn and it was the cars fault, but the autonomous system had disengaged, giving it a pass. The question should have been why did it require a human operator to perform the left turn. If all you do is go in straight lines, make turns when things are overwhelmingly safe to do so, only ever go under 35 mph, and the instant any required maneuver could be a risk, surrender to human driver then it's easy to have such a pristine record.
They also aren't 100% blameless in getting rear ended:
"coming to an abrupt halt, for example, when they sense a pedestrian near the edge of a sidewalk"
A human hanging out near a curb will cause it to abruptly hit the breaks when a human driver currently would see that pedestrian and better judge their intent. Of course in theory everyone should be giving everyone else a long following distance, but abrupt stops to avoid what a human discerns as a non-existent threat is not good for safety or traffic flow.
There's a middle ground to be had. Sure there are a lot of ubiquitous bending of rules that should be addressed (amending or enforcing). Speeding is among those. There are an essentially infinite set of 'exceptional' circumstances that are relatively rare in occurrence, but critical when they occur. Having laws to cover that would require an infinite set of laws. One could say you could get close enough with more and more complex laws, but at some point the law becomes outright impossible to understand, well before the laws cover all the circumstances.
all of the robot crashes have been minor fender benders
Note that, for example, Google's cars are never going faster than 25 mph. So it's a little disingenuous to say they only get into fender benders when a human in the same situation would likely not have anything more than a minor fender bender either, even if they were very bad at driving.
For sales tax applied 'fairly' across the board, it drives up the prices for those who can barely scrape by as it is. Income tax has a way to provide relief to those with low household incomes. If you start trying to target 'conspicuous consumption' type things with a premium tax, you get back into a game of crazy loopholes to sidestep elevated taxes.
There are tons of problems with US tax code, but a focus on income versus consumption is not a deficient thing.
But if you have a pure red, green, or blue, then you have a very limited range for that color. This is why for photo realistic, it's no big deal, in nature you don't really see concentrations of just a primary color, and not usually in a gradient . It's when an artist sits down to create the content and chooses much more simplistic colors and patterns, which interestingly enough causes a unique problem for the medium when only 256 levels are available to represent any particular primary.
Now dithering up to fuzz away the bands in a gradient is pretty much imperceptible, but the compressor sees a more 'noisy' source than if the band width is reduced by a factor of 4. Of course ideally a compression algorithm simplifies the model the same way at a certain compression level, but at best it's considering the dithering to be detail that can be discarded if necessary rather than that specific pattern of detail not mattering one bit.
git pull and then du -sh.
The biggest project should be pretty objectively obvious.
They suggest that they are going to have an automated process to transcode content a few ways and use some automated quality check to decide what meets the threshold. Or they are trying to make changing from CBR to VBR sound more impressive than it is.
Maybe better implementations of existing algorithms, but they have to tread carefully about new algorithms.
I assume today they use H264 and the re-encode would just be newer implementation of H264 encode/different settings than they used before.
They could get more from jumping to HEVC, but netflix is on crap tons of smart TVs and such.
Of course that's not to say they transcode to HEVC and client advertises whether it's H264 or HEVC and netflix just keeps both H264 and HEVC live on their CDN, if capacity is no big deal.
It's obvious it saves bandwidth, and if Netflix were having someone manually babysit instances of a transcoder that would be ridiculous. Every transcoder is automation friendly and assuming they've done it all right it's a matter of kicking off a massive parallel job to chew on the library using their idle capacity. It's a common thing to do when you have low priority workload and gobs of servers. Now if they are having people hand review the result of the transcode for video quality issues that would be expensive, but I doubt they would. They would cherry pick a few representative scenes of content and verify their batch job looks good and fire away. Then they would rely upon user issue reports to catch anything they may have missed.
Actually I doubt they'd reduce the color precision from 24 bit (it's not 32 bit).
In fact, content with lots of synthetic content can sometimes be smaller by being 30 bit instead of 24 bit (think how often synthetic content puts in gradients, with 24 bit those gradients are more dithered than 30 bit, and the compression algorithms struggle a bit more with what appears to be 'noisy' content from dithering compared to less noisy undithered content).
Of course this is using general purpose algorithms that are used for both animated and photorealistic alike. There may be some gains in theory from a codec focused exclusively on animated content, but in practice no one seems to think it's worth the trouble to pursue.
For me the human testing is largely in scenarios where a human is involved. Sure they will sometimes hit a case that the test cases managed to miss in coverage, but most of the bugs are usability, documentation, etc.
It varies based on what you are trying to deliver. My experience is that without the QA team, the product that releases even if it doesn't do things like crash or hard failures, that users are likely to not be happy with it. I work on software for target users that have skills most software developers do not possess, and conversely most of those target users can't write software well. Same for my previous job. It's one thing when you are writing something pretty universal, it's another when you are trying to target a highly skilled industry that is not software development. A captive audience to bridge the gap and provide context is just needed for good product.
In my work, we draw QA team members from the target industry. They do have the domain knowledge of the target market. I have also been at a place that offered a deal to one or two clients for steep discounts or free in exchange for volunteering some of their people for occasional meetings on in development code.
The problem with just waiting for the end users is that most of the clients I see would just buy a competitor software rather than contribute any work to make the one I work on better. That's the rub when your user input is roughly out of the knidness of their hearts/loyalty. What bug input you do get is low quality (except for things that are pretty black and white crashes with a stack trace, the stuff that gets gathered in an automatic way), and users are likely to just move on.
For example, if Yahoo and Google offered the same rough service, and yahoo was confusing or didn't do what I expect, I wouldn't click a 'file issue here', I'd just go to google.
I wasn't so much about unexpected data input, but a user not knowing what the hell to do to get what they want. Functionality they don't figure out.
Which can be replaced by an easy issue submission process embedded in the program itself.
Yes, just make your users your testers, great idea. Maybe for a community free effort, but for a commercial deliverable, that's *not* where you want things to be.
humans having a hard time using an interface, this is generally obvious to the developers too
Developers are frequently not very much in tune with their target end user perspective. Hence why I see my fellow developers get frustrated with testers and even clients, wondering why the users can't do things the way the developer thinks they should do.
you transition the frustrated programmers who have been stuck in QA
Most traditional QA people I deal with are not programmers, they represent roughly the level of skill of what real end users would be.
you need less (or no) QA people at the end
If you have *no* QA people at the end, you are putting way too much faith in your automated testing. It's true that in practice the 'end' QA goes smoother when you have automated testing in CI, but the tests are not perfect and the real world will involve real humans and you need real human perspective that isn't up to their eyeballs in the implementation. When you build the software, you lose a lot of perspective of how your end user would use it. You more and more strongly assume your end user has all your experience and understands the underpinnings and make quirky design decisions as a result. Having an outside perspective to bring you back to earth is important.
The argument is actually pretty bad. By all means add more automated testing and hopefully make the QA process smoother, but skipping it entirely (they fired the QA team) is a recipe for disaster, and the only thing they have to measure the effectiveness of this is the number of issues in their issue tracker, which was *fed* by the QA team. It's like a company firing all their warranty people and bragging about how their warranty claims have gone to zero. The filed issues may be lower, but that does not speak to the final product.
Testers don't always follow proper testing procedure
This is a double edged sword in my experience. The testers are using the software much like a human would, and they do unexpected human things like the end user would be doing. This particularly helps identify usability issues, which isn't really an automation sort of thing. It's also a lot of fuzzy stuff that is usually not specifically laid out in the spec.
robustness towards matching the spec
Sometimes single minded march toward matching the spec is a bad idea, because the spec is bad and needs to be revisited. Sometimes this plays out in development, and sometimes this plays out in QA when humans clearly have a harder time with the interfaces than expected. Also generally speaking for me a spec is pretty high level, open to interpretation, and refined throughout the process as the details of the implementation get fleshed out.
While 100% was hyperbole, I think the point stands: if you remove QA then the number of *known* issues is going to go down. Whether your number of *actual* issues go down it's another matter.
I view this as the nightmare scenario, management hears words like automated testing as part of CI and then assumes automation has taken care of everything and they don't need the QA people. When the QA people's input into the issue tracker goes away, the numbers of issues in the graphs go down. Management gives themselves a pat on the back as a problematic metric has improved, without too much thought as to why.