Behind the Code with Terry Crowley.
>> The Internet seems to be at the very core of almost everything we do today.
It's hard to imagine a time when it wasn't available. To become this pervasive meant turning the Internet and, more importantly, the Web into an informational fabric that can be grasped and utilized by the common man. Today's guest has long been involved with making the Internet accessible to people of all walks of life.
Hello, I'm Robert Hess and I'll be your host today as we talk with Terry Crowley, a technical fellow and developmental fellow for Microsoft Office. I hope you enjoy this chance to look at the technology and the person behind the code.
After graduating from MIT in 1982, Terry worked for over ten years at BBN Labs.
From there he went to work for Banyan Systems and BeyondMail. He then hired into Vermeer just before that company and its core product FrontPage was acquired by Microsoft.
Today, he is a director of office development focusing on the next version of
Office, Office 14.
Join me now as I welcome today's guest, Terry Crowley.
(Applause.)
>> Richard Hess: Now, Terry, all this working at Microsoft here, at some point in time got that bug, you know, the little technology bug that forces you into computers or programming or whatever.
Where did you first get involved in technology?
>> Terry Crowley: Well, my dad was actually very involved in computers, he wrote a book called Understanding Computers. But I didn't really get involved in computers just barely in high school, you know, we did a little basic programming, everybody -- you had the paper tape that you fed into the computer back then. But it really wasn't until I went to MIT and I was originally going to be a chemical engineer.
>> Robert Hess: Chemical engineer and programming --
>> Terry Crowley: Very different. But I took an introductory computer course there, given by Joseph Weisenbaum and I sort of got the bug there. He wrote a book called human power -- computer power and human reason, and there was one line from that book that I think captured really what got me excited and it was something, Like no general has ever commanded more power than a computer programmer programming his environment, his world.
>> Robert Hess: So you're a power fiend.

>> Terry Crowley: Right, exactly. All about control.
>> Robert Hess: So from there you switched from being a chemical engineer to being a computer programmer. Did that happen instantly or over a year or so?
>> Terry Crowley: Well, I took that first course, the freshman year and I sort of found I was pretty good at it, and then that summer I got an internship at Bell
Laboratories, which is where my dad worked as well. And that was my first introduction to programming and C, and getting a lot of the experience with Unix, and sort got excited, I found I was pretty good at it. And so when I back, in the sophomore year, that's the direction I took. And I got much more involved in computer classes at that point.
>> Robert Hess: I bet your dad was pretty happy that you were following in his footsteps.
>> Terry Crowley: I think he was pretty excited to see me go down that path.
>> Robert Hess: I understand you come from a rather large family?
>> Terry Crowley: There's 14 kids in the family. Seven boys and 7 girls.
>> Robert Hess: I have a hard time grasping that in my head. Because you were kind of on the younger side.
>> Terry Crowley: I was tenth. There was the old kids -- or big kids and little kids and I was on the little kids side.
>> Robert Hess: How many of your siblings went into technology?
>> Terry Crowley: My two younger brothers also went to --
>> Robert Hess: Talking about your siblings, a bunch of them.
>> Terry Crowley: Two younger brothers went to MIT and were into computers, actually my youngest brother who I think is still actively programming, the only one actively programming besides myself. And then some of my older brothers who got into some more business analyst type of programming, but there's a few doctors and lawyers and CFOs and other disciplines or professions in that crowd.
>> Robert Hess: In your early days, you worked with BBN Systems, you worked on this program called slate. What exactly was that?
>> Terry Crowley: Was a multimedia document system, is what we called it.
And so it was basically a word processing system where you could put spreadsheets and graphics and images and audio clips in it and it was also sort of connected to e-mail. So I could e-mail these rich documents around. It started off as a project called Diamond that was funded by DARPA.
>> Robert Hess: What year was this about?
>> Terry Crowley: Diamond was in '83, '84. And then as that project was initially funded by DARPA and NSF and we turned it into a commercial product called
Slate. In the late '80s. So when I first joined BBN, I had a work station that had a

