I tried everything.  I googled the problem till the cows came home — nothing.  I tried updating VMWare tools.  I tried rebuilding the VM.  I tried 64-bit and 32-bit.  I even uninstalled VMWare Server and installed VMWare Player, thinking that the lack of Direct-X support in Server might be causing the WPF-based VS2010 some issues.  No dice.  Nothing worked.

Just about the time I was ready to chuck the whole works out the window, a nagging memory surfaced.  Somewhere in my distant past (ok, it was three or four years ago), I remember having lock-up problems with Visual Studio 2005.  I never did figure out what was causing the lock-ups, but I had a sure-fire workaround:  just delete the .SUO file for the solution and re-launch.

So, having already exhausted all of my “good” ideas, I gave it a try, and just like that, I was back in business.

Wouldn’t you think that at this point, there’d be some way for Visual Studio to detect that something was pretty badly hosed in the .SUO file?  Me too.

Related articles by Zemanta

• Share the same Visual Studio Settings between Team Members (devcurry.com)
• Visual Studio Not Responding (beeping) when editing ASPX (huddledmasses.org)
• FYI: Visual Studio 2010 Technical Readiness Training (huddledmasses.org)
• Microsoft patches Visual Studio error message (infoworld.com)

Tweet This Post

And if you expect your users to need to use your help system, and if you choose to make that help system an internet experience, and if that internet experience is going to use a browser that’s had so many restrictions placed upon it in the name of security that you can’t sneeze without seeing some sort of exception (IE, I’m looking at you….), you should probably consider the likelihood that your users (already frustrated because they can no longer accomplish something that they used to be able to accomplish on their own) are going to encounter a help system that looks something like this:

Thanks a lot, Microsoft.

Tweet This Post

This memory leak, however, was self-inflicted.  The source of the memory leak appears to be rooted in an open-source project the team was using to manage detached POCO’s.  The detached POCO’s, it turns out, weren’t needed by the project when they were built into the architecture, but were built to support a yet-to-be-built offline client.  The project team met the anticipated requirement with a clever project that met a widely-recognized need in Entity Framework 3.5.  For those shops that absolutely needed this functionality, there weren’t too many choices, and this one was right at the top of the list.  The extra functionality, though, added code and complexity, and in this case, a memory leak.

As a final insult, it now looks like this offline client won’t be needing the detached POCO’s, after all, and on top of everything else, the POCO support project is now essentially deprecated in favor of native support for POCO’s in EF 4.0.   The lesson is repeated every day in development shops around the world: someday never comes (you had no idea CCR was singing about software development, did you?).

Everyone who designs software has done this, but if you’re designing software, think about these points to avoid this all-too-common pitfall:

• Beware the temptation to build for future requirements.  I’ll be the first to admit that it’s pretty tempting to put in that hook or extra layer when you just know you’re going to need it, but consider the risk when you do this.  Requirements change all the time after they’re real, and the ones that aren’t real yet are even more tenuous.
• If you’re using  a third-party tool or library, open-source or not, be sure to assess the present and future stability of the software.  On Scott Guthrie’s blog today, he announced a new View engine called “Razor”.  Buried in the article was a little gem of a quote:  “Razor will be one of the view engine options we ship built-into ASP.NET MVC.”  If you don’t have a quote like that for your library, you have to factor in the risk that the software you’re counting on will go away (perhaps with little notice).
• Be especially vigilant about architecture decisions that permeate your software deeply or create extra complexity in your design.  These decisions are critical and difficult to correct later.

When you build for the future and guess right, you might wind up looking like a genius, but be careful, because far more often, “someday” will bite you.

Tweet This Post

Software factories generally consist of some tools to assist software development, but a central theme of these tools is that they generate code for you.  I’ve always felt that automation in software development is a very good thing, but it’s vitally important that you understand what you’re left with when you’re done.  If automation results in code that you never have to touch or see, then you’re probably more productive as a result, but if you’re generating code that you’re going to have to maintain, there’s a very good chance that you’re taking one step forward and two steps back.

Most developers are familiar with “Don’t Repeat Yourself” (DRY).  The objective of DRY, of course, is not just reduction in code (and thus, effort) when developing new software, but a centralization of logic that pays dividends as you maintain software.  Code generation often accomplishes a deceptively attractive initial productivity for new development, but the generated code is typically littered with repetitive code.  This code is “free” when generated, but it’s an anchor around your neck every time you have to maintain the code, or even when you step through it while debugging.  It clutters your project, reduces readability, and inhibits your capacity to maintain, revise, and refactor your software.  There’s a reason why repetitive code is usually right at the top of Code Smells lists.

