A while back someone asked which phones the Windows Mobile team uses. While I will end up answering that question, in typical form, I’m going to be really verbose about it.
In Windows Mobile, we’re very strong proponents of what we call, “Eating our own dogfood.” What this means is that we use the code we’re developing on our primary phones. If you’ve ever been on a “Beta test,” you know that beta code isn’t always very stable or bug free. Well, we frequently use builds that aren’t even up to beta quality. When internal people complain about this, my response tends to be, “They don’t call it dogfood because it tastes good.” We dogfood (it’s a verb too 🙂 to find bugs. Better it be unstable for us than for you….
Many developers do a lot of their work on the same emulators you use in the SDK. Emulators are nice because we own all the code for them and can easily make them do whatever we want. The downside, of course, is that you can’t put an emulator in your pocket and carry it around. Microsoft doesn’t make phone hardware, so to do actual dogfooding we need to work with our partners to get a device to use.
We don’t make the chicken or the egg
One of the huge challenges we face in Windows Mobile is finding acceptable devices to use for Dogfood. Because the device we need to use hasn’t been created yet, we almost always develop the next release on a device created for the previous one. This causes serious problems (that lead to clever solutions) when the previous hardware doesn’t have features we’re trying to develop. For example, it was hard to add QWERTY keyboard support because no device had a QWERTY keyboard. And no one was going to make a QWERTY device until we added QWERTY support.
Another issue is that a huge amount of the code in a WM phone isn’t written by us. It’s written by the OEM who manufactures the phone. Frequently, to develop a new version of our software we need to modify the OEM parts of the code. The trouble is, the OEMs generally don’t want to give us their code. They’re worried that we might give it to their competitors.
For these reasons, our choice of development platforms is limited not only by finding devices that will do what we need, but also by finding OEM partners willing to either let us use their code or make changes for us when we ask for them. The “make changes for us” idea is a pain for the OEM, because they don’t sell phones based on that work. Any time they spent making something work for us is time they didn’t spend making a phone they’re actually going to sell.
These things contribute to the “dogfood not tasting good” situation. Frequently our internal development builds are done on inappropriate hardware with driver modifications that were made by an overworked team with higher priority things to do. As cool as this place is, it’s not always glamorous.
Dogfood through time
We’ve actually been doing this for ten years now, but I’ll just go back to the PocketPC 2000 release. One of the main development platforms for that was the Compaq Aero 2100. In these fun times, the only way to update a device was to physically remove the ROM chips and replace them with new ones.
When PocketPC 2000 came out, the most popular device created for it was the Compaq iPaq 3600. The iPaq was a natural choice for our development/dogfood platform, but maybe not for the reasons you’d think. First, we already had a relationship with the OEM (both the iPaq and the Aero were made by HTC). That helped us convince them to give us access to its driver code. Second, it ran on an ARM processor. This was before we had standardized on ARM, but that was the direction we were heading. Third, but maybe most importantly, it had Flash memory that let us install new builds without physically replacing ROM chips.
While working on that, we also had a group doing the first Smartphone (for the Smartphone 2002 release). There we had a huge chicken and egg problem. There was no previous device that was anything at all like what we were trying to build. Our division actually has a small hardware team that designed and built a few prototypes for us to use. The first was called “Avenger” and the second was “Avenger 2.” We don’t have the manufacturing capability to make a lot of these, so we worked with an OEM to make a version of Avenger 2 for us. While this was supposed to be called “AV2,” a language mishap turned the name into “AR11.” We also did a ton of work with a small phone company, but that didn’t end well. I’ve got plenty of stories to tell there, but … won’t.
We had a similar chicken and egg problem with the next PocketPC release (2003). It needed to be a phone but there were no previous phone PocketPCs. Thankfully, we were able to work with HTC (who had made the best Smartphone 2002 device) on what would become the XDA (aka the Wallaby). For development of non-phone PocketPCs, we continued to use the iPaq.
For Smartphone 2003 we continued to use the AR11. We also used the HTC SPV (aka the Canary) for a while but switched to the Motorola MPX200. There were a number of reasons for using the MPX200, but one of the biggies was that the OEM who made it was willing to give us code for the drivers. Our work on the AR11 had made HTC worried about giving us the SPV driver code.
Our next release was WM 2003 Second Edition. One of the features in this release was QWERTY support in PocketPC. To do this, we first paid a company to make a QWERTY sled for the iPaq. We had a grand total of two of those, and I believe they cost us more than most people’s salaries. We also found a company that was planning to make a keyboard attachment for the XDA, paid them to put a different layout on it, and bought a ton of them. These were cheaper because the company was already manufacturing the keyboards.
We needed a way to do 240×240. We did that by taking a 320×240 iPaq and just making its display driver only draw the first 240 pixels. We needed a way to do 640×480. For that we used an XDA (which had a 320×240 screen), made its display driver tell the system it had a 640×480 screen, and then “pixel quartered” the output (average pixels together) to make it fit. It was ugly, but if you squinted, you could almost pretend it was the higher resolution. And it let us test to make sure that text fit on the screen correctly, etc.
The most funky thing we needed to do was 240×320 for Smartphone. We couldn’t use the pixel quarter trick there because the MPX200 was 176×220, which isn’t an even multiple. Instead we made the Smartphone version of our code run on the XDA. To simulate the number pad, we overlaid a number pad on the screen and let you tap it with your fingers.
For Windows Mobile 5, we had a number of devices. On the PocketPC side we had three: the HTC XDA II (aka Himalaya), a prototype HTC CDMA device that didn’t end up shipping, and the Toshiba E750. Although HTC had reluctantly given us source code for the iPaq and the first XDA, they wanted it more restricted this time. So we worked out a deal where only two people in the entire company could see the code for those platforms. These two developers were tasked with all driver development for the release. Thankfully they were both extremely good developers (and one of them is a superhuman who typically gets more done than any two or three normal people). On the Smartphone front we started with the MPX200. Trouble was, it didn’t have enough ROM to hold WM5. After a lot of herculean measures to keep it going, we finally switched to using the HTC SMT 5500 (aka the Typhoon). We never got source code for the 5500, but HTC was using it to practice for their upcoming WM5 device and we were able to ride on those coattails.
Windows Mobile 6 continued to use the 5500 for a while but switched to its replacement, the HTC SDA (Tornado). We also used the HTC MDA (Wizard). At the tail end, we got some HTC Dashes in. In all of these cases, we didn’t have access to any of the source code. An HTC engineer made changes for us.
Not everyone in Windows Mobile works in the main feature team. Some people work on focused items for OEMs so they see and use more devices than the main group does. For instance, we worked really closely with Motorola on the development of the Q. As a result, many people dogfooded Qs. Etc. But, for the majority, the above pretty much tells the tale.