Can excessive downloading mess up the router?

[POSTED TO alt.internet.wireless - REPLY ON USENET PLEASE]

That's a pretty standard configuration. More likely it's others trying to push it harder.

Reply to
John Navas
Loading thread data ...

I'm not sure they don't know what users do with them, I think they are trying to ensure they don't hurt their Cisco biz. I know the products are not comparable, but look how many use MS Access (or try) instead of SQL Server or Oracle. Linksys/Cisco face a similar 'problem' and their solution is to make sure that you can't 'make do'. For heavy loads, use Cisco...

fundamentalism, fundamentally wrong.

Reply to
Rico

We Americans love our evil corporate conspiracy theories, but I know from a lifetime of personal experience that such theories are almost always wrong. The real reasons are almost always the ones Jeff and I suggested, resulting from pressure to get products out the door in an environment of costs slashed to the bone: haste, sloppiness, carelessness, etc. I've beta tested many products, and know from experience that the great majority of products are shipped with *known* defects.

Reply to
John Navas

John Navas hath wroth:

Yeah, but conspiracy theories are so much fun. I like writing them. Every once in a while I get lucky and they turn out to be true. That's a scarey thought.

It's worse than that. There's no incentive to fix them. What happens is that by the time the defect is discovered and identified, the next two or three generations of products are already in the design->production cycle. Why bother fixing the current problems when the next generation will simply eliminate the problem? Worse, you can't just stop production or shipping from an automated production line. The setup and downtime is horribly expensive.

There's also only one area where field upgrades and fixes can be easily applied. Software and firmware are easily field installable by the customer[1]. Hardware and component fixes are impossible in the field. The result is that the vendors emphasize the all important hardware aspects of a product and delay testing of the software because it can always be fixed later (by the customer). I have yet to purchase a wireless device where the drivers in the box were the latest.

As for testing, that's now the customers job, not engineering or QA. If the phone doesn't ring, it must be working. I once was involved in a product design where 3000 items were shipped before anyone bothered to call complaining that the demo software didn't run. If nobody complains, there is no problem.

[1] The Mars probes were launched with almost none of the operating software installed. The updates and fixes were uploaded while en-route to Mars.
Reply to
Jeff Liebermann
[POSTED TO alt.internet.wireless - REPLY ON USENET PLEASE]

The best list of known bugs is a null set.

I've managed many professional software development organizations, large and small, and I know that it is quite possible to release software with no known significant defects, and that it is also possible to greatly minimize unknown defects with proper methodology. I sincerely mean no offense, but claims to the contrary are really just excuses for poor quality.

It basically comes down to a determination to produce products without defects, as opposed to the "good enough" mentality practiced by all too many companies. The common "wisdom" is that quality is tested into the product at the end of the process with a cycle of bug fixing, but that just doesn't work. Quality must be fundamental to the process from the very beginning. (My experience in teaching and practicing quality management is that your description is clear evidence of a lack of proper quality procedures.)

To repeat: You can't test quality into a product! If there is a substantial number of bugs at the beginning of final test, then the process has failed, and real quality will not be achieved. Game over.

Quality won't be an issue if the product is designed right in the first place. The actual implementation should be a small fraction of the total development process, on the order of 20% or less. Coding should not even start until there is not only a detailed spec, but also complete user documentation. When this is done, there is almost no risk of a change that affects advertising and schedules. In fact, just the opposite -- a proper process produces on-time quality products that conform to published specs.

A basic problem is that companies aren't getting money from old victims (er, customers), so they tend to be focused only on sales to new victims/customers. As a result, the "good" intentions to fix known problems after shipment often go unfulfilled (even ignoring the fact that bug fixes never even make it out to most customers). It's a kind of Ponzi scheme, and sooner or later it breaks down. When it does, even the mighty (e.g., Borland, Ashton Tate, Wordperfect, etc.) can and do fall.

Philip Crosby wrote the book "Quality Is Free" (ISBN 0451625854) many years ago. The title is as true today as it was then: "Quality Is Still Free : Making Quality Certain in Uncertain Times" (ISBN: 0070145326) . "Quality Without Tears : The Art of Hassle-Free Management" (ISBN: 0070145113) .

Recommended readings in software quality management include:

"A Guide to the CMM: Understanding the Capability Maturity Model for Software" by Kenneth M. Dymond (ISBN 0964600803)

