I’ve been soldiering on for a couple of years on a T-MobileWing. That old phone did some pretty great things for my personal organization, but I always seemed to struggle with connection issues.
Last weekend, I finally bit the bullet and picked up a new HTC HD2. Make no mistake, this is a spectacular piece of hardware, but sadly, I still find myself chasing connection issues. I’ll share some thoughts on the rest of the phone later if I end up keeping it, but right now, I want to detail my signal strength problems. I’ll continue to update this post as the fun and games ensues, so if I (or T-Mobile) manage to fix the problem, this post will show the resolution, and if not, you’ll be able to see why I left. All of the observations here, unless otherwise indicated, occured in exactly the same spot in Columbus, Ohio, near the OSU campus (ie, not while moving around).
Bought the phone, took it home, charged it, and powered on. No data connection. It turns out that the upgrade to 3G takes a while to provision.
Signal bounces around all day. Full-strength Edge, then nothing, then 3G, then nothing, then no connection at all. This goes on most of the day, with almost all day spent on Edge only (no 3G).
In the evening, I got a good 3G signal, and the phone worked great.
Slightly better luck with 3G, but not by much.
I talked to a couple people who said they tried to call me several times — the phone never rang, and didn’t show any missed calls.
Noticed the same problems. Signal really bouncing in the morning.
Called T-Mobile customer care at around 11:45. Rep advised me to power off and back on a couple minutes later, and asked if I could call from another line (I can’t).
Immediately upon powering up, here’s what I saw:
11:57 – 3G w/ 2 bars.
11:58 – Edge w/ 3 bars.
12:00 – no service (I was trying to dial voice mail).
12:00 – Edge w/ 4 bars (after I stopped trying to dial VM).
12:01 – no service (as soon as I dialed VM).
12:20 – 3G w/ 3 bars.
12:20 – Call to VM fails.
12:22 – 3G w/ 2 bars.
12:22 – Call to VM fails.
12:24 – Call to VM fails. “Phone operation failed” message. Immediately saw Edge w/ 4 bars, then no signal.
12:26 – Finally completed a call to VM.
12:27 – no service.
12:28 – no service – unable to place call.
12:30 – placed call – it worked!
12:39 – Edge w/ 4 bars. As a side-effect of the connection-hunting, my battery is down to 57% – I noticed this sort of decreased battery life when my Wing was connection-hunting, too. Done troubleshooting for now – my lunch is over.
Douglas Adams, muse to software developers everywhere, had this to say about bugs:
“Just as a slow series of clicks when speeded up will lose the definition of each individual click and gradually take on the quality of a sustained and rising tone, so a series of individual impressions here took on the quality of a sustained emotion[.]”
If you look at bugs one at a time, you can miss some important “big picture” stuff. It’s possible to spot product design issues, usability issues, architecture issues, and more by looking at patterns across multiple bugs. Instead of just taking the bug at face value, consider whether there are other factors that caused this bug (and others like it) to show up. Unless you’re writing mission support modules for NASA, it doesn’t make sense to do a full five-why’s breakdown on each bug, but keep your eyes open for signs like this:
You find yourself going back to the same area of code over and over.
User complaints cluster around a few screens (or functions) in your application.
You recognize a similar pattern in source code that keeps popping up.
When you see patterns like this, you can certainly keep on fixing the bugs one at a time, but it’s pretty hard to make progress this way. Instead, consider a larger bug fix, or even an actual feature (there’s really no difference, IMO) that cuts across individual bugs and fixes the foundational problem that’s spawning them.
Maybe you need to redesign a screen. If users are having a hard time figuring out part of your application, you’re not going to be able to fix your users. Bite the bullet and figure out what you need to change in your application so that it makes sense.
Refactor ugly code. This should be a no-brainer. Spaghetti code can hide a multitude of sins, and the bugs are just going to keep coming until you deal with the problem.
Address architectural issues. Sometimes, your problems run really deep, and big changes are needed to fix them. This can be a tough sell, but if you can show a pattern of costly bug fixes over time, all of which share an architectural root cause, you’ve got the ammunition to push for a fix that will make them go away.
If you eliminate the sources of these clustered bugs, you not only get rid of the current bugs, you wipe out a whole swarm of future bugs before they’ve had a chance to show their ugly little faces. Don’t believe for a second that you can do this one bug at a time.