Category: software

I’m convinced that cellular phone companies keep dark basement cubicles full of evil marketing gnomes whose sole job is dreaming up ways to confuse and frustrate customers.

I thought it’d be cool to use my phone for browsing those new fangled web pages designed for mobile, and to be able to check my email. Having no idea how to go about this, I dug into the incredibly twisted world of marketing lingo, misdirection, and bad technological practices of T-Mobile.

Part 1: T-Zones(tm) Means Fun!

First, I went to the T-Mobile website and looked at their Services & Accessories page. Something called T-Zones(tm) is featured in a large box. What is it?

“The place to buy services—on your phone or on the Web. Check out all the fun and useful things available at t-zones.”

Okay. It has an icon that says “Web & Apps,” which sounds promising. Except… in a smaller box separate from T-Zones(tm), there’s also a list of “Other Services” that includes “Internet & E-mail Services.” What’s the difference? Well, obviously, T-Zones(tm) is “fun and useful” (trademarks will do that sometimes) whereas the other service isn’t.

Fine, I’ll bite. What does T-Zones(tm) Web & Apps give me?

E-mail on the go
Keep in touch while you’re out of the house. E-mail service lets you use your phone or other T-Mobile device to access personal e-mail from a variety of common providers so you’re never out of the loop.
[…]
Choose when and where you Web
Just $5.99 per month gives you unlimited access to mobile Web destinations and great capabilities—like reading, editing, and sending e-mail directly from your phone.

Sounds good, aside from the minor fact that web is not a verb. But how is it different from Internet & E-Mail Services? Well, the latter seems to be only for BlackBerry, Sidekick, and Smartphones. I consider my phone to be pretty snazzy, but I don’t know if it’s a Smartphone. How can I tell?

Luckily, there’s an FAQ on the side that tries to help out with this. Sort of.

Do I need a special phone to get Internet access?
Most phones can display text-only Internet by using T-MobileWeb service. To find a phone with a full Web browser, go to the Phones page and check the T-Mobile Internet check box.

Holy crap, that’s confusing. Checking off the T-Mobile Internet box doesn’t really show me Internet-capable phones, it shows phones with a FULL Web browser. “Most” phones are already capable of text-only Internet. Thanks for making that crystal clear!

Part 2: Wrestling with the phone

It would appear, then, that T-Zones(tm) is the right choice for my Nokia 6086. Which, incidentally, is NOT a Smartphone, after all. I do want “unlimited access to mobile Web destinations.” And if T-Zones(tm) makes it fun and useful, so much the better.

Frankly, the T-Zones(tm) menu item has always scared me. I didn’t know what it did, and it terrified me to think that I might click something by accident and discover a $1000 charge on my next bill. But this time, I clicked it. It brought up a little screen that sort of resembled a web page. I could navigate, just like using a regular web browser on a PC, to a screen that let me turn on T-Zones(tm) service for $5.99/month.

I suddenly understood. The T-Zones(tm) item is a simple mostly-text web browser. That’s all.

Which suits me fine. I can get the basic information I want, and I don’t really need the bells and whistles of a fancier phone with better browsing capabilities. On the other hand, I want to make the most of what the device can do. Googling around, I found that there’s a better browser, Opera Mini, that’s available for this phone. Why not try it out?

I transferred it successfully, but when I ran it, it showed the message: “Application access set to not allowed.”

It reminds me of that old passive voice trick, “War has been declared.” By whom, damnit?! Just who is it exactly who won’t allow this application to run? I want some answers.

Part 3: The mystery of T-Zones(tm) solved

Under the Option menu for the Opera Mini application, there’s an item called “App. access.” It’s what you’d use to grant permission to use the network. That’s a pretty good idea, since you don’t want applications secretly doing undesirable things on your phone. They’re written in Java, using a mobile API that has a strong security model built-in.

But on my phone, “App. access” is greyed out, disabled.

More Googling revealed that so-called unbranded Nokia 6086 phones let you adjust this setting, and Opera Mini works on them. But T-Mobile’s phones have that option deliberately disabled. Other users have reported this same problem with other applications that use the network as well.