Given my strong preference for software craftsmanship, it shouldn’t be surprising that I consider software factories that barf out projects and classes that you’re supposed to maintain an absolute blight upon the landscape of software development, but there are any number of other automation tools available to us.  Here are some thoughts on a few of these:

• Designers.  These remain the best example of code generation done right, in my opinion.  Designers, when properly executed, produce wholly-standalone code files that we can largely ignore.  Classes are declared as “partial” so that if you need to modify them, you can do so without touching the generated code.  Some designers will add [DebuggerStepThrough] attributes so you don’t see this code when debugging.  All of these things help the generated code disappear unless we’re specifically looking for something, and that’s a very good thing.
• Snippets.  I remain mixed on these little gems.  When used correctly, they can be a big help, but in practice, they’re almost always a sign that you should be doing things differently.  Whether or not you’re using a snippet to generate code, you don’t want to end up with code that violates DRY, and this means that the opportunities to use snippets effectively are few and far between.
• T4.  The best usage I’ve seen of this generation tool (built into Visual Studio, by the way), is Rob Conery’s SubSonic data access project.  T4 creates code from templates written in an ASP-like syntax, and is great for iterating over a database or other object structure to crank out code in for…each loops.  Like designers, this code is intended to be read-only (you shouldn’t modify the generated code), and it can be marked with [DebuggerStepThrough].
• Reflection.  Yes, it’s a little bit of a stretch to call reflection an automation tool, but creative use of reflection can help you achieve some Ruby on Rails-like productivity by adding behavior dynamically.  Reflection is commonly maligned as a performance-killer, but Rocky Lhotka has been doing great things with reflection in CSLA for years with minimal impact on performance.
• Copy-paste coding.  If you’re not even using a tool to help you with your unnecessary code duplication, you’re definitely doing it wrong.  ‘Nuff said, I think.

In addition to these “automation” tools, there are language features and frameworks available to us today that can serve the same productivity objectives without resulting in tons of repeated code:

• Attributes.  Typically used with reflection to act on classes at run-time, attributes can make your code much more expressive by declaring behavior rather than implementing it over and over.
• MVC.  Since MVC is a framework, it doesn’t really do anything at all to enforce DRY (or any other coding practice), but it encourages a declarative style of Model development that’s very consistent with the ideas I’ve been discussing here, and most MVC examples use a very expressive, compact Model syntax.
• Model-driven development.  Microsoft’s data modeling bits (known at various times as “Oslo”) consist of tools, modeling syntax, and extensions that create a very dynamic metadata-driven application environment.  We’re still looking at the early stages of these tools, but the broad objective is to make object behavior completely declarative and dynamic.  There’s a danger that we could trade unmaintainable code for unmaintainable configuration data, but I think that as this technology matures, it’s going to move us in the right direction.

In addition to the options available to us today, we’ll continue to see innovations in the future.  When you’re reviewing and evaluating these options, though, remember to always add lightness, because less code is better.

Related articles by Zemanta

• Model Driven Development: Code Generation or Model Interpretation? (theenterprisearchitect.eu)
• Why Coding is not enough (basilv.com)
• Using a Software Factory Approach for Customized Modeling (devx.com)

Tweet This Post

It’s entirely my Mother’s fault; she drilled proper grammar into my skull from an early age, and I now cannot help but notice the absolutely atrocious spelling, grammar, and punctuation that permeates our culture.

Have you ever watched a history documentary where they read some crusty, tattered old manuscript that some Civil War soldier left behind?  Not ol’ Honest Abe, or even Grant or Sherman — just some guy who wrote to his folks or his girl.  These everyday soldiers invariably sound like Shakespeare compared to the IM-speaking crackberry addicts we meet today.

But surely, even if the everyday American has given up on proper grammar, our journalists are still upholding these standards.  Surely, they manage to set a positive example for all of us: showing us the error of our ways and offering their own writing as a shining sample of excellence, and surely among all of these highly-trained journalists, the writers for the Wall Street Journal would be right at the top.

Surely, this must be true.  Right?

Sadly, no.  Here’s an excerpt from an article I saw from the WSJ a while back (preserved with spelling, capitalization, etc., exactly as found in the article online):