200-megabyte hard disk, and I think it was probably another 12 years or so before I had a hard disk that big on an actual PC.
>> Robert Hess: This time, especially since you mentioned e-mailing with Slate, the Internet was really kind of an undercurrent for computers, like a lot of people were using Internet for doing FTP, and file transfer access and things like that long before the general public really understood what the Internet was. And so you were kind of involved in some of that Internet development stuff.
>> Terry Crowley: BBN, was one of the sort of core developers of the Internet.
You know, and the people I worked with were involved with that. I worked with
Ray Tomlinson who famously is the person who picked the at symbol for e-mail and turned out he wrote the first e-mail program and I worked with him for ten years. Fabulous engineer.
And Jenny Travers (ph) who I worked with very closely wrote the first Internet router. So you know, I was definitely very close to them. And a lot -- I was on some of the Internet task forces, and you interacted with some of the famous names, John Pazall (ph) was someone I worked with quite a bit and he was very famous in the Internet development.
>> Robert Hess: Those days did you comprehend that the Internet would become as ubiquitous as it is today?
>> Terry Crowley: It's kind of funny, I think -- the people who were involved definitely felt this is different, people just don't get it what it's like to be working on a computer and to be, you know, 30 milliseconds away from any other computer on the Internet.
At the time we would work a bit with some of the Bell system folks, and they were thinking about T-1 lines and direct, you know, conferencing between one computer and another, and we're like going why would I ever want to connect to one other computer. I want to be connected to all these other computers.
So there definitely was a feeling that this is different and people don't quite get the difference. But it was still uncertain where it was all going to go, because there's -- you know, there was a lot of (inaudible) manager and Banyan had their system and deck had its own system and exactly how it was going to evolve, it was not completely clear that TCP/IP was going to take over the world.
>> Robert Hess: Back in those days I was working on deck systems and we had deck net that was linking our PDPs together. It was a big deal. And just to connect one computer up to another and get a file transfer. I'm sure the same thing going on when you first going those connections and seeing the bits go across the wire.
>> Terry Crowley: The first connectivity is pretty exciting. But it was definitely, it was a different world. Because I think in terms of the size, you know, I tell the story about when my work station that I was working on, we were going to tut if

on the Internet and there were only a couple hundred machines on the Internet and so it was exciting to have the computer on the Internet and nowadays of course your computer is on the Internet. But there was no domain name system and no hierarchy system and just a flat name system. I sent a mail stomach
John Pazall and said I want to name my machine pearl, and he said you can't because there's a computer at University of Massachusetts named pearl and you have to pick another name. And so that was it, it was a single person deciding what you could name your computer.
>> Robert Hess: Unique name for the entire Internet.
>> Terry Crowley: And it wasn't until the domain name system got in place where you could name it whatever you wanted.
>> Robert Hess: Do you think it took to be the one name --
>> Terry Crowley: I don't remember the exact history. That was the mid to late
'80s as it moved into that.
>> Robert Hess: System think immediately if I want more than 100 computers here we need to have more than just --
>> Terry Crowley: It seemed like it should be obvious, but I think getting big was, you know, a lot of folks who were working on the Internet thought about getting fast. You know, getting -- go one megabits per second and three. And moving up but there was a pretty good understanding the problem wasn't getting fast; the problem was getting big in terms of number of individual nodes on the Internet.
>> Robert Hess: For most people, their connection to the Internet comes through the web. Now -- and the web is relatively a recent newcomer to the
Internet world. Prior to that we had FTP connections and gopher connections and other capabilities. Having been involved in the early days of the Internet, do you see the web as being the forcing function, as kind of unfortunate and you wish some of the other technologies used prior to that having value as well or are you glad for the web.
>> Terry Crowley: Actually I think it was a couple brilliant insights about that and some just being at the right place at the right time.
I mean the neat thing is like I said, it was -- the folks who were working -- when we were working on these Internet programs I was doing real time conferencing, where you're connecting multiusers and doing this. This thing about how do I actually show that I've got a computer that's that -- just milliseconds away from any other computer and the neat thing when -- the first web pages were all list of links, everything was lists of links, and the neat thing was you had one page that boy, I could very easily go from one site to another computer. And that -- and the web did a great job of bringing that home. That you were actually -- you really were connected to all these machines and just milliseconds away from each of them.

I think when that came it was like, yeah -- I looked at it and should have got that.
Kind of obvious in retrospect. Hypertext was something that was there, everybody was building hyper text. I built a hypertext system a local help system that built on top of this infrastructure but it was a local one, it didn't pull all the pieces together the way that the web did.
>> Robert Hess: It sounds -- I never saw it until I was chatting with you about this but the fact you had this rich text in audio video stuff going back and worth.
Back when I was sending e-mail it was raw text and if a picture came across it came as encoded and I had to paste it into a separate file but it sounds like you were tying everything together.
>> Terry Crowley: No, I think it was another -- after I left BBN, it was 5 or 10 years where I felt I had as rich a set of tools at my hands as I did when I was working there.
It was a pretty capable system. Despite the fact that it was about five DEVs and we eventually added one tester. Which is pretty, you know, it's neat that we could have delivered that although we delivered one version where I think a menu if you pulled it down, the product crashed. Nothing about special about the state, but if you selected that menu item --
>> Robert Hess: Where testers were important.
>> Terry Crowley: I have great respect for testers.
>> Robert Hess: It's interesting to see you started off with this rich text system and now you're involved in office another big rich text system. Do you see similarities between those two?
>> Terry Crowley: It's been interesting how many of the concepts that I sort of learned and built into the systems sort of early in my career are still relevant at
Microsoft when I'm working on applications there. I remember sort of the first conversation I had with Peter E. about the one node architecture and we started talking about it and immediately we sort of drove to sort of key topics about design of these systems that really I was working with throughout my career. So there's a lot of sort consistency about the way these systems are designed, even today.
>> Robert Hess: I mean, the problems we're facing are basically the same problem, it's just the quality of the solution sometimes can improve, and leaping off the shoulders of someone else until you finally get better systems. I'm not sure how many fonts you had in Slate --
>> Terry Crowley: Fonts were a big problem. X. window system we moved to after sort of some of the early systems we were working on, has a pretty painful sort of font system underlying it.
Actually, one of the first programs I wrote was a font editor, because we didn't have enough fonts when we were on the custom work station we were using at

