Columns

Too much, too soon?

How fast can Microsoft change technologies? More importantly, how fast can developers learn and exploit the new technologies that Microsoft produces? Take building GUIs, for instance. Microsoft Foundation Classes (MFC) and Visual Basic 6 were the Windows standards for this in the pre-.NET era. When the .NET Framework shipped in early 2002, Microsoft told us to start building new app GUIs using Windows Forms instead. Windows Forms is an improvement on these earlier technologies, and it also provides a common approach for any .NET Framework-based language, so the change counts as progress.

Yet Windows Forms also requires developers to learn a new way of performing a familiar task. I'd say roughly half of all Windows developers have switched to .NET, so many have yet to come to grips with Windows Forms and the other changes the Framework brings. This isn't surprising; it takes time for new technologies to be broadly adopted.

What may be more surprising is Microsoft's announcement of a forthcoming replacement for Windows Forms. The Longhorn release of Windows, the next version of the Windows client, will include a technology code-named Avalon. [See "Longhorn roundup" by John K. Waters.] Designed for building better user interfaces, Avalon allows for the creation of local Windows apps that let users navigate through pages like a browser, combine documents and video in a natural way, and more. Avalon looks like an improvement on what we have today. Yet once again, it will require developers to learn a new way to build GUIs.

Avalon was announced in the fall of 2003, a little more than 18 months after the first release of Windows Forms. Just how rapidly does Microsoft think developers can assimilate new technology? I have yet to run across a working developer who thinks the company releases new technologies too slowly.

Thankfully, the GUI picture isn't as bad as it seems. Longhorn won't ship until at least 2006. Even when this new system is available, it will take time for it to become widely deployed. In the most optimistic case, let's assume Longhorn ships in mid-2006 and becomes widely adopted within 18 months. This means applications can reasonably use Avalon if their deployment is scheduled to start in early 2008. Windows Forms, released in early 2002, will have had a six-year run by then, which isn't bad.

The true picture for Windows Forms is even better. Avalon is a Longhorn-specific technology, so the only apps that can use it are those that exclusively target Longhorn. Many desktop apps aren't likely to do this right away, which means that they will still continue to use Windows Forms. (Since Microsoft doesn't want to break existing apps, Longhorn supports Windows Forms alongside Avalon.) This extends the lifetime of the current Windows GUI technology even further.

Microsoft has been accused, with some justice, of not giving its customers enough direction about its future plans. Announcing Longhorn so far in advance of its release should help customers feel more secure with where their investments are going. Still, these early announcements can also suggest a foolishly rapid rate of technology churn. When you work through the dates, though, the truth isn't all that bad.

It's been said before, but it bears repeating: Organizations should adopt new technologies only when it makes business sense. Novelty for its own sake is attractive to some developers; it's fun to use the latest and greatest. Yet steering an intelligent path through the churning rapids of technology change requires calm, reasoned, business-oriented decisions. Deciding when to build GUIs with Avalon is no exception.

About the Author

David Chappell is principal at Chappell & Associates, an education and consulting firm focused on enterprise software technologies. He can be reached via E-mail at [email protected].