GPRS (Internet access) from my cell phone costs extra. SMS too. Yet both put vastly less traffic on the network than voice does. Why then are they much more expensive than voice, when on the face of things they ought to be cheaper?
Packet data does have its own issues. Voice is loss-tolerant but time-sensitive stream data, which is a fancy way of saying that for voice near enough is good enough provided it's quick. Packet data on the other hand requires lots of handshaking, because you have to make sure all of it is received uncorrupted. So per-byte it is more expensive to carry. But there's much less of it. Voice is bandwidth greedy. Therefore, different charging schemes are required.
A reasonable approach to charging would be to measure the traffic volume (how many bytes sent) and work out how many seconds of voice this represents at 9.6kBit - the speed of the old digital voice network. Data traffic might then be charged as voice. It actually is more expensive than voice due to the overheads of the TCP (transmission control protocol) checking that all the data arrived and if necessary retransmitting some of it, so it would be fair to apply a cost weighting. Say, double. This allows for retransmitting everything once - which isn't going to happen, but this leaves elbow room for other problems.
But no, they use some wacko per-request scheme that reflects neither the provider cost structure nor the load placed on the network.
Load on the network is relevant because charging schemes are often designed to discourage certain usage patterns that cause network problems. Reasonable, but the scheme in use seems designed to punish any use of GPRS. Why would the carrier want to chase off business at large?
Hmm... perhaps network capacity is dismal and this is deliberately concealed by a punitive pricing structure designed to inhibit non-essential use of it. That actually would make sense. High-speed packet data is a great marketing feature, but widespread use would bring the network to its metaphorical knees, and people who can't be bothered understanding the issues and who think "they" should do better (nearly everyone) would start badmouthing it.
This isn't speculation. I saw exactly this happen to countless ISPs between 1995 and 2000. They'd start up with a handful of customers, and performance would be wonderful. Word of mouth being what it is, this would promptly bring in hordes of customers. Lots of customers means lots of load. Performance would drop through the floor. They'd make a mint, but word of mouth being what it is, the reputation of their service would soon be in the toilet. This would abate the load and performance would come back up, but too late. With no way to recover their customer base but discounting, they would quickly go broke or get bought by Telstra, often both and generally in that order.
Tel-cos have the same problem. Updating entire networks is expensive and takes time. You have to buy lots of new equipment, and to do that you must first extort the money from your customer base. If you don't slow down network up-take, by the time you have enough network capacity on-line to support widespread use, your network will have a bad reputation and people will stay away in droves.
This will force you to sell at or near cost to get people to use it again... and you can't jack the price back up. Customers are so fickle, after all you've done for them you'd think they'd drop their pants for you but no, off they run to whoever is cheapest. Anyone would think they just wanted the service as cheap as possible.
So what you do is exactly what we're seeing: you charge the new service at a premium, which not only limits network up-take but (hooray!) makes such traffic as you can support extremely profitable. Unfortunately this state of affairs is so desirable to bean-counters that they see it as their fiscal responsibility to preserve the status quo. If you let the bean-counters run things you get ISDN for twenty years.
The convergence of IT and telecommunications has changed this situation. The pêle-mêle rise of bandwidth combined with the equally hectic collapse of equipment prices makes it cheaper to replace everything than repair it. This means that every now and then a tel-co finds itself with cheaper bandwidth. To increase market share they drop their prices. To compete, other tel-cos are forced to either set up a cartel or upgrade their equipment. Cartels are illegal, if not unheard of. Since you can't afford to replace the whole network you just do the capital cities... sound familiar?
Before anyone thinks I'm justifying the carriers' behaviour, I'd like to point out that what generally happens is the latest wonder-boy CEO does something insupportable so they gather up the proceeds of the last two years and bribe him to go away before it gets too embarrassing. There is then nothing in the coffers for the required network upgrade. This is blamed on corporate inefficiency. They "fix" the situation by sacking all the skilled employees, outsourcing everything they can think of and then charging for services that used to be free (ie funded by general revenues). In the short term this substantially improves corporate cash-flow, so the new CEO gets a big bonus. These characters generally know nothing about the industry with which they're interfering, so they honestly think they've earned the bonus. Which makes you wonder about their understanding of basic economics: if I sell my car it will do wonderful things for my short term cash-flow, but taxis and buses aren't free.
The other thing that usually happens when tel-co cash-flow is looking rosy, is that the government of the day issues shares. Um, excuse me, I thought we already owned Telstra on account of having paid for it in our taxes? Considering that telecommunications is specifically listed as an essential service is it not therefore the exclusive domain of a public service or at the very least a QANGO (quasi autonomous non-government organisation)? Doesn't that make it illegal and immoral to sell it into private hands?
I do not object to QANGO and other public sector organisations running at a loss and having to be propped up through taxes. They are not there to be cheap, they exist to guarantee reliability and availability. Doing so is the basis of their special privileges - like run a cable trench anywhere they please and everyone else can damn well dig elsewhere. But if they aren't going to fulfil this brief then the DoC should bugger off and let me run my own cables and transmit microwaves anywhere it doesn't cook people or jam other transmissions.
If it were up to me I'd nationalise all the tel-cos and consolidate them, and imprison all the people involved with the privatisation of Telstra. Treason would be the charge. Or theft, or possibly both. Not to mention reckless endangerment of 20 million lives - it's an emergency service, remember?
203.206.89.94
My career has been so long and varied that I've done just about anything a typical software developer might do, using a wide variety of tools and technologies. More a software developer than just a coder, here are some of the more significant things I've done over the years.
-
General programming with C#, Java, VB and Delphi
-
Extensive database schema design
-
Extensive database implementation
-
Some database administration
-
Custom GIS tools
-
Reports for both electronic and paper delivery
-
Wizards for guided data entry in very complex systems
-
Context sensitive help
-
Custom implementation of various internet protocols
-
High-concurrency server-based services
-
Design of low-cost warm fail-over for high-traffic systems
-
Setupkits
Database design, implementation and administration
In various projects I have used Microsoft SQL Server in every version since 4.2, and on occasionally Oracle 8i. For single-user applications I have used Paradox, Jet (the engine behind Microsoft Access) and dBase.
What did I do with databases? Everything from online superannuation self-management web interfaces for large corporate clients to accounting systems, inventory systems and - rather more interestingly - GPS based asset tracking systems.
Sometimes I designed them. Most often I implemented them. You can't do implementation without doing a certain amount of administration, although my experience in this regard leans away from production environments toward development environments, which place somewhat different demands on the administrator. You don't have to worry so much about high-availability but you are much more often required to restore earlier versions of a database or even maintain several instances in various stages of change and be able to offer instant guidance to developers as to which databases have which versions of structure and test data.
GIS
The GIS involved overlaying asset movements (and various optional detail layers) on maps of cities, highways, mine-sites and suchlike. Often the maps were bought in but sometimes we had to prepare them from aerial photography with trigonometry and matrix math. Plotting asset movements to play back long journeys required adaptation of skills more normally associated with modern computer games, for example the use of KD trees to cull non-visible playback position samples, not to mention the use of DirectX to exploit modern graphics capability in a relatively platform independent manner.
Arguably the wizards fall into the domain of general programming. However, to allow the code to deduce what next to ask of the user, dynamic validation necessary. This is very much more difficult to implement than programmers expect. You end up building a mini application framework involving a number of the more complex design patterns; that or a big mess. Developers who have done it a couple of times are far more likely to produce a robust, reliable wizard in a reasonable time than those who haven't, and so it rates independent mention.
Context-sensitive help
Context-sensitive help is less exciting than it sounds; basically it's program documentation with a structural and stylistic bias toward quick reference invoked for a context. There is a tutorial or how-to element, a reference element and a requirement for brevity.
Reports
Having gone to so much trouble to collect data into a database, people often want to examine it. Generally they don't want to wade through all of it, and often they want the same summary for a different period. Reporting is the business of defining a domain of data, aggregating it in some defined way and then presenting it in a structured layout.
Various tools exist. I have used Crystal Reports in several versions. I will not use it again; there are equivalent tools that combine better quality from the developer's perspective, higher performance from the user's perspective and lower cost from the business perspective. I can think of no reason in any context to prefer Crystal Reports. I'm trying to be polite here but frankly it's expensive rubbish. The only thing I will use it for is examining old reports to convert them to a more worthy medium.
If Microsoft SQL Server is in use then the SQL Reporting engine is a good choice; it can actually do all the things that Crystal Reports claims to be good for, and it scales well unlike Crystal Server. This sounds like an ad but I'm not selling anything. The Microsoft SQL Reporting engine is free if you already licensed SQL Server.
You can deliver SQL Reports over a web server to a browser or you can embed a widget in a window for print-preview or onscreen use. I've done both. There were a few hiccups as Microsoft remembered that most of the world doesn't use inches or Letter paper but it's a rapidly maturing technology that's a pleasure to use especially considering the alternative.
I've gone on a bit about SQL Reports because you can use it irrespective of the programming language in use for application development. There are certainly other options of acceptable quality, and if SQL Server is not in use they should be seriously considered, since practically anything is better than Crystal Reports.
Custom implementations of internet protocols
There is diminishing need for DIY with protocols but occasionally it is useful especially for direct integration into applications of several protocols in concert. For example, one might use a web based report to provide HTML formatted dynamically generated content that forms the payload for bulk email. I have done this, and in the process implemented a subset of the SMTP protocol as well as implementing a simple HTTP client directly in code.
High concurrency
Multi-threading in applications and services is my normal mode of operations. There is no other way to guarantee an application will always respond immediately to the user, and services bespeak concurrent access. For very high concurrency requirements the overheads of thread management may be too high. In such cases it is better to switch to a non-blocking asynchronous callback model with a pool of shared threads rather than have a private thread for each logical context.
Low-cost warm fail-over
In the ultimate hardware failure scenario so beloved of backup equipment salesmen, the question seldom asked is "Onto what do we restore our wonderful backup?" My answer is "the warm fail-over machine at the alternate location". If you don't have one of these there isn't much point in having an offsite backup. So, set one up. And then answer the never asked question "how do we know for sure that the backup is valid and viable?" by taking the backup to Site B and restoring it onto the failover machine. Physical transfer of the backup media both addresses the question of getting the copy offsite as soon as possible, and solves the problem of large data: never underestimate the bandwidth of a briefcase full of DVDs.
In these latter days of removal high capacity disk arrays there's no reason you couldn't have a warm fail-over update twice a day even for high-traffic like a bank.
Where now?
There are embedded systems under development at work and I think I'l get involved because it isn't something I've done. Also, I'm going to have to get into C++ because although .NET is wonderful after the prerequisites are all in place, until then you can't make any assumptions about the runtime environment, and so any support code for the setupkits I'm building will have to be written in C++ and MFC.
Also there's a little project called Empire.