BBN, so we said I'll build a font editor and that was way before I understood how hard it is to design good looking fonts.
But that was fun.
>> Robert Hess: Probably like by the map fonts.
>> Terry Crowley: Completely different. These were machines where they were called 3 M machines. Sort of one megabyte, one megahertz processor, and one megapixel display. Which seemed incredible amounts of resources. And now we're a factor of -- or three orders of magnitude.
>> Robert Hess: As I alluded to in the entry, one of the things that I think makes the Internet extremely useful and popular, is the fact that it addresses itself more to just the geeks of the world but to the common man.
And the web being the thing that people come up to from that standpoint, I also see FrontPage as being a very big part of that story, of making the web real, because now you have a tool that the common man can actually create web pages with without having to get into the HTML, and you were quite involved with
FrontPage early on. What was that like?
>> Terry Crowley: Was sort of an interesting process. I had worked at
BeyondMail -- so I left BBN, and worked at BeyondMail. And a couple of my friends at BeyondMail went off and started Vermeer. And I didn't quite know what they were doing because they kept things very, very quiet. But then soon found out they were building a HTML. I understood they were building a HTML editor and I'm like Microsoft is -- adobe, whatever, how do you compete with just building a HTML editor. And so it was pretty neat when I got a demo as I was talking about joining them, and sort of realized that they weren't just building a
HTML editor, he were building the website absence the metaphor of the thing you're building and page editing is one part of it. And the length of the dynamic execution at the server. And it just wow, the numbers -- the things you could do with a product like that, where there was just huge room for innovation in different areas. Got me just really excited about joining up with that.
And also was the case when I understood how they had they had built the HTML editors there was something I could teach them about how to build editors and I was excited I could bring direct value to that. But recognizing all the other value they had already built.
>> Robert Hess: To continue to build on your strength you started with Slate doing this rich editor, word processing capability.
>> Terry Crowley: Right, and I also had built a rich text editor at Banyan and I had done a whole number of editors along the way so I was able to come in and really give some sort of guidance on the way to architect that system, and it took us a few -- we were shipping so frequently, it took us a few releases before we got it sort of to the architecture we wanted. But over time we did that.

>> Robert Hess: Had you been doing much with HTML before this time?
>> Terry Crowley: Been just playing around with it at Banyan. The -- we did the
Internet-enabled version of the mail client so I did the POP and SMTP protocol support for that and the rich text editor support for the Banyan mail client. But we were just -- that was just at the transition point where we were sort of viewing
HTML mail as a way of saying rich text content. There were a couple other less functional ways of encoding rich text in e-mail, and with the rise of the web it became sort of obvious we should just use HTML as the rich content so we were starting to get some experience there but there was really then when I jumped into Vermeer that I sort of became familiar with it.
>> Robert Hess: Kind of a big problem with rich text since the Internet was
Internet e-mail was meant to go from machine to machine you had no idea what which inch machine so standard on a MacIntosh wouldn't be on a PC and other systems and stuff like that. And that's where HTML provides the connectivity between the systems.
>> Terry Crowley: One of the issues that just getting standard -- getting it standardized was critical. That each of these systems had various different sort of capabilities in those areas. But getting them all to agree that we'll just use this was what was the critical thing that enabled sort of the ability to send the rich content.
>> Robert Hess: Flip side is you need a graphical text editor that can take and then convert to HTML because otherwise whatever your standard word processor you would have to expect that to convert which maybe it couldn't because that's wasn't standard back in those days.
>> Terry Crowley: That's an interesting topic. It's a hot topic actually right now because with document standardization, with ODF, and open XML, and whatever, these underlying systems have different models for what a document is and what text is, and how to structure it.
And the assumption that you can map from one to the other isn't necessarily true.
That they have very different models they're trying to present to the user and then how they encode the information.
>> Robert Hess: Quite often the word processors they have internal things that they're really trying to accomplish which HTML can't handle without special encoding going on partially that's why CSS exists, launch on top of HTML, so there's other ways, other things you might have in a document you might not work properly in HTML.
>> Terry Crowley: Of the things you saw with when -- when office went down the path of encoding Word documents in HTML, is they needed to add a lot of additional context around the HTML information to carry around the semantics of the document versus the visuals of the document. You can get the visual straightforward but either it wouldn't edit like previously edited and carrying the semantics is a tricky issue. And if you don't have -- if you're coming at it from two

