Oct 96 Factory Floor
Volume Number: 12
Issue Number: 10
Column Tag: From The Factory Floor
Garry Hornbuckle, DevTech Leader
By Dave Mark
This month’s interview is with Garry Hornbuckle, manager of Apple’s Developer
Technology Services Group. You may recall that, two months ago, this column featured
Heidi Roizen, Vice President of Apple Developer Relations (ADR), and that Heidi
introduced Garry’s group. Here, we’ll take a closer look at its various activities.
Dave: Tell me about Developer Technology Services.
Garry: Our overall mission in DevTech is to design, develop, and deliver the
technical information, services, and systems needed by developers to be
successful with Apple technologies. This group includes the teams from
Developer University (DU), Developer Press (DP), and Developer Technical
Support (DTS).
Bringing these three teams together organizationally is a reflection of one of my
key goals for improving the technical proposition for our developers.
Individually, the past efforts of these groups have ranged from pretty good to
excellent. We’ve had award-winning technical documentation, for example. But
we haven’t been good enough at integrating each of these information delivery
channels. Supporting developers technically is, after all, a life-cycle. If we do a
poor job with documentation or with training, we have to expect decreased
technology adoption, or increased technical support requests, or both. But if we
do a great job with documentation and training, we can look forward to greater
technology adoption, and to better, more focused support questions. That means
faster turnaround times and crisper responses for developers from DTS, and that
means that developers can get back to coding more quickly. And now, we’re
talking about improving the business proposition!
In addition to those three groups, DevTech consolidates world-wide
responsibility for Apple’s third-party compatibility labs with our developer
training facilities. We expect that this will allow us to better equip labs
world-wide, utilize facilities, and coordinate with the prototype hardware
seeding program managed in ADR Evangelism.
Finally, DevTech includes a “systems” group to provide IS&T services across
ADR and to our developers. Most visibly, this includes Apple’s presence for
developers on the Internet. We’ve been moving rapidly to leverage Web
technology for distributing information, and there’s lots more on the way.
Dave: The Windows universe is undeniably larger, and many people say that
Microsoft’s Developer program is better than Apple’s (and it’s free, I believe).
What ammunition can you give to Mac developers trying to persuade their bosses
(and possibly themselves) to keep their focus on the Mac?
Garry: First off, I’m not going to take any shots at Microsoft or at Windows.
They’re an important developer on the Mac platform, and today’s business
proposition is largely cross-platform.
That said, Apple has to offer a compelling business and technology proposition on
the Mac OS to attract and retain developers. I believe that most of the coolest,
most innovative technology appears on the Mac platform first - sometimes from
Apple (such as QuickTime), and sometimes from developers (there are many
examples). But cool technology is valuable only if we enable developers to
access, understand, and effectively apply the technology to their product. That’s
where my group comes in, with a goal of providing the best possible
documentation, training, sample code, and technical support.
Other parts of ADR are chartered with other parts of the platform proposition:
marketing with and for developers, providing access to market information,
offering strong developer programs, and so forth.
What’s free and what’s not? An easy question to answer in general, but much
harder to answer specifically. In general, Apple should not and does not view
developers as a profit center. They should be, and are, seen as an investment in
our future, as their success and our success are completely interlinked. Does
that mean that all developer support programs and services should be free?
Well, it’s a goal for ADR to offer the best possible support to the broadest
possible audience. But I don’t think that means “one size fits all” in terms of
support needs, nor do I think that every support option we might offer to
developers will have the same perceived value.
To me, the bottom line is value. If the value of what we provide to a developer is
worth (or exceeds) the cost to the developer (which might or might not be zero),
then we have a win-win. If we have a program or service where the value
proposition is not right (it costs too much for what you get), then we need to fix
that. That may be done by lowering the price, by increasing the value of the
content, or through some combination of both.
Dave: Right now, trying to master a specific Mac technology means tracking
down a series of Tech Notes, juggling multiple Inside Macintosh volumes, hunting
for obscure (and often unpublicized) emails from DTS, plus searching through
comp.sys.mac.programming. You get the idea. How will you help ease this
learning curve?
Garry: You’re right. This has been a problem. As the Mac OS platform has gotten
more and more complex, we’ve had a hard time keeping our documentation,
training, and support strategies synchronized with each other and with R&D
engineering. As I mentioned earlier, this is one of my top priorities this year in
this new job. The first step is a reorganization such that all of our written
technical content is managed by a single organization. That means that there’s a
specific human being whose neck is on the line to make this better. - And it
happens to be me... (Laughs)
Of course, another part of the answer is technology. We are rapidly getting all of
our technical content up on the Web, in a searchable form. That’s got to help. We
are also rolling out interactive developer training on the Web. In fact, there are
four DU classes on the Web now (including an introduction to MacOS 8), with
several more scheduled to be ready and online before the end of this year. We are
also working on using Internet chat to support Web-based training, so you’ll be
able to interact with an instructor, live, in real time, without leaving your
office.
We’ve got a number of DTS engineers who, just because they are amazing and cool
people, hang out on the net, in c.s.m.p., or on AOL, or elsewhere, answering
questions. We’re working with Apple IS&T to complete the internal transition to
Internet technologies. As our infrastructure gets better, you’ll see more of this,
not less.
Dave: How about the path from DTS to documentation? Will you do anything to
help cause the answers provided by DTS to migrate into Inside Macintosh?
Garry: DTS has been great about turning important questions with broad interest
into Tech Notes. What we haven’t done in the past is to have a well-defined path
by which Tech Notes “grow up” to become more formal documentation. So there
was a separate Tech Note index, and revisions to Tech Notes, etc. Why not just
have Tech Note content integrated with the reference materials on a regular
basis, you have to ask. And that’s the direction we’re pushing.
That doesn’t mean that Tech Notes aren’t valuable; they are. But their core value
is that they are quick turnaround, and accurate enough to get the job done. They
may not have perfect grammar or style, and they may not meet other standards
for Apple technical documentation, but they are quick enough, and good enough.
We don’t want to lose that, but I do want them to become incorporated much more
quickly into our reference documentation such as IM.
Dave: What is the future of Inside Macintosh? Given the dynamic nature of
Apple technology, will Apple’s official documentation continue to be a batch
series that gets updated only every few years?
Garry: As we have started our move from “paper-first” to electronic publishing
and online content delivery, we’ve also been reworking our internal processes.
Before, things were oriented around a large project, delivered in print - for
example, an IM volume. We’re now pushing for a model that is based on smaller
chunks of work that are continuously “pipelined” through the electronic
publishing process. IM itself is a huge challenge, but one that we are going to
tackle. It’s too soon for me to know what I can promise, and by when. But if you
look at the process we are now using to write seeding documentation for prototype
hardware, you’ll see that we’re ready to move on this. You’ll also see Inside Mac
on the Web, probably by the time this interview is published.
Dave: How about tracking bugs on the Internet? Will there be a mechanism for
finding out if what I suspect is a bug is already known?
Garry: We’re now beta-testing and making final tweaks to a brand new system
that exports Apple’s internal bug reporting and tracking system, called Radar, to
the Web. Internally we call the result RadarWeb, though I think we’ll probably
introduce it as the Apple Bug Tracking System. Using RadarWeb, developers will
be able to view a list of known bugs across several technologies, including Mac OS
8, ETO, and System Update, with more planned as we go forward. In addition,
developers will be able to submit new bug reports against these technologies, and
track their bug through the various stages to its resolution. Rollout of RadarWeb
is planned to accompany the DR1 release of Mac OS 8. And before you ask: no, I
don’t have new information to share about DR1 availability - but remember that
we’re keeping the Mac OS 8 developer Web site updated with new information as
it becomes available:
http://www.macos.apple.com/macos8/dev/devworld.html
Dave: Apple’s current developer Web presence is slow. What changes do you
have in store?
Garry: We’re making a significant investment to upgrade our internet
infrastructure; this includes working out world-wide mirror sites, getting
bigger, faster, and more numerous servers, routers, and pipes, and thinking
much more carefully about the way in which we organize our content, so that it
takes less time to find what you need. And, as I mentioned earlier, I’ve also
created the ADR Systems group, with a specific manager held accountable for
keeping pace with the demands for Apple-developer Web-based communications.
You get a lot of focus on a problem when there is a directly responsible person.
Dave: What will you do for folks who don’t have access (or have only slow
access) to the Web?
Garry: We are moving strongly to the Internet and Web as our main focus, but
the Web is not everywhere, for everyone, at least not yet. So we will continue to
use other media for content distribution and communications, based on local
conditions and options. Print and CD in particular will continue to play an
important role. In Beijiing, we do tech support by fax. So it really depends on
the specific situation.
Dave: What is the future of Apple’s various disk-based document types for
documentation? We see Acrobat, DocMaker, MS Word, SimpleText, and even
HyperCard. Is there a final word?
Garry: (Sighs) No final word, but a current plan. If only all of you could agree
on a single choice! And if the discussion of the pros and cons on Semper.Fi is any
indication, we’re not at all close to that goal.
Seriously, we’re going to produce documentation in multiple formats for now.
There are various reasons for using some of these different tools, and each is
valid in its own context. There are some incremental costs incurred in doing
this, and I would really like to squeeze these out. But with good automated tools,
the incremental costs needed in order to output QuickView in addition to HTML,
for example, are not that great.
Dave: Are there plans for expanding Apple’s storehouse of sample code?
Garry: I hear this request all the time, and yes, we are planning to expand in
several ways.
Our first step is to take stock of what we have (almost complete), and to get a
real source code control system into place (scheduled for Q4 CY96). At the same
time, we need to get a process and resources in place to make sure that all of the
sample code compiles every time we update system headers, etc. Then we get all
of the documentation efforts to reference into this sample code library, so that
the examples you read about are available, and the examples you discover online
are documented. Then, we’ll start writing and collecting and publishing even
more examples. Of course, DTS and the documentation group will continue to
create sample code on a day-to-day basis as they do now. But I want to
dramatically improve our sample code library in the future, including making it
searchable on the Web.
Dave: What about the famous twenty million dollars that Gil gave Heidi? Do you
get any of it? If so, what are you going to do with it?
Garry: If I had one dollar for every time someone asked me about the $20M, well,
I’d have $20M! - Right. Apple has allocated $20M over the next twelve months
to help developers get their products in front of customers. This money will be
spent roughly half in the US and Canada and half in Apple’s markets outside the
US. All of Heidi’s team are working on programs now that will best leverage this
money in both the traditional channel as well as in some emerging channels.
The funding is likely to be split among channel initiatives, “virtual” and
Internet initiatives, co-marketing and collateral materials, and some pull
advertising. In order to maximize the leverage, we aren’t going to be looking at
specific proposals from developers, but rather to take their input and create a
few standard programs that can either be shared by all, be “pay-to-play”, or be
targeted to particular segments of the market. That said, we are looking at some
new and expanded support services and options in DevTech as well - things like
the expanded sample code library service, for example, improved compatibility
lab access, and more.
Dave: People on the West coast have great access to Apple’s compatibility labs.
What are you doing for the rest of us?
Garry: This is a harder problem to solve than some, but consolidating ADR labs
and the Cupertino third-party compatibility lab group is the right first step.
Next, we need to work much more closely with Evangelism to coordinate the
availability of prototype hardware in our labs. We’ve just brought the Munich
lab up; this should help European developers some. We’re now looking into the
next priorities - a possible second lab in the US (probably in Boston), a lab in
southeast Asia, and a lab in Latin America.
Since we are still in the planning stage, and our FY97 budgets are not nailed down
yet, I can’t promise how this will come out. But I think that it would probably
save Apple money and would be a strong benefit to developers if we could assure
world-wide lab capacity, including old and new hardware, rather than having too
few prototype machines to ship around for too few days at each location.
Dave: What is your vision for the future of Apple Developer Relations? How
does this impact the smaller developer?
Garry: I have two major goals for my new job. The first I’ve already talked about
- getting our technical content and services integrated into a life-cycle approach
to communications with developers. The second is extending the range of
developers’ needs that we can address. Access to technical information and
support options should be there for any developer interested in our platform.
Some will be free, some will be pay-to-play. But I’d hate to see anyone turned
away because they “didn’t fit the mold”.
If you think of DTS as the middle of the support spectrum (predominantly but not
exclusively mainstream, commercial, etc.), then we need to broaden in two
directions. First, “downward” to reach out to the larger number of casual
developers, hobbyists, students, etc. Second, “upward” to smaller but
significant numbers of strategic opportunities that require rapid response and
the highest level of expertise. We have plans on the FY97 drawing board for new
services in both of these areas, and I am very hopeful that we’ll successfully
launch new support offerings this year.
To check out the fruits of Garry and Apple’s labor, including Inside Mac online,
check out:
http://www.devworld.com/
-ed/wgi