Dianne:
I think this gives a somewhat misleading impressions of what happened.
From a software perspective, Sooner and Dream were basically the same -- different form-factors, one without a touch screen -- but they were not so different as this article indicates and the switch between them was not such a huge upheaval.
The main reason for the differences in schedule was hardware: Sooner was a variation of an existing device that HTC was shipping, while Dream was a completely new device with a lot of things that had never been shipped before, at least by HTC (new Qualcomm chipset, sensors, touch screen, the hinge design, etc). So Sooner was the safe/fast device, and Dream was the risky/long-term device.
However the other factor in this was the software. Work on the Android we know today (which is what is running in that Sooner) basically started around late 2005 / early 2006. I got to Google at the beginning of 2006, and it was around that time we started work on everything from the resource system through the view hierarchy, to the window manager and activity manager that you know today. Some work on stuff we have today (like SurfaceFlinger) was started a bit earlier, but also after Google acquired Android.
Even if there was no iPhone, there is a good chance that Sooner would have been dropped, since while it was a good idea to get Android out quickly from a hardware perspective, the software schedule was much longer. I don't recall the exact dates, but I believe the decision to drop Sooner was well before the iPhone announcement... though we continued to use it for quite a while internally for development, since it was the only semi-stable hardware platform we had. If nothing else, it helped remove significant risk from the schedule since software development could be done on a relatively stable device while the systems team brought up the new hardware in parallel.
So what you see running on that Sooner is the same Android that would run on Dream. This is one of the reasons we have the -notouch resource qualifier, for the UI select a touch-based or non-touch interface depending on the device. Also at that point most of the widgets you see in the UI (lists and such) are the ListView and GalleryView we have today, and would already be able to react to touch input if they received it. And the software on there was using our layout managers to resize the UI elements to match the screen size.
However that build may not have things in it like actually running apps in multiple processes. That was one of the lagging implementations in Android, which was increasingly making the hardware schedule for Sooner not match the software schedule for Android. I think almost everyone on the team was relieved when Sooner was dropped, just because it gave some relieve on the core software schedule.
Imagine if Sooner had gone out at a reasonable time before Dream, say a year before. This was when we released the preview SDK. We had a mad dash to get the SDK somewhat cleaned up for that, but did lots of iterations on it in the following months. We had barely gotten multiple processes working (it was so close you still see remnants of our single process environment in the SDK with Application.onTerminate).
During the time from when the SDK came out to when the G1 shipped, we spent many many months working on stabilizing, optimizing, and productizing the platform. This was a platform that had never been shipped before, with a lot of pretty unusual designs -- up until near the end, you had to wonder "is this actually going to work?"
We also had a long lead time required in stabilizing the platform before shipping the device. Partly because of uncertainty of how everything would work together, partly because the team hadn't shipped a device before and didn't know the tricks we do now for tuning the release schedule. At the time we shipped the device, we even felt like we had to assume that what we shipped on the ROM was it, and we would never be able to deliver an update to it!
So be careful when you look at screen shots. People who aren't programmers, understandably, see a UI and take that to be all there is to know. We should know however that what is behind the part you can see is actually a lot more complicated, stuff you could never realize just from what you see with your eyes. People throwing up pictures of a UI they have played with and coming to conclusion that explain what is going on behind the scenes may get some things wrong.