different models, then it becomes difficult. You use information when you map from one to the other.
>> Robert Hess: Also gets into an issue I know I personally had with FrontPage,
I like doing HTML in notepad. And then when I used to pull it into FrontPage and drop back to notepad, oh, that's not the HTML I wrote.
>> Terry Crowley: Preservation, I can go on for an hour talking about HTML preservation. I mean, it's an interesting -- it's actually kinds of interesting story because when FrontPage first started, and in fact you could hear quotes from
Tim (inaudible) who -- you know creator of the web, that he assumed that nobody would be writing -- handwriting HTML. That eventually everyone would go to these editors. And so the assumption is all editors work by sort of pulling the content in and mapping it to an Internet representation. And then you fiddle with it and they map it to an internal representation that makes it easy to manipulate.
And so -- and then they write it out. And mostly people don't look at what got written out. But in fact, because people were both wanting to hand edit information, they expected the editor to not change anything. But in fact not changing anything is actually really hard, because you want to map it into an internal representation that's conducive to editing.
>> Robert Hess: Keep track of before and after shots and --
>> Terry Crowley: It's actually incredible difficult because there's a lot of information in a hand edited HTML file about spacing and case and of tags and attributes and whether you use quotes or don't use quotes and things like that, that are totally immaterial to the actual the semantics of the content and yet from a user's perspective they might be very material to the way they wanted it to look.
And so really it was over time FrontPage '98 was the first version where we started trying to do a good job about, S2000 was a whole new rearchitecture, again trying to do a much better job. And then it was 2002 and then finally 2003 where I think we had the best preservation in the industry.
But everyone always assumed there was something in there we did to pollute to their HTML as opposed to how difficult a technical job it is to not change anything. On the top of that was the other trend that was happening was server side pages -- pages that were expanded on the server side and so what you were actually editing was not HTML, it was ASP. Or ASP.net or PHP, or these different service side languages. So it was HTML embedded with code, and so they expected us to read these pages which aren't really HTML and then do nothing -- you know, only make the changes. And that was -- it's a tremendously difficult job, and I'm actually, very proud of the work the team did to the quality of the job it does now.
>> Robert Hess: Now, are you saddened by the fact FrontPage kind of doesn't exist anymore?

>> Terry Crowley: Yeah. So FrontPage diverged into two products. It's bittersweet the FrontPage was a very damaged brand at a certain point. I think partly because it got so much success so early and it ran into these issues of
HTML preservation and other things that a lot of people -- and a couple other decisions. We made a decision about theming, to sort of spread HTML codes and comments throughout the HTML, to support this notion of theming. So you could simply make a quick change and it would change all the fronts and background colors and things like that.
And so it was a couple features we did that generated this sort of expanded the
HTML and ugly HTML. And so FrontPage as a name got this bad reputation among sort of the high end HTML coders, and despite the fact that over the course of a number of releases, we really focus on HTML preservation and clean code and whatever, it never sort of lost that reputation. And so I think what we did is focused on share point designer which is of course sort of building on the great success of the share point product. And then expression web which is really focused on this high end professional web developer. And so I now have two products that are the base -- actually three products, individual studio design surface is also based on FrontPage. The FrontPage design service. So I feel good about my code lives on.
>> Robert Hess: Three products rather than just one now.
>> Terry Crowley: Exactly.
>> Robert Hess: Now, where do you see the future of this web design market moving to? I mean, the same concept moving forward, or do you think a new problem coming up?
>> Terry Crowley: So, I mean the dynamic of the market has been pretty interesting because essentially we were focused on -- we were assuming there was going to be this sort of broad lower end of the market, and you know, and in fact what happened is these tools like share point and these backlogging tools and these things that are very focused on not sort of general Web editing and
Web authoring, but rather these very focused ways of contributing content really sort of took over the lower end of the space.
And so the essentially the hobbyist market, has sort of went away, where it's sort of a very small market. Versus the high end sort of web design authoring market and then these sort of website self-service website markets.
So that's been a theme and its -- that's a theme that's going to continue because it is these browser-based authoring environments are pretty easy to use and there's a lot of technical advantages to that approach.
The other sort of big interesting sort of evolution is around some of these rich
Internet applications, whether it's Silverlight or flash base sites and how they're