“A lot of traders are getting carried out of there seats. There are lots of liquidations including hedge funds out of riskier assets,” Michael Franzese, head of Treasury trading at Wunderlich Securities in New York. “No one was expecting this sell off in stocks and the euro and a flight to quality trade is in full effect and it not yields levels it just capital preservation.”

Read it again.  Sorry – yes, I know it hurts.  This time, just try to figure out what it’s supposed to say.  I’ll bet you can’t do it.  It’s like swimming a 100 IM in a pool full of Jello.

People, if you’re going to commit anything to writing, please make a passing attempt to make it readable.  If you supposedly make your living as a writer, don’t ever, ever do anything like this.

Thanks.

Tweet This Post

So what?

About two and a half years ago, I wrote an article about usability where I ran into this exact problem while using a touch-screen phone.

I’m glad someone was listening!

Tweet This Post

Apple has, as you’ve probably heard, indicated that it will allow apps on the iPhone and iPad only if they’re written with Apple-native languages and tools, and it’s widely-believed that this has been done as a form of anti-Flash “nuclear weapon”, as my friend commented.

I’m not convinced that this move is directed only at Flash, though.  Any third-party tool (MonoTouch, for example) will be impacted by this move.   Some people have even speculated that this move is intended to help iPhone multitasking (“BS”, I say — write a damned API).  While all of these things might be factors in this move, I believe that the fundamental driver here is a maniacal need for Steve Jobs to control the entire digital experience for his users; nothing short of this will be enough.

Apple isn’t perceived among consumers to be monopolistic simply because they don’t have a majority market share yet.  The thing that just kills me about Apple right now, though, is that within their customer base, they’re monopolistic to an extent that would have gotten Microsoft run out of town on a rail, even in its heyday.

• All functionality on these devices is approved by Apple.
• When rejecting an app or content, “because we said so” is sufficient reason.
• “We changed our minds” is enough to get an app pulled after approval — including yanking it off any devices upon which it’s installed.
• To get an app on your device, you have to go through iTunes.
• To build an app, you have to use Apple development products (for all intents and purposes).
• To use Apple development products, you have to be running a Mac.

That’s a lot of kool-aide, folks, but if you think that’s bad, it’s going to get worse.

I got a new phone last week.  Although I’ve experienced some teething pains, one of the most pleasant parts of the experience was spinning up my contact list and calendar.  I pointed a new Exchange account at Nuevasync (which connects to my Google account), and sucked down all my contacts and appoinments at 3G speed.  Easily the most painless phone transition I’ve ever experienced.  This is what cloud computing looks like for the consumer.

Apple is building a gigantic data center in North Carolina.  Care to take a guess why?

Data centers this size are being built today for cloud computing, almost exclusively.  Apple is going to suck your entire digital identity into their brand-new data center, and you’ll never see it alive again unless you keep paying your monthly ransom.  As long as you play along, life will be wonderful, in a fuzzy, heavily-sedated way, but if you engage in nonconformist behavior (trying to get your data back, for instance), you should expect to be punished as you’d expect to punish any troublemaker.

Another friend of mine asked me the other day how he could get his DRM-protected music (bought on iTunes) off an old PC and onto his new one.  This is a smart man, by the way – a successful businessman, and he’d tried to figure this out and was stumped.  If you’ve ever tried this, I’m sure you can understand.

Take a good whiff, folks, because that’s the experience we could be signing up for with all of your data.

I’ll pass.  How about you?

Related articles by Zemanta

• Adobe To Apple: “Go Screw Yourself” (cultofmac.com)
• iPhone OS 4 Developer Agreement Further Enforces Flash Ban (appscout.com)
• Silicon Alley Insider: Apple Boots Google Off iPhone 4.0 (AAPL, GOOG) (businessinsider.com)
• Apple v Adobe: this time it’s executable (guardian.co.uk)

Tweet This Post

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).

Sunday, 3/28

• 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.

Monday, 3/29

• 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.

Tuesday, 3/30

• 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.

Wednesday, 3/31

• 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.

(watch below for more updates)

Wednesday, 3/31 (continued)

