matthew.chaboud.com

March 31, 2010

The ninety-percent user myth…

Filed under: — admin @ 5:06 pm

It occurred to me while reading about Sony’s recent decision to remove Linux support from the PS3 with a firmware update (version 3.21) that the overwhelmingly negative response comes from a few groups of people, only one of which seems well reasoned:

1. People who blame George Hotz for rooting the PS3 via the Other OS feature.
2. People who blame Sony for throwing the baby out with the bathwater (i.e. eliminating an entire feature instead of closing a security hole).
3. People who say “well, 99% of people don’t use that feature, so who cares?
4. Optimists who say “dude, it’s happening on April first!”

I love that the optimists for thinking that a company like Sony would pull such a joke, especially such an unfunny one. My complaint in this case is with the third group, but the first group should also lose speaking privileges for 24 hours while they think about how stupid it is to blame a hacker for the knee-jerk over-reaction of a corporation. The risk of compromise of a system is part of the formula one should consider when designing/implementing/cost-estimating a system.

No doubt some people at Sony made the same sort of majority consideration when deciding to pull this feature, just as they did when deciding to pull SACD support, PS2 backwards compatibility, card readers, or two additional USB ports from the console lineup. What has rightly incensed so many is the removal of a feature from existing hardware. PS3 purchasers who bought into the platform early will find themselves with fewer features on Friday than on Wednesday because Sony appears to be buying into the myth of the single minority.

Sony has given a simple workaround to those who wish to keep Linux support. Just don’t update your system. The trade-off is that, without the update, the user is unable to access the PSN store or play games online. So the user of Linux on their PS3 is forced to choose between using the system for Linux or using the system as a Playstation. This would be akin to Apple releasing an update that broke Boot Camp support but was required to use networking under OS X beyond Thursday. People would be livid, and rightly so.

This kind of user-hostile behavior is quite commonly justified by the single-minority myth, most commonly stated as some variant of:

90% of users don’t use that feature, so we don’t have to worry about it.

I heard this type of statement far too commonly in my five-and-change years as a programmer at Sony, and this sort of thinking is a plague in the tech industry at large. Apart from 90% of statistics being made up on the spot, this sort of thinking considers a decision in isolation and trots out an overwhelming majority to validate the point. It’s pretty easy thinking to fall into:

i. The overwhelming majority of PS3 systems in the field are not running Linux.
ii. The overwhelming majority of PS3 systems with Linux installed are not being used for gaming (if this isn’t true, it just makes this a dumber call, so go with it).
iii. We’ll make very few users unhappy by removing a feature, and the trade off is worth it.

The problem with this thinking is that we’re all part of different minorities. For any feature, the 10% will be a different group of users/buyers. Each user has a set of features critical to their workflow/playflow, and the removal of any one or a small subset of these features might eliminate their demand for the product. Add up all of those minorities and you have yourself a console in last place in the current generation. SACD playback, PS2 compatibility, card slots, USB ports? Those all cost prospective purchasers, but removal of the option to install a second operating system on a PS3 does something far more dramatic.

Even those unaffected by this feature removal have no reasoned view but to be aware of Sony considering such a feature removal acceptable. This will undoubtedly affect future sales, because purchasers trust that the features they buy in a boxed product will be the features that they have down the road. There’s a long tail effect of violating that trust, and it’s much easier to lose the trust of your users than it is to build it.

April 23, 2007

It’s easier from outside the box…

Filed under: — admin @ 11:16 pm

