Slashdot Mirror
A Possible Cause of AT&T's Wireless Clog — Configuration Errors
AT&T customers (iPhone users notably among them) have seen some wireless congestion in recent months; Brough Turner thinks the trouble might be self-inflicted. According to Turner, the poor throughput and connection errors can be chalked up to "configuration errors specifically, congestion collapse induced by misconfigured buffers in their mobile core network." His explanation makes an interesting read.
They keep cost and quality low because that is what their customers actually want, or at least, that is what they are willing to pay for.
[CITATION NEEDED] You'd have an argument if AT&T was the lowest cost provider, but they aren't. MetroPCS is. Also this doesn't make sense from a market perspective either. You have the leading smart device on arguably the worst national network, yet AT&T continues to get subscribers almost exclusively due to iPhone sells. This makes a scarce resource -- AT&T's network -- even more scarce. Supply and Demand tells us that customers would be willing to pay more to access that network, especially given that demand isn't just steady, but steadily growing.
To quote Red from Shawshank Redemption, "I do believe you're talking out your ass."
You might think that you hold it high and mighty over techies, but there does seem to be a lot that you don't understand in my post. For a start.
Sometimes 'good enough' really is the best option for the business as a whole. Techies and engineers often have a hard time accepting this until they've actually run a department, but it's true.
Totally agree.
If we have $10m today, we might benefit more by doing 10 $1m projects 'pretty well' than by doing 7 $1.4m projects 'perfectly', for a number of reasons.
Yes and no. It's not that simple. If doing 10 $1M projects doesn't raise support costs drastically, then yes, it's great. My problem is when you run 10 $1M projects which then cost a half million each to get to an acceptable level. As a business that means $5M less next year to spend, it might mean having to hire more support staff, or it might mean that the development budget is smaller next time round due to a tighter overall number. You are so close to my point actually, it's almost funny. If you did say do the 7 $1.4M projects and didn't have to spend the huge increase in support, yes you would be three projects down on the possible, but you would be $5M up, which at your same estimate of $1.4M is around 3.5 projects. That's a net gain. This is my point and why I often argue with the program office.
It could get something to market faster... it could be that the marketplace cares deeply about some features, but doesn't care quite so much about initial quality, it could be that it's just better to run 10 experiments and see which pan out well enough to put extra money in them later... it could just be that nobody is happy, but there's simply not enough cash to do what's really wanted.... so it's do it 'good enough' now, or not doing it at all.
I mean... there are shitloads of valid business reasons to purposefully do things a bit half-assed. Especially in very competitive markets, where there just isn't enough margin to pay for doing things "perfectly", or in markets that aren't meaningfully differentiated on quality.
I work for a multinational retailer, and the projects I am involved in are mainly system tweaking dealing with improved measurement of stock, forecasts, reporting and analysis of our data. Yes, it's important to be able to get to new opportunities quickly and take advantage of new information, I actually sit within the business side, so I totally understand this, but not if it comes at the cost of other failures of other systems which are unintentional or unexpected. I am surrounded by business users (who are funding these projects for the most part) and while they *understandably* want to have cheap and efficient projects but they don't want to lose functionality of current systems or have projects so poorly implemented that the gains are far below project expectations.
I spend my life fighting with people like you... people who think I don't understand, or I'm shortsighted, or I'm just a robot. But here's the thing: I think *YOU* are the idiot.
The funny thing is that I don't think you are shortsighted. Yes, I don't think you always see the implications of poor implementation, which in some people's eyes will term you short-sighted. However, I look at all the projects that come within our area with a fresh set of eyes. If the project is sound, then great, roll with it, if it's going to be a headache for everyone from the business through to IT support, then no, re-budget and look at it, or keep the business informed of the shortfalls within the project plan manage expectations to the point where the business is well aware that it will be a rough ride. You thinking I am an idiot honestly doesn't help anyone - especially if you are actually trying to be productive for the company you work for. If you are not as technical as people giving advice and explaining things, it's not a bad thing, it's a different set of s
Moved to http://soylentnews.org/. You are invited to join us too!