• 1:27 – 3G / 2 bars.  Tried to update twitter client – “There was a connection error while attempting to download tweets.”
• 1:47 – Edge / 4 bars.  Browser fails; twitter fails.
• 1:57 – no service.
• 2:05 – no service.
• 2:06 – 4 bars, no data service indicated.
• 2:07 – no service.
• 2:10 – Edge / 4 bars.  Changed to no service as soon as I tried to update twitter.
• 2:11 – power off.
• 2:18 – power on.
• 2:23 – no service.  Tried calling voice mail – call failed.
• 2:25 – Edge / 4 bars, then right back to no service.
• 2:28 – 3G / 2 bars.  Twitter update works.
• 2:32 – 3G / 3 bars.
• 2:38 – 3G / 3 bars.
• 2:51 – 3G / 2 bars.
• 3:17 – 3G / 2 bars.
• 4:16 – 3G / 2 bars, but got email error on send-receive.  Browser worked.
• I also found out at about this time that people had tried calling me and hadn’t been able to reach me (and didn’t leave a voice mail).  My phone never rang, and it didn’t show any missed calls.
• I stopped into the T-Mobile store where I bought the phone and shared my experience thus far.  The guy I talked to there was very cordial – he called up customer service and they decided together to try replacing my SIM card.

Thursday, 4/1

• Day 5 with the phone; day two of keeping a service log.
• 8:22 – 3G / 3 bars.
• 9:36 – 3G / 2 bars.  Twitter fails.
• 9:39 – Edge / 4 bars.  Twitter fails.
• 9:41 – No service.
• 10:00 – 3G / 2 bars.
• 10:29 – 3G / 1 bar.  Twitter ok.
• 11:11 – 3G / 1 bar.  Twitter fails; browser ok.
• 1:42 – “G” / 4 bars.  What’s “G”?  Twitter fails; browser ok.
• 4:20 – 3G / 2 bars.  Twitter fails; browser fails.
• 4:25 – “G” / 4 bars.  Browser works; twitter fails.
• 4:27 – No service.
• 4:35 – Got a voice mail notification, but my phone never rang.
• I’m starting to appreciate how much voice service is affected — this isn’t just a data problem.  I saw intermittent data service from time to time on my old phone in this location,  but I rarely had problems with voice service.  It’s becoming clear, though that right now, my brand-new flagship HTC HD2 is performing substantially worse than a three-year-old Wing after I ran the Wing over in my car.

Friday, 4/2

• 10:23 – 3G / 2 bars.  Browser fails; foursquare fails; twitter fails.
• 10:26 – 3G / 1 bar.  Twitter works; foursquare fails.
• 10:27 – 3G / 1 bar.  Browser fails; foursquare fails.
• 10:31 – 3G / 1 bar.  Browser fails.
• 10:33 – 3G / 2 bars.  Call to VM fails.
• 10:34 – 3G / 2 bars.  Browser fails.
• 10:35 – 3G / 2 bars.  Call to VM fails.
• 10:43 – 3G / 2 bars.  Call to VM fails.
• 10:48 – 3G / 4 bars.  Call to VM works; browser fails.
• 10:49 – No service.
• Somewhere around 2:30 – received VM notification.  Phone never rang, and no missed calls are shown.
• 2:51 – 3G / 1 bar.  Call to VM fails.
• 2:55 – 3G / 2 bars.  Call to VM works.
• 3:38 – 3G / 3 bars.  Call to VM fails.  Browser fails.
• 4:22 – Tried changing 3G settings to HSDPA only.  Phone off.
• 4:32 – Restart – now running HSDPA only.  Call to VM – “Phone operation failed”.
• 4:49 – No service.  VM failed.  Tried to call my number w/ Google voice – failed.
• 4:51 – Back to default 3G setting (HSDPA / HSUPA).
• 4:54 – VM fails.
• 4:55 – 3G / 2 bars.  Google voice call works.

Saturday, 4/3

• Stopped into a T-Mobile store near my house.  The assistant manager there told me I needed to go back to the store where I bought the phone for help.
• Back to the store where I bought the phone.  Talked to the same guy I’d spoken with on Wednesday night.  He’s going to try swapping this phone out with a new one as soon as they get a shipment in.  I expect to hear from him on Tuesday.

Monday, 4/5

• 9:16 – Incoming call test (Google voice) works.
• 9:27 – VM fails.
• 9:32 – Today, I have my backup phone with me.  This is a $20 Nokia prepaid candybar phone I picked up at Wal-Mart while my Wing was out of service.  I swapped my sim into this phone and fired it up.  I see 5 bars and I can call VM.
• 9:43 – VM works on the Nokia.
• 11:17 – Chat w/ T-Mobile customer care rep to bring them up to speed.  The rep said they were issuing a ticket to have engineering look at the problem.  They should have an update in “24 to 72 hours.”

Tuesday, 4/6