I’ve seen a number of complaints from users of our software and other software along the lines of:
“Vista has been in Beta since last year! Why don’t you have an update for compatibility?!? Don’t you care about your users?!? I’m going to switch to different software because of this!!!”
While it’s true that Vista has been in Beta for quite some time, it has not been a fixed target since then. Between the Beta period and the RTM, I watched as our products worked great, crashed on startup, worked great, crashed on exit, worked great, failed to draw properly, and then, late in the game, had installer issues.
Having been a professional programmer with MSDN builds for Win2k, WinXP, and Windows Vista, I can say that Vista was easily the hardest to prepare for. It was constantly a moving target. Major features like Aero Glass didn’t make it into the available builds until very late in the game. Only then did we discover that things like initialization message order had changed when running under the DWM.
These aren’t the kind of things that 3rd party developers can readily prepare for. Even Microsoft’s own in-house Visual Studio team wasn’t ready for it. When the RTM build was dropped on us, Visual Studio 2005 installs would warn us that the application was not compatible with Vista.
Do we care?
Of course we care. Users are important to most developers. With software as heavily focused on being usable as ours, it seems almost silly for our users to believe that we would want to leave them looking for answers, or, at least, not care enough to fix things. It’s tough to not be able to run the nice new shiny user interface of Vista when Mac users have had illegible semi-transparent menus for years. That frustration gets let out on us, as Windows platform developers, because Microsoft shipped what was, essentially, a beta build.
Users who look for different software to switch to are generally finding that other vendors have run into the very same problems as us. In six months, Vista will be solid, all of our software will work around what Microsoft broke, and the world will await more breaking changes.
It’s worth noting that Apple has also broken the world with updates to OS X. What makes Vista so special is that Microsoft is generally far better about this…

January 18, 2007

Forgive me coders, for I have…

Filed under: — admin @ 12:56 am

C++ is a language that regularly presents things that make me laugh and cringe at the same time. It, more than any modern language I use that starts with “C” and ends with a non alphanumeric character, provides me enough rope to create things that seem useful on the surface but are really ugly when you think about the possible uses. This may not be as bad as the lazybuffer (think std::vector, except any [] access beyond the end of the array leads to the extension of the container to make the ref to that address valid, and also add an optional default value), but it could definitely lead to some ugly, and invisible, code.
This came about towards the end of Bob showing me his trick for writing an operator new that explicitly throws, akin to a new(nothrow), but the other way around.
In our codebase (or, really, any codebase), that trick is likely more useful than the following.
Imagine this code:

int _tmain(int argc, _TCHAR* argv[])
{
   int Out = 0;
   HRESULT hr = S_OK;
   printf("Start running - Int is %d, HRESULT is 0x%.8X\n", Out, hr);
   Out = DoSomethingInt(S_OK, 1);
   printf("return to Int - Int is %d, HRESULT is 0x%.8X\n", Out, hr);
   hr = DoSomethingInt(E_FAIL, 2);
   printf("return to HRESULT - Int is %d, HRESULT is 0x%.8X\n", Out, hr);
   RWrap(hr, Out) = DoSomethingInt(E_INVALIDARG, 3);
   printf("return to Both - Int is %d, HRESULT is 0x%.8X\n", Out, hr);
   _getch();
   return 0;
}

and imagine that the output could be:

Start running - Int is 0, HRESULT is 0x00000000
return to Int - Int is 1, HRESULT is 0x00000000
return to HRESULT - Int is 1, HRESULT is 0x80004005
return to Both - Int is 3, HRESULT is 0x80070057

It can be, without any severe trickery. The point is to be able to handle optional error return values without losing the simplicity of regular return values and, of course, to do so without exceptions. Here’s everything. Just make a console app in the wizard and drop this code in:

// MultiReturn.cpp : Defines the entry point for the console application.
//
#include "stdafx.h"
#include <windows.h>;
#include <conio.h>
template <typename FirstType, typename SecondType>
class MultiReturn
{
   protected:
     FirstType First;
     SecondType Second;
   public:
     MultiReturn(FirstType FirstInit, SecondType SecondInit)
     {
       First = FirstInit;
       Second = SecondInit;
     }
     void Set(FirstType FirstIn, SecondType SecondIn)
     {
       First = FirstIn;
       Second = SecondIn;
     }
     operator SecondType() const
     {
       return Second;
     }
     operator FirstType() const
     {
       return First;
     }
};
template <typename FirstSet, typename SecondSet>
MultiReturn<FirstSet, SecondSet> tReturn(FirstSet FirstIn, SecondSet SecondIn)
{
   return MultiReturn<FirstSet, SecondSet>(FirstIn, SecondIn);
}
template <typename FirstType, typename SecondType>
class MultiRef
{
   protected:
     FirstType *pFirst;
     SecondType *pSecond;
   public:
     MultiRef(FirstType &FirstIn, SecondType &SecondIn)
     {
       pFirst = &FirstIn;
       pSecond = &SecondIn;
     }
     MultiRef& operator=(const MultiReturn<FirstType, SecondType> &rIn)
     {
       *pFirst = (FirstType) rIn;
       *pSecond = (SecondType) rIn;
       return *this;
     }
};
template <typename ErrorType, typename ContainedType>
MultiRef<ErrorType, ContainedType> RWrap(ErrorType &error, ContainedType &contained)
{
   return MultiRef<ErrorType, ContainedType>(error, contained);
}
MultiReturn<HRESULT, int> DoSomethingInt(HRESULT hrIn, int input)
{
   return tReturn(hrIn, input);
}
int _tmain(int argc, _TCHAR* argv[])
{
   int Out = 0;
   HRESULT hr = S_OK;
   printf("Start running - Int is %d, HRESULT is 0x%.8X\n", Out, hr);
   Out = DoSomethingInt(S_OK, 1);
   printf("return to Int - Int is %d, HRESULT is 0x%.8X\n", Out, hr);
   hr = DoSomethingInt(E_FAIL, 2);
   printf("return to HRESULT - Int is %d, HRESULT is 0x%.8X\n", Out, hr);
   RWrap(hr, Out) = DoSomethingInt(E_INVALIDARG, 3);
   printf("return to Both - Int is %d, HRESULT is 0x%.8X\n", Out, hr);
   _getch();
   return 0;
}

November 29, 2006

Making the 2125 work with Vista (part 2)…

Filed under: — admin @ 11:41 pm

Chances are, if you’re an HTC 2125 user, that you use the sync feature of the phone. It’s especially appropriate for this phone, as the T9 entry makes it difficult to lay down data really quickly. If you’re also a Vista user, you may have found the inability to use Activesync somewhat annoying.
Dragging and dropping files is something, but not enough.
If you’re willing to tough it out with Windows Mobile Device Center Beta 3, you may be able to get things working. I ran into the problem of having my phone connect for a while but fail about 250 KB into being connected. My attempts to move the OneNote Mobile cab (about 450KB) over USB resulted in hours of frustration.
I still haven’t had much luck with USB, but I did get everything working over Bluetooth after several more hours of fighting, uninstalling, re-installing, etc.
The answer ended up being relatively simple:
Connect the phone via USB.
The connection lasted long enough to establish a partnership without crashing, after which Bluetooth sync worked with relative ease. It’s not fast (I have an $8 BT1.2/USB1.1 dongle), but it’s functional.
Never underestimate the power of lowered expectations.

Making the 2125 work with Vista.

Filed under: — admin @ 11:29 pm

If you own a Cingular 2125, there’s a chance that you’re interested in having it act as a usb modem with your computer. If you’re a Windows Vista user, this might be difficult, as the usbser.sys file is not available in the usual way. I spent a lot of time hunting for the fix, and eventually came upon this knowledge-base article at Microsoft, describing how this problem should be fixed by driver writers.
It turns out that more than a few people have gone through this headache, and one of the fix-files is here, with the device renamed so you can tell which driver you’re installing in the driver install wizard.
Here you go.
This site, running on a version of MovableType that was cut in stone, just can’t handle comments. If you have further questions or problems, feel free to email me.

April 22, 2004

Vegas 5

Filed under: — admin @ 1:48 am

No new Hellotrans news, but I’ve posted a Vegas 5 difference-masking tutorial here.
Let me know what you think…
P.S. If bandwidth usage goes out of control from the large files in this tutorial, I’ll yank it and note the removal in this post.

October 28, 2003

Correction…

Filed under: — admin @ 3:21 pm

Hellotrans will receive a much larger update than planned, making use of RegisterHotKey(), building with a makefile, and adding custom key support. This will likely be version 2.0 and will have to wait for a few weeks until I can get a free night to work on it.

July 16, 2003

Pending updates

Filed under: — admin @ 8:02 pm

HelloTrans will be receiving some attention in the near future. At the very least, support for customizable keys will be added. Expect changes before the end of August.

Powered by WordPress