So I can’t give Opera Mini permission to use the network, because the phone’s software has been crippled (a sadly un-P.C. word choice that’s stuck). By who? T-Mobile, that’s who.

What does this tell us about T-Zones(tm)? From what I can tell, and I might be wrong, both T-Zones(tm) and the more expensive Total Internet plan give you unlimited web access. The phones make the difference: lower-end consumers are forced to use the stock browser on crippled phones, while the more expensive service and application options are offered to users with high-end phones. This, in spite of the fact that your humble little phone might very well be capable of running applications that access the web. Definitely not very fun or useful.

It’d be like selling 2 models of Ferrari with the exact same engine, but one is capped at 50mph in the systems software. It’s capable of going faster, but it’s limited for no reason other than to encourage you to buy the faster, more expensive one. Which also happens to have a sunroof.

It’s fair to pay for a service, like network usage. It’s fair to pay for a device. But it’s bad business and bad technology to artificially disable goods simply to differentiate a product line. I don’t know how other T-Mobile customers feel, or if most of them even know about this aspect of their business, but to me, it’s downright insulting.

If you haven’t caught Kyle Wilson’s recent piece, “Software is Hard,” I highly recommend it. The essay moves elegantly from book review, to musings on knowing when the code is “done,” to issues of measuring quality, to the ever-present problems of lateness and going over budget, to the potential inadequacy of “engineering” as the metaphor for writing software.

It’s the last topic that’s the most fascinating to me. Kyle points out that new software is written only in response to new problems (otherwise, you’d just use existing software). As such, new code ventures into the unknown, where you can, at best, only guess at the challenges you’ll encounter. We always try our best to assess what we’ll face, but by their very nature, these are imperfect assessments. As Kyle puts it, “The only way to avoid that is to have your design go all the way down to specifying individual lines of code, in which case you aren’t designing at all, you’re just programming.”

Which is not to say, of course, we should simply give up engineering. Without some sort of plan for design and advance assessment, we’d be utterly lost. Businesses couldn’t function and programmers couldn’t make a living. For better or worse, the smooth functioning of our society is founded on the arrogance of making accurate predictions, not just about business and software, but about everything from politics and law, to human behavior and psychology, to weather. Such hubris…

No surprise, then, that even real-world traditional engineering often fails to be predictable. Kyle mentions the Oakland Bay Bridge as a project that’s hugely over time and budget. Just yesterday, Boeing announced its much-anticipated Dreamliner would be six months late.

So maybe software engineering IS the right term after all.

Slashdot reported on an opinion piece by David Sivers entitled, “7 reasons I switched back to PHP after 2 years on Rails.” It’s sparked heated discussion about languages, but if you read the article carefully, it’s not really anti-Ruby or pro-PHP, though David does imply serious shortcomings to Rails. He writes, “at every step, it seemed our needs clashed with Rails’ preferences.”

The problem with the short piece is that he’s not very specific about what these “preferences” are. The main criticisms seem to be that Rails is too complicated, too slow, and doesn’t allow direct SQL. Complexity and performance are often the cost of using a large web framework; these don’t seem like Rails problems, but issues you’d have to deal with when using any big framework (in fact, there’s an apples-and-oranges dimension here: Ruby on Rails is a full web stack and architecture, whereas PHP is a scripting language with built-in access to tons of different libraries. But we’ll put that aside for now.). As for direct SQL, a lot of folks have pointed out that David is just plain mistaken about not being able to do what he wanted.

The real reasons he switched back actually have little to do with PHP per se: read the piece carefully and you’ll see he’s much more comfortable thinking in terms of libraries than frameworks. Also, he needed to integrate tightly with an existing codebase. Those two things are the real reasons why switching back to PHP worked for him. They don’t have anything to do with either the strengths or failures of Ruby on Rails itself.

David doesn’t quite do justice to his main point, which is actually about software development, not language features: don’t expect a much touted language or tool to work magic for you. Of course, this should apply as much to PHP as to Rails! I’m not trying to defend Rails, which I know zilch about. There’s a bigger lesson here: the strengths and weaknesses of languages have less to do with success than the overall environment, the functional and integration requirements, and the coders’ facility with a toolset.