• 9:50 – VM fails.
• 10:14 – VM fails.
• 10:16 – VM fails.
• 10:17 – Power down, sim moved to $20 Wal-Mart phone.
• 10:18 – Nokia shows 4 bars, call to VM works, Google voice can call the Nokia phone just fine.  There’s a T-Mobile signal here, for sure.
• 1:52 – Sim back in HD2.  Showing no signal.  VM fails.
• 1:55 – Sim in Nokia.  Five bars.  VM works.  Considering strapping the Nokia onto the back of the HD2 with a couple of rubber bands.  Give me the HD2 with the radio on the Nokia, and I’d be a happy man.
• 4:30 – Called back in to T-Mobile customer support to check on the status of the ticket I opened yesterday.  There was no engineering update yet, but the customer service rep got a technician on the line to see if he could help.  He asked if I could use WiFi to call (no), and if I’d tried manual network selection (I hadn’t yet).  I’ll play with manual settings a bit tomorrow to see if I can see any difference.
• During the customer service call, one of the people I talked to tried to tell me that T-Mobile wasn’t aware of any problems like this with the HD2.  I’ve started adding links at the end of this article to forum posts where other people have indicated problems.
• I did not hear from the guy at the T-Mobile store who told me he’d be calling me today.

Wednesday, 4/7

• 9:05 – Incoming call test works (via Google Voice).
• Checked manual network selection – only one available network listed – “T-Mobile”, so I left the selection on “manual”.
• 10:43 – Google Voice fails to reach my phone.
• 10:44 – VM works; Google Voice fails.
• 10:45 – Tried selecting  ”Terminate Data Connection” on shutdown screen.
• 10:46 – Google Voice fails; VM fails.
• 10:48 – Sim card in Nokia.  Immediate VM notification from previous Google Voice connection, and VM works just fine.  Showing four bars.
• Still no call from local T-Mobile store.

Thursday, 4/8

• 8:55 – Incoming call test works (via Google Voice).
• 9:06 – No service.
• 9:07 – Manual network selection shows three networks:  ”T-Mobile”, “T-Mobile”, and “AT&T”.  Chose the first “T-Mobile” network.  No service shown.
• 9:08 – Manual network selection again.  This time, searching takes a long time (over a minute) and comes up with same list.  I chose the second “T-Mobile” entry.  Signal shows four bars / no data service indicated.
• 9:12 – Tried calling VM – phone popped up the network selection screen showing No Service.  Repeated “Find Network”.  Signal shows Edge / 4 bars while searching.  Searching takes around a minute again.  Chose “AT&T”, but got Network error: “Cannot register on selected network.”
• 9:15 – Find network again.  Chose first T-Mobile network.
• 9:16 – 3G / 4 bars.
• 9:17 – Before I could even test the great signal (!) above, phone shows no service again.  VM fails and pops up the network selection screen.
• 9:18 – 3G / 2 bars.  VM fails.
• 9:19 – Back to “automatic” network selection – manual isn’t doing anything to help me.
• 9:20 – 3G / 2 bars.  VM fails.  Power down – sim is going into the Nokia.
• 9:22 – Nokia shows 4 bars.  VM works just fine right off the bat.
• 10:20 – Per thread on T-Mobile forum, I tried changing my TcpWindowSize.  In the registry, HKLM/Comm/Tcpip/Parms/TcpWindowSize was set to 65536 (stock).  I changed this to 98304 and cycled power.
• 10:26 – First test call to VM was successful.
• 10:28 – VM call – “Phone operation failed.”   In the last three minutes, I saw the phone go to “No service”, then to Edge w/ 4 bars, then back to No service, then to 3G w/ 2 bars.  A call to voice mail when the phone showed 3G / 2 bars failed immediately.
• 10:32 – Back to default setting for TcpWindowSize.  Phone powering off, and sim back in Nokia.
• 11:14 – The guy on the forum who suggested changing the TcpWindowSize thought I didn’t wait long enough for the phone to “go through its cycles”, so I’m trying one more time.  TcpWindowSize changed back to 98304 and the phone is powering up.
• 11:15 – Phone is up.  No service shown.
• 11:16 – Phone shows Edge / 4 bars.  Before I could try a call, it’s back to no service.
• 11:17 – No service.
• 11:18 – No service.  Are we still “going through cycles?”
• 11:19 – No service.  Tried a call to VM anyway.  Call connected, and the phone immediately showed 4 bars, no data connection.  WTF??
• 11:20 – Edge / 4 bars.  Tried Google Voice call – it connected.
• 11:21 – No service.  Call to VM fails.
• 11:22 – Edge / 4 bars, then no service a second later.  Google Voice call fails.  VM fails.
• 11:24 – No service.  VM fails.
• 11:25 – No service, then 4 bars / no data service.  VM indication received from failed Google Voice call.
• 11:26 – VM works.
• 11:27 – Five bars / no data service.
• 11:28 – No service.  VM fails.
• 11:29 – One bar / no data service, then 3G / 1 bar.
• 11:30 – 3G / 1 bar.  VM fails.  TcpWindowSize reset, power down, sim back in Nokia.