"The Capability Maturity Model: Guidelines for Improving the Software Process" (SEI Series in Software Engineering) by Mark C. Paulk, Charles V. Weber, Bill Curtis, Marc C. Paulk (ISBN 0201546647)

"CMM Implementation Guide: Choreographing Software Process Improvement" by Kim Caputo (ISBN 0201379384)

"Software Process Improvement: Practical Guidelines for Business Success" (SEI Series in Software Engineering) by Sami Zahran (ISBN 020117782X)

"Successful Software Process Improvement" by Robert B. Grady (ISBN

0136266231)

"SPICE: The Theory and Practice of Software Process Improvement and Capability Determination" by Khaled El Emam, Jean-Normand Drouin, Walcelio Melo (ISBN 0818677988)

"Comparing ISO 9000, Malcolm Baldridge, and the SEI CMM for Software: A Reference and Selection Guide" by Michael O. Tingey (ISBN: 0133762602)

"An ISO 9000 Approach to Building Quality Software" by Osten Oskarsson, Robert L. Glass, Oskarsson Glass (ISBN 0132289253)

"ISO 9000-3: A Tool for Software Product and Process Improvement" by Raymond Kehoe, Alka Jarvis, A. Shah-Jarvis, Ray Kehoe (ISBN 0387945687)

"Software Quality Management and Iso 9001: How to Make Them Work for You" by Michael G. Jenner (ISBN 0471118885)

"Practical Guide to Software Quality Management" (Artech House Computer Science Library) by John W. Horch (ISBN 0890068658)

"Customer Oriented Software Quality Assurance" by Frank P. Ginac (ISBN

0135714648)

"The Handbook of Software Quality Assurance" by G. Gordon Schulmeyer, James I. McManus, G. Gordo Schulmeyer (ISBN 0130104701)

"Inroads to Software Quality: 'How To' Guide and Toolkit" by Alka Jarvis, Vern Crandall, Alka Shah-Jarvis, Shah Jarvis (ISBN 0132384035)

Reply to
John Navas
[POSTED TO alt.internet.wireless - REPLY ON USENET PLEASE]

That's totally different (as I know from having actually worked on one of the early Mars missions): There's no external customer base, and the mission evolves as more is learned of the unknown. It's actually very sound to have a robust design that allows the mission to be dynamically changed on the fly.

Reply to
John Navas

Especially when you need to launch *years* before the kit will be used.

Consider Cassini-Huyghens - when it was designed, the Pentium was the top chip, clocking in at a scary 100 Mhz and running Windows 95 or if you were corporate, WinNT 3.51, maybe the new OS WinNT 4.0. Whoot. Mark McIntyre

Reply to
Mark McIntyre

No conspiracy here, Cisco management doing their fiduciary responciblity to the share holders. Don't let the low end stuff eat the high end stuff's business. I would expect no less of them. While I don't directly own any Cisco, I would be most upset as a stockholder to learn this was not true.

fundamentalism, fundamentally wrong.

Reply to
Rico

Is restricted bandwidth and number of connections a defect? Again we are talking 'low end' stuff here.

fundamentalism, fundamentally wrong.

Reply to
Rico

I'd be willing to bet serious money that isn't true. As proof I point to the fact that products are no worse now, actually better than before Cisco acquired Linksys.

That would be very shortsighted. Way better to eat your own business than to have someone else do it.

No offense, but this is the kind of simplistic thinking that keeps most people from understanding how business really works.

Reply to
John Navas

Actually I think you are being simplistic, the reason you buyout Linksys is to be positioned in the consumer market, easily the fastest growing segment. While they have improved quality, I don't see where they have increased fleixbilty with the product line. Example you are still limited to the 192.168.x.x range for your local LAN, 10.x.x.x is not supportd. 50 connections limitation. Again for the home/small business user who needs more? But the high end is left alone. I don't see Northern Telecom entering the consumer business, so who is going to eat the business for the high end stuff? Now what is indeed short sighted of them IMO was dropping the WRT54GL. They had created quite a little boom for themselves and won all sort of atta boyz with the nerd crowd who often do influence purchasing decissions either now or in the future (that new minted CS grad will eventual be in management etc).

fundamentalism, fundamentally wrong.

Reply to
Rico

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.