|
|
|
| Whither Our Fox? |
Lisa Slater Nicholls
Published in FoxTalk July 1992
[ NB: the product codenamed "Cirrus" was released as "Access". >L< 2001 ]
By the time you read this, the Fox development team will be packing their bags to move to Redmond.
The transition comes a little sooner than expected. Although the Microsoft officially acquires Fox Software on June 25th, at the close of the Microsoft fiscal year, the developers originally planned to move only after the release of the 2.5 FoxPro products. The 2.5 versions of FoxPro were seen as projects proceeding as if the merger had not occurred. This schedule was later amended to allow the developers to move after the first (limited) beta of the first (Windows) 2.5 product.
Why the rush? The quick, almost impulsive shift is characteristic of the enthusiasm with which Fox, from Dr. Fulton down, is greeting the new order. And, from what I've seen at Microsoft, the feeling is mutual. Their support teams are shuffling into place, and they are eager to become involved with the Fox entries in the Microsoft product line.
Other staffers will follow the developers, some almost immediately, but others at a more leisurely pace, to accommodate family needs and an orderly transfer of responsibilities.
I'm writing before the June date, and not all Fox employees have given their final answer to Microsoft's offers. Internally, Microsoft has not made final decisions about their organizational structure and where some of the Fox staffers will fit in. They certainly have not disposed of all the strategy and policy considerations facing the new Database and Programmability Group. Product Support Services, the other arm of the company most directly concerned, is still in the midst of adjusting to accommodate Fox personnel and the Fox support model. Mergers of this size take time, there are enormous numbers of details to be settled. The pace in both companies has been remarkable.
When I visited Redmond in late April, therefore, my purpose was not to gather facts that weren't firm facts yet, or to derive pronouncements about the directions Fox products will "inevitably" take. Many of us have had personal contact with Fox personnel, and we have assumed a certain flow of events when attempting to address a Fox question or resolve a Fox problem. We need to revise our assumptions about that process, and to understand how to conduct such business in the future. We also want to know what is happening in the lives of people of whom we've grown fond.
I'll give you a sense of where those people are going, and introduce you to some new people you will encounter when you are dealing with the Microsoft/Fox team. Of course, along the way I will speculate a bit about what FoxPro-the-product will become; it's impossible not to.
The move
Microsoft typically makes a distinction between end-user product support and developer support. In Fox's case, they have established this distinction as a division between CompuServe FoxForum, which has developed a reputation for sophisticated programming support, and the phone support staff, which disposes of more basic questions.
These areas were both termed "Technical Support" within Fox Software, and Tod Nielsen, Group Product Manager for Fox products in the Database and Programmability Group, acknowledges that the division is not nearly as clear-cut for databases as it would be for Microsoft's other products. Tiers of support just don't work, when an interactive user is capable of maintaining linked tables of astonishing complexity, and an otherwise-sophisticated programmer may be stymied by some feature of the interface.
Nevertheless, the distinction is important, because Microsoft user support is provided by personnel in regional centers, whereas Developer Support is concentrated in Redmond and nearby Bellevue. (Both are part of Product Support Services.)
In Fox's case, the bulk of Tech Support will be relocated to the Charlotte, North Carolina, User Support Center in phased stages, while the Forum sysops will be moving to Redmond, along with Fox's Developer Services' Gloria Pfeif and Susan Graham. Kristine Ulrich, Forum Wizop, will be leaving the sysop roster to join the main Tech Support group, moving to Charlotte with her soon-to-be-increased-by-one family. (I'm sure I speak for all the ForumFolk in wishing her the best!) Dave Watkins, Chris Pudlicki, and Roger Bischoff will remain on the Forum staff.
Of approximately 40 Tech Support staffers, about 30 are willing and able to move. Yet Microsoft is aware that it will take time to build a quality Tech Support staff. Even with no attrition, at the rate at which FoxPro is gaining new adherents, there will be some rocky periods for the phone group, until sufficient numbers of Microsoft people gain expertise in the products -- and not just at the typical end-user level. Fox's Bart Hanline will be on hand in Charlotte, assuming the role of Unit Manager for the Fox Tech Support group and making sure they're up to the challenge.
The plans
Along with continuing CompuServe and phone support, Microsoft has additional ideas about expanding developer services for the Fox products along with Cirrus, its sister-product in the Database and Programmability Group. (This group also includes all Microsoft programming languages.) A corporate "premier support" program will augment the free tech system currently available.
But Tod stressed that "Excellent support is a key issue for us. It isn't something raised by the merger. And the corporate community has a good image of Microsoft already." While admitting that developers have not always been as happy with the company as is the corporate world, he felt that the plans for expansion would answer our objections. "We know how important it is to get through quickly to a knowledgeable technician, and we know developers have other, varied needs."
Microsoft will have special sessions at the Fox DevCon to gather your suggestions, so come prepared to let them know exactly what those needs are. DevCon will be held in Phoenix this year on September 20-23, with a mini-conference for new users beginning on the 18th.
In fact, you can reach them with information or requests and questions now; the "Dr. Dave line", which you can call at 800/225-6657, has already received over 2,000 phone calls. You can also address them by writing to "Dr. Dave Queries", at 1 Microsoft Way, Redmond WA 98052, where 500 letters have already come in.
Regional dLAB-type advisory groups, membership in which would rotate to allow the greatest possible degree of access, are under consideration. Perhaps as a first effort towards this policy, Microsoft held a special dinner in Palm Desert at the conclusion of Borland's DevCon. When I remarked that this could be viewed as evidence of a somewhat rapacious competitive instinct, Liz Sidman, one of the dinner's organizers, demurred. "Not at all," she said, "we're just using every opportunity available to us to gather input from the Fox development community." I certainly couldn't fault them for that attitude.
Along with the ongoing advisory council, they plan retreats, surveys of the user base, and travel to regional sites, plus a system of call tracking through product support, to collect enhancements and suggestions along with problems. They are currently attending user groups across the country, soliciting feedback.
The organization
I asked about Microsoft's position on opening up the specs of products under development to allow us, as developers, a chance to provide timely provide feedback, and Tod's reaction was very positive. "Our goal is to put developer feedback on the front end, before the beta period," he replied. But his description of the internal development of those specs, and the path they take through the Microsoft organization, made me realize that we were truly not in Toledo anymore.
The key word is "marketing", and the key principle to understand is what marketing means, and doesn't mean, at Microsoft. It seems to include anything you could suggest as "working with customers": interfacing with third party developers and add-ins, providing or locating training, and product support. Tod Nielsen's group is actually the Fox Marketing Group at Microsoft. Under Dawn Trudeau, Director of Marketing, this group is matched with a companion group for Cirrus, led by Mary Engstrom. In this organization, there is also a Developer Relations group, including Mike Johnson, Steve Murch, and Bob Fortner (whom you will probably meet at user demos and regional presentations), and a Developer Support group. Developer Relations will be database-specific, interfacing with developers directly, while Developer Support coordinates developer relations internally for all Microsoft products.
The groups are "team-oriented", which means that people may switch roles within them without formalities, to provide a needed skill, since they possess overlapping experience and expertise. For example, Peter Bladin specializes in coordinating product management internationally, which might mean contributing to marketing strategy one day and developer relations the next. (Within the groups, I have decided to ignore the proliferation of meaningless titles. Microsoft people have a disarming tendancy to refer to one other by knowledge and background rather than position: "he's the Windows guy"; "he's the Cirrus guy". For what it's worth, my contact at Microsoft Australia referred to himself as "the new database guy". Some terminology apparently travels very easily.)
Together, the Developer Relations and Support groups are responsible for developer relations and programs, and something Steve Murch defined as "maintaining an infrastructure for the resolution of technical issues". As such, they all have some technical background and a keen interest in technical concerns.
Meanwhile, in Product Services, Gloria and Susan's FoxPro Developer Support group functions with FoxForum to handle the nitty-gritty, code-specific developers' questions we all have in the process of our work. Although Marketing does not include them or the User Group phone staff explicitly, it is fiscally responsible for them and therefore, in a real sense, is overseeing this area of customer communication as well.
When you think about it, this definition of marketing makes a great deal of sense. Microsoft chooses to view all of the functions that make up the company's "surface" (that which a customer may see) as something vitally important, rather than "superficial". As Tod observed, "More customers require a positive image of the product continuously maintained" -- which is what marketing, by any definition is all about.
What's so important about all this? Well, what I learned in Redmond is that Microsoft is, indeed, a "market-driven", or even "marketing-driven" company, in a very good sense, although the term has unfortunate connotations for many of us. The development of a Microsoft product starts with talking to customers. Since their marketing staff is very product-aware, and includes everyone who is in a position to listen to customers, they are able to list basic requirements, the "must-have" features, by collating the input they receive from focus groups and the other systems described above.
The marketing requirements list passes to the Program Management group; Fox's Program Management will include Janet Walker, in a role that is substantially the same as her current position in Fox Software. With advice and cooperation from the third part of the triad, the Development group, Program Management is responsible for writing the actual product specifications. At this point, the specs are presented to Marketing and Development for input. Specifications must meet the test of those original basic requirements as interpreted from customers' needs, and they must also be technically feasible. Then Development can proceed to write the code. Testing is handled by Program Management, which also supervises beta programs.
I'm not sure that there is an formal method by which Dr. Fulton, as Database Architect, is expected to intervene in this process. His uniquely informed perspective might be brought to bear at any stage. But presumably it is especially valuable as the initial requirements list is written. The Architects represent the contribution of the long view, and a counterbalance to any negative connotations of a "market-driven" enterprise.
It's worth mentioning that, when I visited the Database group, they were housed in a building with offices arranged in a large open square surrounding an atrium space. The developers' offices seemed to be on one side of the square, but not separated from the others in any formal manner. Just as roles within the groups are somewhat loosely defined, members of the three divisions seem to communicate well, often, and naturally with each other.
The future
So throw away your image of "marketing slime"; marketing is what and whom you'll deal with, and this represents your natural means of access to the Microsoft organization.
I talked with Steve Murch about what changes might occur for us in this new relationship. For example, would Microsoft continue the patching system?
In evaluating the company's responsiveness, Tod had earlier made a distinction between implementation of developer requests for enhancements and the resolution of bugs. The former, he felt, should occur slowly and at long intervals, rather than in incremental upgrades, but the latter should be swift. He posited a goal of 12 months between "feature revision releases", but thought that bug fixes should appear "as often as necessary". He added that the product could become more stable, both before and during the beta period, because of Microsoft's extensive testing lab resources.
Steve confirmed that "incremental tuning" in response to problems would be provided, although no mechanism for providing it had been decided on. "We understand that Microsoft needs to improve its openness with customers about problems," he said. However they would not resort to "slipstreaming" new versions without announcement; Microsoft typically appends letters to the end of version IDs when they change source.
Whatever the revision process chosen, Janet Walker indicated that there will be one final Fox patch, when the merger is accomplished, not for fixes but to change the copyright notice on the sign-on screen.
FoxTalk readers and Forum regulars have shared some of their concerns with me, and I relayed them to Janet: how will 2.5 FoxPro run 2.0 code? What basic changes are being made in the product? What policy would be followed on the issue of backwards compatibility? "Our first commitment is to compatibility of 2.5 applications across the different platforms, with the understanding that some platform-specific features will be ignored where they do not apply," she explained.
In most cases, this commitment will not preclude backwards compatibility as well, but Janet reminded me that Fox has always had to accept some small changes in their products' behavior, to accommodate new and powerful features. "We try to make the choices that will benefit the greatest number of users." (For example, BROWSE LOCK is a feature in FoxPro that is not nearly as useful as it was under FoxBASE, since the LOCKed fields are duplicated in the two partitions. However, BROWSE partitioning in FoxPro gives you far more flexibility.)
To determine backwards compatibility, Fox tries to make a distinction between what the command or interface object was really supposed to do, and additional "excess baggage" it might have carried. For example, SET STATUS does a CLEAR of the SCREEN. If you relied on that behavior before you began to DEFINE WINDOWs for your output, your output would always be cleared. However, if you have ACTIVATEd a WINDOW in FoxPro, CLEARing the SCREEN may not be doing what you need anymore. It may also be an extra layer of confusion, in the Windows product, to be CLEARing an element of the interface (the SCREEN) which is not currently ACTIVATEd. What does "backwards compatibility" signify, in this situation?
Inevitably, we have to expect that some of our workarounds and reliance on peculiar side-effects of Fox commands and functions will cease to work in the new products. They may be workarounds in which we have a great personal investment of time. As Janet put it, "We will continue Fox's policy of being sensitive to developer needs to retain old behavior whenever possible." But she recognizes that expanding capabilities will sometimes conflict with this goal. And so, realistically, should we.
Janet thinks that Fox will avoid creating future problems of this nature by avoiding the creation of new commands "that do multiple things", as many X-Base commands do. Steve Murch described Microsoft's approach in very similar terms. "The challenge of program management is to balance the desire for powerful capabilities against the confusion of the countless permutations those capabilities can create." The more predictable and limited the results of a command, the fewer permutations can result from using it. "Fox excels at providing power. We need to continue to simplify."
This challenge is especially daunting when you consider the FoxPro mandate for compatibility in the DOS, Windows, Mac, and Unix versions. The possible permutations become greater, not withstanding the common code base.
However, this cross-platform advantage is one of the most attractive aspects of Fox for Microsoft. Microsoft, as the largest Mac software vendor, has a special vested interest in the Macintosh's continued success in the corporate world. But Steve pointed out that the Mac product's availability also has a "multiplier effect" on the attractiveness of the whole product line for corporate decision-makers. FoxPro complements their support of Word and Excel as cross-platform products. They have been very successful with this strategy, although they will acknowledge that Windows versions of their products are often given first emphasis in development, in response to their perception of market demands.
It may have been easier for Microsoft to "build power simply" into Cirrus, because Cirrus can use Windows to provide many of its features -- but this is because Cirrus is completely Windows-specific. Only Fox will be providing the competitive advantage of multiple platforms to Microsoft's presence in the database field, quite apart from its premier speed and other qualities.
FoxPro and Cirrus do not compete, but rather complement, each other, although there will be minimal integration between FoxPro 2.5 and Cirrus's initial release. (Integration will be emphasized in later versions of the products.) I can't say much about Cirrus itself that you haven't already heard elsewhere:
Eventually, either the best features of both products will migrate (including Rushmore from Fox and Cirrus' interface) or they will combine to form a new product, open to having its processes driven by both programming languages. Rest assured, you will continue to have X-Base access to your data. Access to data stored in different formats will be provided by sending requests for information through ODBC (Open Database Connectivity), the software layer which will translate such requests to data servers.
This is going to take a long time to accomplish; it's the large and complex task over which Dave Fulton is rubbing his hands with glee at present. Little immediate change will occur. The 2.5 versions of FoxPro will be products you already know how to use, even if you are entering a particular environment for the first time. As for 3.0... a little trust, a sufficient quantity of patience, and our continuing dialog with the Microsoft/Fox people will take us a long way.
See also: People That Helped FoxPro to Become a Legend: Lisa Slater Nicholls