going to evolve into the way we see the web. And there are good things and bad things about those.
>> Robert Hess: The whole concept is being able to embody the developer solution designer concepts to get those things to the users, whether it's through
HTML or like you said Silverlight or --
>> Terry Crowley: The difficulty of course is that HTML has some nice characteristics around searchability and archivability, and issues around accessibility that sometimes when you build flashlights you don't get those benefits. It's harder to get those same benefits that HTML brings.
And so really thinking about how both you can create a great end user experience but not lose some of the benefits that sort of a HTML base web gives you is important.
>> Robert Hess: I regularly see entire sites that is basically one web page, very little HTML code and inclusion of a flash object in it essentially this black box as far as the search engine things are concerned.
>> Terry Crowley: Right, which is sort of painful for all these other different uses.
And so one of the things interesting things is when you think about these technologies is thinking about sort of the overall -- the whole ecosystem about how these technologies interact. And so I think there's still a lot of room for innovation thinking about how this rich content types and interaction types sort of emerge with these other capabilities of the Internet.
>> Robert Hess: Now, you're focusing now on the next version of office. Do you see that as an evolution from your FrontPage work or is it a shift in your duties?
>> Terry Crowley: Well, it's a pretty big shift in terms of sort of general responsibility for sort of overall development in office. On the other hand, it's amazing how much of what I've learned over the course of 25 years or so in the industry is still relevant in terms of how we build applications and how you think about applications that interact with remote data and what's the proper way to structure them. So that you get -- you can create responsive applications.
That's an area that I've been working a lot on, is how you design applications so that they're always responsive and don't hang on interacting with remote sites.
>> Robert Hess: So that the user is never really aware he's using a program that someone wrote that might have -- I want to write a document, access file and bang it's --
>> Terry Crowley: Right, and I think the important thing that we sort of have to realize is that it's different than when you're working on be a single computer with a hard disk that you know exactly how long it's going to take to read a file. When you're interacting with the Internet, things are inherently -- you don't know. And so you have to write the program differently. And you have to -- you have to think about what the user experience is going to be as the user is waiting for that

file to come in and the error conditions are different you can't just make it transparent or ignore it.
And I think we need to do a better job there and we're going to do a better job, so pretty excited about some of the things we're doing.
>> Robert Hess: Enough talk about work. Let's talk about something fun. I understand that you've got an outside hobby of playing what they call ultimate frisbee.
>> Terry Crowley: Yep.
>> Robert Hess: I know nothing about ultimate frisbee other than there's a frisbee involved, I'm assuming. And it's not an ultimate frisbee, but a frisbee you're playing this ultimate game with.
>> Terry Crowley: Ultimate frisbee is a field sport played on a football field sized field. Seven on seven, so there's seven people on one side, seven on the other.
You can't run with the disk. You have to throw the disk to one of your teammates. And the goal is to throw to one of your teammates who is in the end zone and you score a goal when that happens.
And the other team is trying to knock down the disk or intercept it. And as soon as it's turned over, the other team is going the opposite direction. So it's a lot like soccer in that respect where you go back and forth very quickly. So it's a very active sport, lots of running, it's a great sport. It's -- it was invented about ten miles from my home, so I've been --
>> Robert Hess: Your home in Seattle.
>> Terry Crowley: I grew up in New Jersey. And to my ever lasting regret my younger brother actually played on the original, you know, parking lot field where they used to go play on Friday nights, and he actually was the one who really introduced me to playing frisbee. He went to the mythical first field, but I learned it in high school and then went to MIT and played there, and then the team at
BBN, I was very lucky in playing with a bunch -- it was the corporate league in
Boston. And a bunch of the players that I started playing with ended up going on to join some club teams and ended up winning world and national championships. And so I was sort of lucky enough to play with some amazingly good players. I still play. Played four times this week.
>> Robert Hess: Really? Even in this wet weather?
>> Terry Crowley: Actually, Seattle is the perfect temperature for it. You can play year-round.
>> Robert Hess: Is it like a tackle style game?
>> Terry Crowley: No.
>> Robert Hess: You're talking about parking lot.

>> Terry Crowley: No, there's no contact. There's something called spirit of the game. You don't foul intentionally, you don't do something that's likely to injure someone. So it's very different than other sports. Even at the highest levels, it's self-refereed. There's no referees. You call your own fouls. And you know, you have interesting --
>> Robert Hess: Obviously it's not a professional sport.
>> Terry Crowley: Yeah, right. Well, you have interesting things where you have these very high level, the finals and nationals and the crowd will be surrounded and somebody will make a foul call on field and the crowd will boo if they think it's the wrong. And the guy will go, okay, I'll take it back. It's this interaction with the crowd and this notion that you're supposed to be respectful of the other team, and it's a great sport. Great sport for kids. I coached my kids, two younger kids' middle school team and always working to make it a bigger sport.
>> Robert Hess: What other things do you do for fun besides programming and ultimate frisbee?
>> Terry Crowley: I ski, I do a lot of skiing. I have a 16-year-old son who has recently totally passed me and dominates me on the slope. But I like to do that.
I like to read a lot. And we have a place out at Lopez Island, and go out there.
>> Robert Hess: You mentioned a couple different sons. How many kids do you have?
>> Terry Crowley: I have a 16-year-old, a boy; a 14-year-old girl; and 11-yearold boy.
>> Robert Hess: So you're getting your start on the 14-kid family.
>> Terry Crowley: I'm done. Three is a good number.
>> Robert Hess: Now, you're saying that from experience of being a child of 14 kids, or just --
>> Terry Crowley: It was great growing up -- it wasn't -- you know, at the time there was all these -- cheaper by the dozen and it was never like that. It was much more -- it was normal.
>> Robert Hess: You weren't building volcanoes in your back patio.
>> Terry Crowley: No, it was pretty normal. I think one of the odd things, we only had two cars. That was back in the '60s and early '70s and you used to just pack kids into cars. You can't live like that anymore. You'd be arrested, going down the thing. You know, you have two people on the back, you know, how those cars used to have the back thing to lie on and you put two kids back there.
>> Robert Hess: Just start shoving them?
>> Terry Crowley: Exactly.
>> Robert Hess: Now, here at Microsoft a lot of people, especially when you've been here a while, you have a tendency to I suppose collect things in your office.

