I got a e-mail from my dad tonight. He was trying to run this year's version of "Macintax" (TurboTax for the Mac, which started out under that name, and by which he continues to call it), but it wasn't working.
After two phone calls, we had traced through the issue. He had installed things fine. But when he double clicked the application icon to launch the program, it would momentarily launch, showing it's icon bouncing in the dock, but then suddenly quit.
We decided to call it quits for the night, but after getting off the phone I did a quick Google search: turbotax mac won't launch. The fourth search result sounded promising and lead me to this forum where a user was complaining of the same issue.
A link in that forum brought me to a page on the TurboTax website explaining that "Our decision to eliminate support for earlier Mac OS versions was debated extensively, but in the end we believed our decision was the right one—not necessary for today, but rather for the long term sustainability of the TurboTax for Mac products."
A call back to my dad confirmed he is running MacOS 10.3.9. TurboTax requires 10.4
There are three huge failures here.
First of all, if you are going to stop supporting older OS versions, the least you can do is have your software check what version of the OS it's running on, so that when my dad launches it under OS 10.3.9, he at least gets a meaningful error message saying it doesn't work under OS 10.3 instead of the program just quitting.
Second, 10.3 was released in October of 2003. It's hardly unreasonable to expect that Mac users could still be running a 4 year old operating system. In fact, the PowerBook G3 where my dad was trying to run the program, will turn 9 this year. What's amazing is that he's using an operating system as recent as late 2003.
Mac users simply don't upgrade as often as their PC counterparts.
Of course, that doesn't stop Intuit from supporting crazy old PC's. They support the Windows version of TurboTax on ... Windows 2000, which was released 8 years and 4 days ago today.
That's right - on the Windows side, they support 8 years back. On the Mac, 4.
And, finally, the third failure is that the technical claim for why they don't support OS 10.3 is "our new development tools for next generations of TurboTax are written in a version of Java supported only on OS 10.4 and up." It's true that Mac OS 10.3 only supports through Java version 1.4. Here's the failure part though -- you can use RetroWeaver, a free open source project, to get around this. (It lets you write code in more recent versions of Java and then transform the compiled code to run on Java 1.4.) If Intuit had really "debated extensively" and had Java developers worth their salt, they should have been able to figure this out.
Update: In light of Bob Meighan's comments, I'm doing an update and doing it here rather than in the comments section.
First, I have to say I'm rather shocked that my rant caught the attention of a Turbo Tax vice president. I'm used to companies ignoring their customers. It speaks well of Bob Meighan that he took the time to respond. Also, the intended audience of my rant wasn't TurboTax itself; had it been I would have attempted to be a bit more diplomatic.
I'm glad Bob Meighan recognizes that "flagging users with an intelligent error message if they try to install on an unsupported OS" is a refinement they should make. Of the "failures", I think this is the largest. I also wonder if there are users running OS 10.4 but who never upgraded to Java 5 that are experiencing the same error as my dad and also getting no feedback about what the problem is.
If you distribute an application that has external dependencies, like a specific version of the Java runtime, your program really should check that its dependencies are met during the install process or when it's first run. I still hold the view that it's concerning this was overlooked in the current Mac version of TurboTax.
As to the rationale of dropping support for OS 10.3 altogether... I certainly think it's no small feat that your development team undertook. I sort of question why you rewrote your entire application (see Joel Spolsky's Things You Should Never Do, Part I) but turning around a tax software package must be tough work. You have very fixed deadlines and a near guarantee that, because tax code changes continue until the end of the year, your requirements are always subject to change until the last minute. So, that you released anything at all is some sort of achievement. But... that you released something doesn't help my dad. He needs something he can use on his laptop running OS 10.3. Your product doesn't do that, so it doesn't meet his needs, and thus, from the limited place I stand, it's a failure.
I understand you had to make tough choices. You didn't have an unlimited staff, supporting more platforms requires more resources, etc. But you made a calculation that, to be able to deliver a product within your various constraints, you were going to cut off support to people like my dad. I can't say that wasn't the right choice for your company, I can just say it was an awful choice from my dad's perspective. For various reasons, you chose to alienate some of your customers with this release because of its more limited OS support. That's life; I get it; But I really hope the folks at Turbo Tax aren't too surprised that some of those alienated are now complaining.
A few other notes:
1. A friend challenged me on my claim "Mac users simply don't upgrade as often as their PC counterparts." That's one of those pieces of conventional wisdom that I just ran with. I can't really say if this is totally accurate or not. When I first wrote my rant I tried to find some statistics to verify this and couldn't. What I can say is that Wikipedia cites Steve Jobs as saying that in June 11, 2007, of "22 million OS X users, more than 67 % were using Tiger (10.4)". So, six months ago, there were about 7 million Mac OS X users not running 10.4. Let's say only one in 500 OS X users buys TurboTax. That's still 14,000 users, and if you assume the profit on a TurboTax purchase is around $35 (I can't imagine the variable costs per unit are much if anything...), that's close to a half million in revenue. Seems to me that could easily justify hiring two additional $80k/yr full time developers to provide OS 10.3 support. (They'd have like 200+% ROI, not too shabby.)
2. I think my 4 year / 8 year, OS 10.3 v. Windows 2000 comparison is actually more generous than it should be. Put more accurately, TurboTax requires Windows 2000 on the PC side, an 8 year old OS, and OS 10.4 on the Mac side, and OS that's not even 3 years old. Windows 2000 is roughly 280% older than OS 10.4. That's a striking disparity.
3. This is just a fun technical musing: I'm kind of mystified by the notion that, if I'm interpreting Bob Meighan's comments correctly ("I can honestly say that the current “engine” for TurboTax for Mac is truly light years ahead of where it has been" and "In fact, the TurboTax for Mac version is probably much more sophisticated than our Windows version"), the TurboTax engine for the Mac is totally different than that for Windows.
And I suppose the engines must be different since I don't believe the Windows version has any Java dependencies (but does have .NET dependencies).
Why, in 2008, aren't you using a fundamentally shared code base across platforms? At least for the "engine" of the program? Write it in Java which will work "out of the box" on OS X and then either bundle a JRE with your Windows install or add a thin .NET layer which invokes your Java code via IKVM. Or, and I think this would make a lot of sense given the quick pace at which you have to turn things around, use a scripting language like ECMAScript, which you can invoke from the Java platform or from the .NET platform. Or write it in Python, also invokable from Java and from .NET or have it run directly on OS X/Windows since Macs come with Python installed and you could bundle the Windows version with your Windows installer.
You could then also use the same engine for the web version. You end up with a whole lot less code to write, maintain, and test. You'd still need independent and platform-specific UI code, etc., but that should hopefully be a fairly small amount of code overall. Anyway, it's not 1995 ... welcome to the age of "write once, run anywhere."
1 comment:
Kahzoohlist... I appreciate your comments on "MacInTax" and your dad's loyalty to the product (just using this name tells me he goes back some years).
While it's possible for us to do a lot of stuff to make our software work on virtually any Mac OS, the fact is that we have limited time in which to develop our applications. As noted in my post that you quote, I mentioned that we rewrote the ENTIRE "MacInTax" application over the summer to ensure we were not left with an application for which development tools were no longer available. The fact that the team accomplished what they did was an amazing engineering feat. (Instead of highlighting the "three huge failures", I would be pointing out the huge successes of this and the fact that Intuit remains committed to Mac customers.) But in the process, the engineering team had to make trade-offs in the interest of getting the product out the door. The decision not to use RetroWeaver was considered, but lack of time forced us to move forward (the time to engineer this was not the hurdle, it was all the backward compatibility testing required after that). As an engineer, you probably know that it's the testing afterward that takes more time than the engineering itself.
The significant news here is that we demonstrated our commitment to the Mac community by investing in the next generation of TurboTax products for that platform. It was and will continue to be a significant investment, especially in light of the fact that Mac represents about 4-5% of our units. We have some refinements we need to make (yes, like flagging users with an intelligent error message if they try to install on an unsupported OS) and we will make them going forward.
Thanks for sharing your views and allowing me to respond.
Bob Meighan
VP, TurboTax
Post a Comment