Simple: (Almost) every mistake a programmer makes is visible somewhere, but there's actually very little consequence to it. Put another way, bugs happen all the time, people notice but it doesn't matter.

Off by one, program crashes...user restarts it. Miss a "delete" somewhere, program runs out of memory (eventually), user restarts it. Some tiny bug corrupts user data, company fixes it, issues apology, life goes on. With a few (notable) exceptions, when a programmer makes a mistake, life goes on. Very few of them have any real consequences, but they are visible. Someone can't enter in their company name because it contains a digit. Another can't enter their own real name because it contains an accented character.. Tab order is messed up. This field is misaligned with that one. So what?

Arguably, these are visible, but mistakes in other fields may be nearly as common, and with little consequence, but aren't VISIBLE. Construction worker puts 1 nail into a 2x4 instead of 2. Nobody cares. Another neglects to tie the rebar together in a few places. Nobody notices or cares. The bridge is slightly out of level or square due to some miscalculation and...cars can still drive on it just fine. Errors happen in every job, but most aren't visible.

For the most part, we don't have enough redundancy in software resulting in mistakes being a LOT more visible. But there's still little consequence - users will work around it it, companies fix (and sometimes even apologize) and nobody up nor down the chain loses their job or even gets reprimanded.

If bugs were less visible, they'd still happen but fewer people would know.

If there was more consequences to any given bug, then we'd have a lot better practices in place to make sure they didn't happen (and software would be even more expensive than it already is).

Once upon a time I was part of a company acquired by a parent company. Sometime thereafter, parent company's product started displaying an error message and then exiting on all of their customers' computers at the same time. Apparently the (hard-coded) license key for some 3rd party component had expired and as a result hundreds if not thousands of people couldn't do their jobs. The affected product Team Leader's fix was to get a new license key, replace it in the source, compile and then get everyone on that new version as soon as possible. The problem was that good ol' parent company didn't have great source control procedures nor a build server prior to acquiring some real developers (us) so there was a huge variety of versions of the product across all of their customers, some of which were known to contain custom one-off features and changes that potentially never made it into source control in the first place... Also the product couldn't be upgraded without also upgrading some or all of the server pieces too. It was a big mess with potentially days of downtime to clean it up and their customers were losing money by the minute and rightfully PISSED.

My solution was to create a little utility that looked for copies of the product in the usual places and replace the expired license key (stored in UTF-16 in the .exe) with the new one. Since the keys were the same length, it worked perfectly and the support team was able to deploy that to all of their customers in the matter of hours.

Mod parent up. These other replies talking about marking packets and the whole stream of routers needing to respect them don't seem to have a clue about your standard home Internet connection.

Here's the deal, in a nutshell: Your cable modem or DSL line is the bottleneck. Your LAN is very fast and so is the rest if the Internet, if you can get your packet past your modem. It is your cable modem or DSL modem that is actually dropping packets when you saturate your upload bandwidth. It doesn't matter whether or not they have buffers or not (many cable modems have BIG upload buffers, causing all kinds of latency problems) the fact is, your DSL modem or cable modem DOES NOT RESPECT QoS priority flags on packets when it starts dropping. Sorry, they just don't.

So you need to do what the parent said and artifically limit your bandwidth in your router, so every packet your router sends to your cable modem or DSL modem WILL go out, because it hasn't hit its own limit. Then, with prioritization rules, you can make sure your outgoing VoIP packets will not be dropped - there's no need to reserve upload bandwidth for this.

The same thing works for downloading. You can't directly control what the other side sends you, but you CAN artificially limit your download speed, in your router, to make it the bottleneck. What happens is that your router will start dropping packets before your cable modem or DSL modem's download stream gets saturated. These dropped packets will cause a TCP connection's window to drop and the other end will be forced to resend data and slow down its sending rate. This achieves exactly what you want - the other end to stop saturating your connection (or close to it). In this way you can indirectly control what the other side sends you and which streams get priority.

The download throttling and prioritization obviously doesn't work (well) unless the majority of the traffic coming in is TCP. Otherwise reserving bandwidth for VoIP in this case works too.

You can do a great job of QoS on a typical DD-WRT modem, if you make it the bottleneck, which obviously requires knowing your sustainable upload and download rates on your connection. In my experience most DSL and cable limits are very stable. The exception might be cable connections in neighborhoods where they've oversold the headend and your bandwidth suffers during peek hours (6pm to midnight.)