Doh! This is why we run beta programsPublished 6 February 2013 5:11 pm
I’m a big believer in sharing beta software with users as early as possible.
For our users it means getting to try new functionality months in advance of when they’d otherwise get it. For us it means mountains of hugely valuable feedback, which helps make the software better for users before the final release.
There are two main types of feedback. Firstly, we use our own Automated Error Reporting tool, SmartAssembly, so that if the software actually crashes in the wild, we instantly receive a report with loads of information to help work out what went wrong. We can look at which unhandled exceptions are occurring most frequently, prioritize them, and get them fixed quickly.
The second and most valuable type of feedback is when people tell you what they think. Most people are secretly dying to tell you what they think of your software, and I find that the more brutal they are, the more useful it is! We’ve recently done a lot of new UI work, and getting that into people’s hands early has surfaced some problems we never would have considered ourselves. Granted, there aren’t many feelings worse than a user telling you that something you’ve built sucks, but there are also few feelings better than fixing it and that same person telling you that now they love it.
Recently a lot of developers using our ANTS Performance Profiler beta had been telling us they weren’t seeing any profiling results appear. At first we didn’t understand what could have gone wrong – it worked on every machine we tried it on, and passed every test thrown at it. After going through log files and talking to a lot of those users, the penny finally dropped. The culprit? It turns out we’d introduced a bug into the profiler’s WinRT core*, such that it wouldn’t connect to Windows Store apps in time zones outside UTC, which is most of the world apart from us. This might not have been the most annoyance ever caused by a time zone bug, but nonetheless the sound of heads hitting desks certainly echoed around the room for a while…
A bit embarrassing? Sure. But imagine not discovering this until releasing for real. That wouldn’t have been so fun. As it was, we’ve been able to fix it, ship a new build, and write a bunch of tests which should prevent it from happening again.
If you’re one of the people who this bug affected, I’m really sorry, and hope you’ll give the new build a go (there’s also been a lot of new functionality added recently so it’s now better than it was before!). Either way, take this lesson: release early & often, and talk to your users as much as is humanly possible. It leads to better software, and sometime in the future it might just save you from having a really bad day.
The latest beta build is available here, now with Universal Time Zone Support™
*The gritty details: the profiler’s regular instrumentation core talks to the UI through a Pipe, but because of the Windows Store’s sandboxing, the WinRT instrumentation core is isolated and has to synchronize with the UI based on the time. Unfortunately the core used DateTime.Now while the UI used DateTime.UtcNow, so they were working in different time zones, which meant synchronization didn’t work. To be fair, if for example you live in New York (UTC – 5:00), and had been a bit more patient, the results would have started appearing after 5 hours. But we thought not everyone would be cool with that.