Monday, 4/19

• Obviously, I haven’t updated for a while, but things have been pretty much working the same as I’ve observed to this point.  I received two glimpses of hope today, though:  I got an email from HTC indicating that they’re looking into the problem (I originally contacted them back on April 9).  I also heard from the store where I bought my phone — they’ve finally gotten new stock in, and I’m cleared to go and exchange my handset to see if new hardware helps.  Maybe there’s hope, yet.

So, who else is seeing problems?  As indicated earlier, T-Mobile seems not to be aware that this is a widespread issue with the HD2, so I’m going to try to do my part here to collect observations from other people.  These are links to other places where I’ve seen people complain about similar problems:

• http://forums.t-mobile.com/t5/HTC-HD2/network-reception-PROBLEMS-with-HD2/td-p/349024
• http://forum.xda-developers.com/showthread.php?t=659863
• http://forum.xda-developers.com/showthread.php?t=614119
• http://forums.t-mobile.com/t5/HTC-HD2/Dude-at-a-Sprint-store-said/td-p/349869
• http://forums.t-mobile.com/t5/HTC-HD2/Anyone-in-the-Minneapolis-St-Paul-area-Please-Read/td-p/347469
• http://forums.t-mobile.com/t5/HTC-HD2/3G-Is-Not-What-I-Thought-It-Was/td-p/348462
• http://forums.t-mobile.com/t5/HTC-HD2/Connection-signal-problems/td-p/347659 (mine).
• http://forums.t-mobile.com/t5/HTC-HD2/The-Returning-My-HD2-and-Getting-Something-Else-Thread/td-p/345765

[update - 5/20/2010]

It’s been a while since I’ve updated my status here, so I thought I’d add a few notes about how things are playing out.  I swapped handsets back on April 20.  This had very little effect on performance, though I saw a slight placebo effect for a couple days, I think.  Interestingly, I’d seen a couple of forum posts from people who talked about two hardware versions of the phone, where the earliest phones had red reset buttons, and later ones had yellow.  I can confirm that the first phone I had did, indeed have a red reset button, and the replacement phone (my current phone) has a yellow button.  Beyond the color of the button, I can discern no difference in the phones whatsoever, but that doesn’t mean there aren’t internal differences that I can’t see.

Over the course of several weeks, I’ve seen marginal improvements that appear unrelated to anything I’m doing on the phone, so I attribute these to network tuning on T-Mobile’s part.

The other big event has been HTC’s (followed by T-Mobile’s) release of a new firmware ROM (and radio ROM) for this phone.  I’m now running the 2.13 ROM with 2.10 radio ROM, and I’m seeing slightly better performance again.  At this point, I believe that voice connectivity is back close to the level of my old T-Mobile Wing, which is the minimum bar I wanted to see.  Data connectivity is still a little hit-and-miss, but it’s better than when I got the phone, and in a lot of locations, it’s quite good.  I still maintain that when the phone and network are working right, this is a really nice device.

I’ve decided to look into writing an application to log cell tower connections in a way that will let me see if I’m switching towers when I’m sitting still.  I believe this is the cause of the “signal hunting” I’ve seen, and I’d like to be able to provide some good information to HTC.  I’ve received a couple more contacts from HTC about this.  They’ve really been pretty good about following up on things, considering the fact that T-Mobile is really supposed to be taking the lead on customer care.  In any event, I think that if I can generate some reliable data for them, HTC will put it to good use.

Tweet This Post

“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[.]“

Ok, yeah – the quote is really from “Life, the Universe, and Everything“, and he wasn’t talking about bugs, but he could have been.

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.

Related articles by Zemanta

• Dealing with bugs in Linux (ghacks.net)
• Software Bugs A Software Architect Point Of View (slideshare.net)
• Over Half of Software Fails First Security Tests (tech.slashdot.org)

Tweet This Post

Tweet This Post