And when I stopped by your office chatting, I noticed you had a nice collection of things in your office. So we took a tour of your office and let's take a look at that.
>> Terry Crowley: Let's see. I have, right over here I have my -- a poster I got at the end of my BBN tenure career, showing all the different products and projects
I worked on, little snapshots from that. Let's see. Here we have a Buckaroo
Banzai cup, I'm a great Buckaroo Banzai fan. I'm not sure everybody knows what that is, but laugh while you can, monkey boy. There's a whole number of lines in that movie you can live your life by.
And famous boxing gloves after a -- this I was given to from a PM who I worked on with a number of features and we used to have long drag-out fights about the features and but in the end we respected each other.
I also, this is one -- this is the oldest book here and this is the Bell system technical journal, and it was the first combined journal about the Unix time sharing system, and my dad gave the introduction to this, and I grew up on Unix.
So big Unix background.
>> Robert Hess: Well, I think I saw at least one frisbee in that office. I'm sure you had a few more.
>> Terry Crowley: Five of them.
>> Robert Hess: Now, before we pass over to the audience, get some direct questions from them that you're going to answer. We have a few questions we like asking all of our guests and see how they respond to it. Don't worry, it's not a test. There are no right or wrong answers.
>> Terry Crowley: I like tests.
>> Robert Hess: The first question is, what advice do you have for people in your field?
>> Terry Crowley: I would say one of the things that I've seen, if you look at people who have been sort of very successful, I think one thing you see as a pattern is that they're folks that have become experts in some area. They've become -- or the expert. You know, whether it's the expert in the way Word works or the Excel calc engine or the various other parts of our systems. That you need to get a deep, deep expertise in some area.
And so I think actually DEVs have a tendency stay in one area very long and my career shows -- I was at BBN for ten, and -- but if you don't get that deep expertise, I think you don't get the respect from the people you need to be successful. And I think also you learn something when you go deep, about the design of systems and how to construct systems, that you can't get from just sort of a surface knowledge.
So become an expert at something, I guess. Is important. You know, I think another sort of take on that is also that in virtually anything you work on, if you're

not sort of successful in that, you know, every once in a while you hear somebody saying it wasn't a good opportunity, or it wasn't interesting or it was a boring task. And certainly what I've discovered through my career is actually some of the boring tasks are the ones that end up being the most interesting ones. Because you say if I'm going to work on this I better have come up to an interesting solution to this boring problem.
And sort of lots of examples where you end up doing some of the funnest stuff on a problem that initially looked like it was uninteresting.
>> Robert Hess: For me, I would really like string parsing. And that sounds really boring, but I like get figuring out those equations and figuring things out from that standpoint. Owning the problem.
>> Terry Crowley: Yeah.
>> Robert Hess: So how would you describe your work to someone who is not technical?
>> Terry Crowley: Well, I'd say first of all I have somewhat easier job in the sense that working on office sort of, people sort of understand what Office is. So there's a certain familiarity with that. So that's -- that makes my -- describing at least the position I have as easier. Of course, the other reaction you get is they say you mean you're doing another version? Actually, you get -- two versions.
One is aren't you done? And then another reaction you get is please tell me you're not done, you know. There's definitely -- there's people who see opportunity for improvement.
And we see lots of opportunity for improvement. So at least in terms of what generally what I do, it's pretty easy to get that. Because office is pretty well known.
>> Robert Hess: People know your work on office and every time they call you, they end the call off with, oh and by the way, how do I --
>> Terry Crowley: I do. Yes, you get a little technical support. I get those from my family every once in a while.
>> Robert Hess: With that large family, it probably builds and builds.
>> Terry Crowley: Exactly.
>> Robert Hess: In life, what would you compare producing software to?
>> Terry Crowley: So I like to -- let's say, I would say building good software to architecture. You know, I think when you think about how to sort of modularize something and have it sort of broken up well, a program broken up well, then you can think about how sort of the good design of a house or something. I think architects maybe have it a little bit easier because boy, if you snake a cable through -- you know, you can do that in programming and it looks really ugly. It's a lot more obvious when it's architect doing something. Why don't we put a tree -

