Bringing first-class development tools into its Office desktop suite, Microsoft is taking a forward step along the path to productivity. Thats a journey whose progress Ive been praising since 1991, when advanced macro capabilities made Word 2.0 for Windows a revolutionary product.
The forthcoming Visual Studio Tools for Office will put even more developer power at the point of end-user action and will let custom applications inherit Office behaviors that users already understand. These are clearly good ideas.
No, thats being too nice. Lets try another opening.
Putting unrestricted automation into the exposed environment of Office, Microsoft is taking yet another downhill step into the pit of an already-complex and insecure end-user computing experience.
Warping standards-based interoperability into a barbed-wire corral of complexity, the forthcoming Visual Studio Tools for Office will place application-level security and enterprise data protection at the mercy of careless department-level developers.
We should know better by now.
No, thats erring in the opposite direction. But if I wrote these columns from either a pro- or an anti-Microsoft agenda, I could simply choose the pro or anti paragraph above. Either position could be readily defended.
Its too bad, then, that both are valid viewpoints, each with solid arguments to support it. Technology adopters will therefore have to recognize both sides of these issues and exploit the good while guarding against the bad.
Both courses must be followed to meet the rising expectations of managers, in-house users, customers and supply chain partners for convenience and operational security—even as IT staff become more thinly spread while our networked collaborations continue to accelerate and expand.
Ill begin with the positive because the potentials of the (formally named) Microsoft Visual Studio 2005 Tools for the Microsoft Office System are huge—and any pitfalls in using them correctly are clearly marked for developers to avoid.
You can look at VSTO 2005, as Microsoft dubs this planned late-summer release, from two perspectives.
It puts the Office suite into the Visual Studio environment, meaning that anything that an Office application can do becomes a developers building block. Conversely, VSTO takes everything that a Windows-trained developer knows how to do and makes it applicable to Office applications.
The result was shown by KD Hallman, general unit manager for VSTO, when she briefed attendees at Microsofts Office System Developer Conference in Redmond earlier this month: "I can drag and drop Windows forms controls; I can then double-click on them; I can write code behind them," Hallman said. "And it is robust. Your applications wont break when you move controls around. Youre writing to the control, not to the [spreadsheet] cell, something very new and powerful. ... Its the new programming model inside of Excel."
This got my attention because Ive been enjoying the power while cursing the limitations of spreadsheet-based application development since the days of Lotus 1-2-3.
Spreadsheet-based models are dreadfully inefficient in terms of consuming memory and processing power, but both of those are getting cheaper all the time—while the developer time thats saved gets ever more valuable.
So I want VSTO to work, and I want to see the benefits of custom applications in the processes in which people create and use workplace documents—instead of being cut-and-pasted from an applications output into a spreadsheet for further analysis or into a Word document or PowerPoint chart for transmittal.
The flip side of integration, though, is the loss of opportunities for a person to look at a result and think about whether it makes sense. The royal road toward smart documents is also a slippery slope toward dumber mistakes and more devastating attacks on our systems.
Im reminded of a line from William Gibsons 1982 short story "Burning Chrome." Launching an attack on a financial database, a cyber-cracker exults, "We just told Chrome were an IRS audit and three Supreme Court subpoenas."
When documents talk to one another, sometimes theyll lie. Its up to developers to make those documents not merely smart but at least a little street-wise as well.
Technology Editor Peter Coffee can be reached at firstname.lastname@example.org.