- you know, a tree -- or zip line down here. Maybe that's a little more obvious when you're designing.
>> Robert Hess: Or the gargoyle.
>> Terry Crowley: We do that in programs all the time, it's really bad.
I think the good programs are a beautiful thing. There's an aesthetic to programming that sort of matches, I think aesthetic of sort of designing a building. You have to -- if you don't have that aesthetic, you're willing to lump things on and I think you end up building complex fragile systems.
>> Robert Hess: Do you think an architecture shows through? In architects you're building, anybody walking by can see it. Whereas the architecture of office don't you have to see the codes to see how it's interacting?
>> Terry Crowley: There's certain -- but I'm relating it to the person who is deep in it. Who is involved in it, looking at it. But you're right, that is one of the advantages of architecture, that you can sort of -- it's laid out there, and I've always -- thought we need to do a better job of how do we visualize our programs. Just reading through flat listing is a difficult way to get a real understanding of whether it's been sort of broken up nicely, and we -- there's various research projects that have done work to think about how to explore sort of visualization of a complex system. But yeah, that is a sort of the one of the difficult things.
But I think the basic aesthetic of building a nice system and designing, building or whatever, feels similar to me. I've had roommates and others that are architects, and there seem to be similarities there.
>> Robert Hess: So finish this sentence: You know you're a computer nerd when...
>> Terry Crowley: When you're so excited by the algorithm or data structure you just designed that you go and tell your spouse about it and try to describe it to her. And then you find maybe I need to find somebody else to talk to about this.
But there's definitely been a number of times, this is so cool, I really want you to understand this.
>> Robert Hess: Doesn't quite work, right?
>> Terry Crowley: Doesn't take. My wife is a smart person, but she's not a computer programmer.
>> Robert Hess: Does she get much into computers, HTML?
>> Terry Crowley: Not HTML. She's very techie. Sort of new more techie with new devices she wants to jump on quickly, from that perspective.
>> Robert Hess: More of a technophile than techno enabler.

>> Terry Crowley: Yeah.
>> Robert Hess: So lastly, we ask everyone to draw and explain your favorite data structure. So we're going to give you the opportunity to check out your artistic skills.
>> Terry Crowley: Okay, which are very bad. So anybody who knows me would be stunned if I didn't pick a gap buffer as the thing. So I'm going to go ahead and do that. I'm going to pick a gap buffer. Gap buffer is a data structure that I first learned about in reading about the E-max, text editor, but it's usable in lots of other cases and has some interesting sort of characteristics. I'm sorry. My drawing here is goofy.
It's an interesting data structure from a number of perspectives. So here's my attempt at drawing gap buffer. So the idea is -- so of course one of the simplest data structures in computers is just an array, and so you start off with an array, and a common thing that people want to do is build an extensible array. So you allocate some large amount of data -- or some amount of data and let's call that sort of max line. But then you're only using a small amount of data, let's say
Lang, so these are the locations actually used.
The nice thing about the extensible ray is you can add new elements for constant cost or delete things at the end. So a generic extensible array, typically the gap is at the end. So a gap buffer basically takes the extensible array idea and says, well, gap can -- instead of having to be at the end of the array can actually be in the middle. So what this means is that as you want to do insertions or deletions you move the gap to that location and then you can do insertions and deletions basically in constant time at that point.
And so it's often used for E-max it was used for the text buffer so you -- where you're typing is where the gap is. And so typing and inserting and deleting around the gap is very easy.
The next thing about this data structure in terms of talking about data structures in general is a couple things. One is it's sort of super important -- it's all about locality. The performance of this data structure is all about sort of the locality of operation. And it turns out as we think about sort of memory hierarchies and the way that even the way that multicore is impacting things. That locality is just more and more important, in fact, in terms of designing, thinking about how our systems sort of architect and having good locality.
And then the other interesting thing about this is it's a very efficient data structure if you use it the way it's designed to be used. And it can be very inefficient if you don't do it that. And there are no perfect data structures. And knowing what the characteristics of the data structures are and knowing how to use them is actually pretty important.

And so the gap buffer is sort of a classic in that. It's great for what it's designed for. But if you try to misuse it, it can be bad for you.
So this is -- at the core of e-max and in fact FrontPage, if you look at FrontPage, data structures, gap buffer is all over the place. And I could go on for another hour talking about that.
>> Robert Hess: You preface this by saying anybody that knows you, if you didn't do a gap buffer -- why are you so known for gap buffer?
>> Terry Crowley: Well, this is -- you know, one thing about FrontPage, the -- I would say one cool idea I had with FrontPage, maybe you could come up with few other cool ideas, but was this idea that how do I manage selection in a complex system, selection as in what area is selected to operate on.
And then in particular, in a tree-based system, selection is typically handled by a list of pointers to nodes and elements in the tree. And that can be very awkward and fragile in terms of as the system gets bigger and more complex.
So the design of FrontPage was the notion that you stick sort of sentinel characters in the underlying text buffer and then you can use selections on the text buffer as the sort of core selection object that can be used throughout the system and its real estate very robust performance -- sort of underlying selection model. And so I always made that big point, that was the very sort of cool aspect of the design there.
>> Robert Hess: It seems like you really own this data structure there.
So before we go into asking the audience questions, go ahead and sign this for us, make that permanent.
>> Terry Crowley: Okay. Typically you can't read my signature, so I tried to do a good job.
>> Robert Hess: That means you're that's not your signature, you're trying to say.
Now we're ready to open up for questions from the audience. Does anybody in the audience have questions for Terry?
>> Question: What is one of the most challenging problems you've had to solve and how did you solve it?
>> Terry Crowley: It was a really scary problem I had to solve and maybe I'll pick that, just because it was an interesting technical problem but it was sort of -- it was scary from a professional perspective. Because when I was working
FrontPage 98, I had just -- we had shipped FrontPage 97 and then I had then worked to deliver the MacIntosh version while the rest of the team went on to
FrontPage 98. And so I joined the 98 team a little bit later from the other

development -- the rest of the development team, and -- but that didn't prevent me from ripping up the entire core of the editor design service, and sort of throwing it up in the air -- I think I went three weeks without compiling because I was rewriting everything. And then I was actually several weeks past -- the rest of the team was code complete and things weren't coming together. I had this design for the display surface and the data structures and the internal data structures that I was having a tough time sort of getting to sort of working state.
And so I remember I worked like every single day for 12-hour days, 16-hour days, in that April trying to get it going. And I went home to have dinner with my family one night and on the way back I had this insight I was going to back off of what I was trying to accomplish, in terms of the complexity of that data structure, and I was going to take a simpler approach. I proceeded over the next two hours to code that up. Fix the couple compilers and one bug. And had it working that evening. And that's what we ended up shipping FP 98. And then in FrontPage
2000, I ended up sort of finishing that full design I was looking for and doing it.
So that was really the point where sort of in contrast to BBN, where there was like five of us working on it and the project -- product maybe had 15,000 users.
This was -- you know, FrontPage, there was a lot of people working on the product, and if I screwed it up, it was a big screw-up. So that was --
>> Robert Hess: You wouldn't be here today.
>> Terry Crowley: I wouldn't be here today. So that was scary.
>> Question: Microsoft is famous for having challenges in its cross group and cross division collaboration on software. Can you tell us about one of the challenges you've worked through and how you managed to get through it?
>> Terry Crowley: Okay, that's an interesting question. I think one interesting experience we had was around sort of the FrontPage design service and the relationship with visual studio. For a long time, Visual Studio was pushing the
Trident-based surface, and FrontPage went down a path that said we're going to sort of own our own core surface. And there was a lot of sort of interesting discussion back and forth about what the right strategy there was.
And back in 2002, we worked -- and this was driven by Harley R who worked for me at that time, we worked through with the Visual Studio team in terms of them understanding what our technology was and what we could deliver into their product, and essentially drove an agreement where we took the FrontPage design surface and delivered it as part of the expression product and then also into the Visual Studio product.
And I think that was -- it was a long process of getting to the point where there was agreement that that was the right direction to go. And part of it was developing the technology internally, in FrontPage, that really addressed the requirements. But it involved getting people on their team that thought it was the right thing, and getting them sold on it. And there needed to be internal drivers

there on their side as well as folks on our side who saw the value in working together.
So that was -- it was critical to get the people sold on it, and then -- but also to have the technology, the right technology choice there.
>> Robert Hess: Now, cross group interaction like that can be extremely important in a company the size of Microsoft. Did you take learnings from that and apply those to other similar type problems you might have been later on?
>> Terry Crowley: I think one of the things we've seen is the importance of knowing the people and getting to know the people. I had a great opportunity in working with this multicore virtual task force, people from around the company, and that was a great opportunity for me to really get a chance to know those people and work with them on some technical problems and I think when you sort of develop those relationships, it makes it a lot easier when you're going in had where you have some issue, some product issues, or product decision to make, to based on -- if you can go in based on having a mutual respect for the people you're working with, it ends up being a lot easier.
So those relationships are a big part of being successful.
>> Robert Hess: Quite often you'll hear it explained to people, to understand
Microsoft you almost have to envision it being like Silicon Valley but up in the
Pacific Northwest. All those companies out there, and we are not just one big company. We're a company of companies. And so quite often the conversations don't always flow as smoothly as might expect otherwise.
>> Terry Crowley: Yeah, I think one -- it's funny when you read a news article that talks about Microsoft decided this, or Microsoft decided that. And I'm going, there is no person named Microsoft. There's lots of individuals. And we had actually an interesting sort of learning when we first joined as FrontPage, we were very lucky because Chris Peters who had been the head of Office, took over and took over to become head of FrontPage. So went from leading a team of 1500 or so people to 40 people. But he was incredibly insightful. And one of the things as we went through the first process where we go through the triage process, where we go through and make decisions about which bugs to fix and how to fix them and whether or not to fix them. And one of the things that he pointed out there was, you know, it's the decisions you're making in this room with three people the DEV, a test, and program manager, about these, that end up being Microsoft. This is what Microsoft decided. Well, it was three people in a room trying to make the best decision they could for the product, for the user.
And that's where some of these key, key decisions are made.
>> Robert Hess: Thank you, Terry, from the Techno Community Network for being our guest, and thanks to the audience for coming by.
(Applause)