Alright so you said when I met you before you knew the Altair was coming before the Popular Electronics hit the news stand. But still what did you think when you saw it in Harvard Square? Did it, did it sort of mark a new era in computing?

The key event was the microprocessor itself. The availability of a chip that included all the elements of a computer and we saw that in Electronics Magazine when I was still in tenth grade in high school and we discussed what that meant. And that's when we got excited about the fact that this meant computers could be purchased by individuals and used in a, in a different way. And we, we were surprised other people weren't expecting that and seeing that there was so much change. But it wasn't until three years later that the first ah, product came out using microprocessor and that was when I was a student at Harvard University and Paul Allen and I were walking through Harvard Square and saw the cover of Popular Electronics Magazine and even though it was nice because what we had predicted was happening our main reaction was that we better get going and get involved or else our whole vision was going to happen without us.

So did you have any sense when you decided okay we're going write software for this machine did you have any sense how big this industry would get?

Paul and I wrote down when we started the company that we felt there'd be a personal computer on every desk and in every home. So we thought of it even from the beginning as a very pervasive tool, as an information tool. And we felt that more and more software would just increase the number of tasks that the computer would help solve and so that we were at the most exciting part of, of this revolution that would be taking place.

So what was it like back then different from now let's say being a programmer? Were they sort of a different breed of people writing software for those machines?

The early personal computers were not very powerful so the idea of feeding their program into a small amount of memory requires immense skill. Our job was to put into a, a computer with only 4K of memory an entire basic full blown, floating point Basic and that's one of the greatest programming feats I've ever had a chance to work on. We had so much fun just squeezing it down and amazing people that such a thing could be done. The industry was very small in the seventies. People tended to know each other and I spent a lot of my time evangelizing that is going to large companies and convincing them they should make computers like this and then going around and helping user groups get started so that people who like the stuff could all get together and share their ideas and work together. So we had a feeling as an industry that we were, we knew something that other people didn't knew, know, and that it was very exciting and very important.

And time has proved you right.

Well the industry, the industry's changed a lot now. Most of the people who I worked with in those earlier days are, are no longer involved. Certainly the things we felt about the pervasiveness of the tool and the importance tool and all that has proven to be true.

What about who sort of has the power in the industry now? I mean you said back then you were going around evangelizing and asking different hardware makers make this hardware for me please. Do you think it's changed a little now? Are the people who are writing the software more in the driver's seat?

Well, from the beginning we felt that software was the key element that would determine how useable and how broadly applicable the machine was. So we focused on, on software from day 1. And we were actually the first microcomputer software company. In terms of revenue even today a higher percentage of the dollars are spent on hardware then software. Although that's been shifting, today's software sometimes as much as a third of what people spend. That greatly understates though the importance of software when it comes to opening up new things or deciding even which hardware you ought to buy, the software's the most important element. And some software companies including our own, Microsoft, have ended up being very profitable. They've created high volume hit type products. And so the focus of attention is shifted very much to the software industry not nearly as much as it will over the next ten years. I mean the... the center of, of exciting advances will be more and more on the software side.

But why is it more and more on the software side? Why is hardware being left behind?

The analogies that try and explain the role of software and hardware aren't perfect but the idea of TV industry versus TV programming is, is a good one or the printing industry versus the book industry and in those examples you can see that the richness of what software provides by making the machine valuable to, to different people, that's what's new, it's what people pay attention to and once they see a piece of software that can help them in business or home then they ask what hardware do they need to buy? And so the hardware's is almost like a record player. The one difference though is that hardware is continuing to improve so it's not, not static in that way and so we have to have close cooperation between the hardware manufacturer and the software developers so that we take advantage of the new things that are done on the hardware side. So it'll... it'll never be as extreme as say a record player but it's, it's the content. It's the experience is all defined by the software piece.

You're enabled by hardware that can run itself enough to, to give you to allow you to create a user illusion?

When you write a piece of software you assume a certain type of hardware. That's always a tough question. If you assume hardware that's too powerful then you can't sell many copies cause very few people have that machine. If you assume hardware that's too simple your product can't do as much. And so making that choice is one of the most important decisions that a software company makes. What hardware are the software packages targeted for?

We are interested in the comparison how is the software industry different from another industry, like Boeing or something where you create something physical. The differences between physical media and digital media? So for example how would you measure the size of the job creating a certain software product. What units do you use to quantify when it’s not a number of widgets or something like that? How do you guess how long it’s going to take to do a project?

Creating a... a piece of software is always complicated because you're doing something new. If you just wanted something that had been done before you'd just use that old piece of software. So there are no repetitive tasks. It means that it's very hard to estimate how hard it will be, and it's extremely difficult to add new people to a project because you don't get any benefit from the new people if you're having to explain to them what's going on and if their pieces don't fit in with the other pieces and so often our very small teams are by far the most productive. You don't want to impose external measures on on on the team because they, it's up to them how enthusiastic they are. If one piece is easier, one piece harder or they want to shift the design around you have to give them total flexibility if you want to get the right results. And yet you want to measure what's going on. Certainly you can, you can judge if you put smart people onto the task, are they working hard, but you still want to know when will they get done, should you cut back in terms of what you're asking them to do. And there is no science to it. It's ended up that some companies pull the right pieces together and, and succeed and a lot of companies don't.

So what accounts for the success when the projects do go well?

Most of the success of great software projects you can assign to picking great people to work on the project. People who are very smart, in a scientific sense, and who have a lot of energy and interest in what it is they're creating. And in any project review I can tell if people are tuned in to what's going on. If they've thought through the alternatives, if they're making the right choices, they've thought through what the problems are going to be or not. You can get a feeling whether it's a, ah, even say within Microsoft a relatively great project team or a, a team that needs to be livened up or given a less ambitious task.

What about the team I met with this morning, Chris Peter’s team? Are they unusual, they are getting a product out pretty much on schedule, is that a first?

Remind me when this airs, this stuff.

This airs next fall.

Next fall. That product will have been shipped long before that. Our Excel team, headed by Chris Peters is a fine example of a group where everything's come together in a perfect way. The team is smart, they're excited, the specification that we wrote has a lot of very new innovative features. Ones that we thought maybe we could do but there were breakthroughs along the way and new ideas came along and we were enough on top of things we could add those into the schedule and plus which these developers look at the competitive atmosphere and they can see that our graphical interface that that they're betting on is getting to be popular and Lotus is not getting its competitive product done very quickly. And so they sense the opportunity and it builds ah, even more excitement in that group that that they should get their thing done. The fact that we were able to pick the completion date several years in advance, ah, it's partly because we're, we put enough buffers in for a surprise but it's also a real milestone in the way we manage these projects. That's it's quite unusual even for us to know when something will get done in advance.

So I mean what did you do? Did you engineer it differently or you just lucked out with a good team?

No it's…

Is it more complicated?

Writing software, that's our, our life. I mean this — everyday we think about could we use a different tool? Could we organize things differently and there's a variety of things that we're doing in our projects now that are making it more predictable. One of those is that we have phases where we get a certain set of pieces done and test them before we move on to the next. The idea that you think you've got something done but ah, when you go to test it, certain problems of speed, or interactions come up, can often make you have to go back to work that you haven't looked at for quite some time. And so using this phased approach as... is one of the smart things we did with the Excel project.

Now they’re, I guess, in the last week of debugging, getting ready to finish it up. They’re having people play games and not play actually with the software I guess because they don’t, there’s sort of a risk with code, with the project, because it’s just code you can add a new feature. There’s no physical constraint that keeping you from adding a new feature, it’s not like the cement won’t dry in time. Is this a risk that you have to avoid, be careful to not have people play with the software product toward the end of a project?

When you develop software, the people who write the software, the developers are the key group but the testers also play an absolutely critical role. They're the ones who ah, write thousands and thousands of examples and make sure that it's going to work on all the different computers and printers and the different amounts of memory or networks that the software'11 be used in. That's a very hard job. As you get to the end of the project you want to run all the tests cases against one version and make sure that you know that that version passed everything. And so as you get late in the project you get a little more conservative about making radical changes to the software and finally in the last month where we are now you make sure that every change is examined by lots of the programmers so you don't get what we call a regression going backwards in terms of the reliability. This means that the, at the very end the testers are on the critical path. It's their testing that's hard because they're not finding enough bugs to keep the developers busy all the time and the developer's already thinking about the next version that they're going to get done.

And wanting to incorporate their new ideas in the current product. Right. I mean they're sort of itching to write to write in new features?

No they understand, I mean everybody's part of the same process.

Is this something that has been the result of some experiment, say here at Microsoft, where maybe in the early days it wasn’t as clear that when you make changes at the last minute they’re going to have unforeseen repercussions so you have to discipline people to not tinker with it at the end?

No I mean everybody always follows the rules. There's no, every project towards the end you do less stuff. I mean that's always been the case. The need for testing has gone up as the size of the products go up and as the, the number of machines you're going to run them on. So the scale, the scale of things changes but the basic principle, I mean is... is the same. Even when I wrote Basic myself the day before I burned it into a computer I wasn't making design changes. I didn't have a testing team. I did all the testing myself. And there was no project methodology or schedule that, there was the notion of coming to a close means testing a lot at the end and making very few changes.

Still sort of interested in the differences between physical and digital media. I mean with debugging, if you’re building something and you’ve got a leaky roof you know exactly where to look because the problems going to located near where it’s physically manifested. What about with software, how is that different?

Software is different than other products um, partly because it's, it's not physical and, and partly because of its complexity. You can express in software millions of different cases and making sure that you handle all of them correctly is extremely difficult. There are more inputs then you could possibly have time to step through. And knowing which test cases are worth going through and when you're ready to ship the thing is not a science. It's more of an art to that. Certain teams are more careful in what they write. They generate less bugs. You can know that but it still doesn't mean there might be there might not be one bug that would be bad to ship the product with. And so there's a whole body of knowledge being developed about how you do testing and some optimism that maybe the computer itself will be able to help in the testing process but not, not much going on practically with that right now. The other great thing about, about software though is that you can you can pick exactly when you want to come out with new versions. So you decide how ambitious you want to be. If you want to ship a new version in two years you're coming up with a specification that matches that that time schedule based on your experience of how long does it take to write it and test it and how good of a team do you have involved with the thing? And it's certainly exciting to have a product where you can update all of your users at very low cost. They don't have to go and buy a new car or anything. They can just substitute in the new disks or even just download it into their network and boom they have the new version. And so the old users get the benefits of your new ideas. That means that literally within a few weeks of shipping a new product you can have say a million people who are enjoying using it, getting onto bulletin boards and saying what they like, saying what they don't like. Sending in reports, building on top of it. Maybe enjoying their job more because of it and we get all that feedback and then we use that to decide how to do the next version. So it's possible to get closer to your users with this kind of product than, than with most other products and if you decide you wanted to get a new version out you know three or four months later you could do that too.

What about debugging as programs get increasingly long and more complex? Is it possible to ever really fully debug a program?

There's a famous debate about whether programs of a certain complexity can be debugged. This came up in the Strategic Defense Initiative where some people are saying that maybe the program that would control all the sensors looking at incoming missiles and then control the reaction of the missiles going up that even if the hardware was great that the software part you might not be able to trust it. /In the software industry people like myself are optimistic that by using the right tools and breaking things down into pieces that that problem could be solved. But it sort of suggests the state of the art that very smart people in the software field disagreed about whether that could be done or not./ So there's certainly some scale at which our current tools are inadequate. The trick generally is to break programs into pieces and have those pieces be individually testable and so then when you move on to the other pieces you treat it as a black box knowing that it either works or doesn't work. The same ideas apply in any type of engineering area, it's just that the interface, the boundary between one piece of the program and another keeping that simple, so you can think of it as a black box is very, very hard, it's part of doing very intelligent design is breaking things down in the right way.

So it's a matter of trying to make it less like the sort of virtual infinitely flexible media right? You want to try to emulate physical things you can wrap your mind around and think about how they would interact together. Trying to avoid too much complexity around it, for one mind to handle.

I don't know about the... the physical analogy. People, people are building the software and so having the pieces be such that a single person understands all the tradeoffs and everything that's going on in a piece is extremely valuable. It avoids getting into an experimental mode where you're just trying things out. That never works. And in any of our projects even though we may have as many as twenty or twenty-five people involved, for the major pieces we have one person we really trust who understands the speed and what it would take to do changes and who can look over all the changes made to that piece. So the idea of dividing it down so that people understand it really has to do with now what can you keep in your mind? What can you have a total understanding of? So it's almost a human limitation.

Are you talking about object oriented programming languages, are you talking about software modules?

There are a variety of techniques for breaking software down into pieces and making software development more efficient. Many of these techniques have been sort of… and everybody got excited about but very little benefit was actually derived once the thing was put into practice. Software is inherently complicated. If you say to somebody I want an airline reservation system, to really say what you want in terms of overbooking and fares, and different airlines communicating with each or schedule changes, it's immensely complex. And so you can't write a program that's any simpler than that full specification. In software what we're trying to do is make it so that just by describing that specification then that's the program. You don't have to do any special things besides state the problem in a very, very exact form. And there are ah, advances that are pushing us in that direction fairly slowly. Another trick in software is to avoid rewriting the software by using a piece that's already been written, so called component approach which the latest term for this in the most advanced form is what's called Object Oriented Programming and the strongest analogy is to think of writing a book. You don't go to other books and take little pieces because although say a romantic scene may have been many times before all the details of who it is, where it is, are so intertwined in that text that it's easier to write it from scratch and that's the way programming has been to date even though something like searching the table has been written millions of times. When we have a new program that involves searching the table, there are reasons why we don't grab that old code. Very, very similar to this idea of trying to take something from someone else's book. And the type of breakthrough we're looking for is where you separate out those details from the basic idea and so the basic pieces can be used again, and again and this is Object Oriented Programming.

… And Chris said that too. And I wonder why is it that programmers share that trait, why are they optimists?

So why are programmers optimists, or are they?

I think if you talk to the experts in any field where you have to take on a unknown challenge, where you're going to be working on it for a long time you'd find that to work themselves up to their best performance and really throw themselves into it, you know, spend all these hours in there and ah, give it their... give it their best that optimism plays a role. I mean if... if you had a group that was about to climb Everest and you said, do you guys think you'll make it to the top, and they said, well, we have to be realistic, you know, there's a good chance we'll... we'll buy, you might not ah, expect them to be the... the most energetic at pursuing the thing. So I think it's partly when you're world class and there is this level of uncertainty ah, you don't want to worry about it. You want to plunge ahead and have the probability of seeing breakthrough ideas, ah, that you hadn't anticipated, have yourself be as open-minded to that as possible, not just counting on the fact that you won't see a... a short-cut along the way.

But is there something also about the idea that you could, in theory, do anything in code, right? You're not limited by the tensile strength of the metal or what have you. Is that part of it?

When... when you program, you want to think you're writing the best possible program for the... for the task you're trying to solve. And even for the very best programmers ah, sometimes you'll see someone else's program or somebody will come along and they'll show you what can be done in a simpler way. And it kind of blows your mind to recognize, gosh, the possibilities of clever programming are so incredible. Ah, there are often ah, neat ways to do things. And good programmers stay open minded to that even though there is no obvious way to improve what they've done they... they keep looking and they listen to what other people have to say. That's why we have this concept of a lot of people looking at the code, reviewing the code to see if they have a better approach to it. And open-mindedness is very important. Ah, we... we can't mathematically ever prove ah, that we've gotten the best program.

So how do you motivate your software developers to get a project done? How do you make them optimistic about it or are they just born that way?

The most... the most important people is to pick people who like to write software and who are good at... good developers like working with each other. And they... they reinforce each other's skills. Ah, good developers like seeing their products sell in large quantities. They enjoy the competition of doing a better job than the other company, especially if the other company has more people on the project and they're entrenched and people are saying that we don't have a chance of getting in there and... and doing well. You have to view it as a mission. And build up a very high level of excitement. Make sure they know all the pieces of what... what you're doing and assign them a very ah, tough part of the job. For us that's meant you know, groups of about 15 people, who, early in the project go off, really talk through what's going to happen and spend an intense period of time working together. Ah, we try to set that to be around two years because anything more than that ah, you know, it's hard to see the end and if you have to course correct it's... it's a bit of a problem. But we need about that much time to do something that's so significant that users actually want to change what... what they have.

So it sounds like your most valuable resource is smart people who work together well. Is that a concern for you that someday you might not have enough people to write software? I mean Microsoft is growing pretty quickly. How do you get people into the company?

From the day Microsoft was started, the only constraint to our growth has been attracting ah, more great programmers, very smart, committed, ah, people. And so we're always on... on the look for ah, that kind of person. And over the years, you know, we've gotten to know the various college campuses, we've gone outside the United States, and pushed the immigration department absolutely to its limits in terms of letting us bring in ah, smart people from other countries. It's ah, of considerable interest to us, you know, where can we find ah, more of these world class developers. And it's been the key to our success that we've found ah, far more than our fair share.

If you were going to try to convince someone who you thought would be a good programmer, let's say someone who had never seen a computer, which is kind of hard to believe, but what would you tell them about writing software, to make them want to do that?

If you're smart, you often want a feedback loop so you know if what you've done is... is right. And ah, you know, you can adjust. In the pure sciences, of course, there is a concrete test of whether theories work or not, but ah, the frontiers are very far out there. The... the practical impact of those things is fairly limited. Urn, and so we can often attract people who were in a pure science, at least in school, to an area that requires the same precise thinking, and yet ah, has this impact that you can meet people who are using the software and they can tell you what's good or what's bad. And you can work with other very smart people and you know, show them, you know, do you have the... the right stuff to ah, do incredible software. And it's often somebody who's been involved in the sciences and likes the idea of a concrete test of ah, excellence, rather than just, you know, a very soft definition of what's right.

I just wanted to ask you in a different way about the project, the people on a project. If you're building an airplane and you're running behind schedule you put more people on a project. What would happen to you if you did that on a software product that was running behind schedule?

In software you can't really add people and expect to get more done, because their ability to understand the program and what's going on it would require so much investment and all their work would require so much review that you'd be more likely to slow things down. Ah, in...in programming when you're making a change you have to know all the affected places, and you have to be able to model in your head what the performance impact will be. And so we... when we start out with a team of a certain size, we can only increase it a small amount during the course of a project.

I read your speech that you gave at Convex. The buzzword for Microsoft is information at your fingertips, what do you mean by that?

The term, information at your fingertips, is to remind people what a broad role the personal computer will be playing. It's not a computation device, it's not a word processing or a spreadsheet device. It's a window onto the world of information. Anything that someone's interested in should be very, very easy to call up onto the screen. And in fact the computer over time will see what you're interested in and make that immediately available without your having to be give any commands at all. This includes not just text and numbers. Also pictures and sound. Um, information from outside a company like the news data or other people's prices. Or data of an educational nature, learning about the human body or movies or sports, should all be right there. And so that... that phrase is a challenge to the people in the industry ah, to come up with the software and data and networks um, that will make this a valuable tool literally for everyone.

That's a hardware problem too, though. I mean people have to have access — there are going to be lines between the information. How do you see that getting organized?

Lines? Oh, connections.

Yeah.

In order to fulfill this idea of... of information at your fingertips, we have to have not only a lot better software but also portable computers that you can write on, ah, big flat screens so that the wall of an office could display data and you could just point to it and see more detail. We need motion video and sound which current computers have very limited capabilities in those areas. The machines need to get faster. They need to get cheaper. One reason that we don't dwell on this though is that ah, those advances are predictable, they will absolutely come. Ah, just because chips get more powerful and the key technologies like storage and screen display, there's so much great work going on. The most open area is ah, how available will the information be? That is, how easy will it be for people to reach out and find what they're interested in?

And that's a software question?

Yeah, finding... finding information is either a software question or a question of how much information is online. For example in teaching students about all of history, you've got to make sure that you've found somebody who understands it very well, who put in the pictures and text and was financially motivated or somehow motivated to... to make all that data available.

We're looking at artificial reality as sort of the step from the 2D to the 3D interface. And in a way it seems like it's at the stage... the hardware right now is still not right there for it and it's still incredibly expensive to put on one of these demos. Is it analogous to where say someone like Englebart was back in the 1960s when he was trying to demonstrate the power of a 2D interface? Is that a fair analogy?

Yeah. What term are you using, virtual reality or artificial reality?

Virtual reality.

Virtual... virtual reality is at...at a very early stage. The demonstrations people do are... are very simple ah, scenes and the equipment is kind of unwieldy and a little expensive. However, it... it will develop fairly quickly. I don't think it will take the same, oh, 20 to 25 year period that using graphics on a computer screen took. Because we have the foundation. We have all these personal computers and software companies and ah, companies that build inexpensive chips that will attack this problem. So it... it might be ten years or maybe even fifteen years, but a lot of the things that you see in very specialized applications now, like flight simulation will become broadly available. Even if the hardware's expensive you can imagine an arcade that you go into and get to use ah, the equipment on a... on a temporary basis. The toughest problems are also software 'I problems. The idea of making it realistic, that you're walking around on the desert... See right now we're, it's so new to us the idea of walking around the 3D scene and just hitting a... a ball or something that very simple representations of what's going on are... are fascinating and they kind of grab us. But to make it an enduring phenomenon where you'd really find it fun, you'll have to have a lot of ah, physical things happening. And the software to make those things happen quickly and appear realistic, it's quite complex although there are... there are very smart people working on it.

Is that a field that you see Microsoft getting into?

Microsoft's role in... in this ah, will be fairly limited. Ah, we sell a flight simulator game. And as it becomes pervasive we may do some... some entertainment titles. But the ah, most of the interest comes from people thinking of walking through architectural models or travelling on the moon, or... or flight simulation. So our focus on improving access to information and work in the office doesn't directly overlap virtual reality.

What's the most important thing that you think has happened in personal computing since you joined the industry?

Well, there wasn't... there wasn't a personal computer industry before... I mean we didn't... it didn't happen. There wasn't... there wasn't... ah, wasn't an industry. The most important thing was the creation of a... a standard, where hundreds of companies build hardware that can all run the same software. The effect that's had on allowing software companies to write even obscure applications and be able to sell them in high volume and therefore, make money, is really incredible. It's a level of openness that allows people to switch their hardware without any change in the software whatsoever. And now we have over 60 million machines that can take the same diskette, plug it in and immediately ah, that that software's working. And so it's created the worldwide software industry that... that is so very competitive and moving so quickly.

Do you have any last thoughts for me on software engineering is other kinds of engineering?

No, soft... software is definitely engineering. It's different in that we take on novel tasks every time. It's not like building a certain bridge that is virtually identical to some previous bridge or some previous building. And the number of times those people make mistakes is very small. And first you think, well, what's wrong with us? Why you we miss our dates and sometimes it's too slow? It's because it's like we're building the first ah, skyscraper every time, or the first Verisano Bridge every time. And so we're having to invent the whole approaches of how pieces work together and see ah, limitations that you wouldn't... you wouldn't have expected because nobody has worked there before. So in the sense of... of doing very novel things ah, it's a tough area of engineering. Almost like the engineers work on space missions or creating all new things. They have certain approach ah, that they do duplicate systems and they test the systems, and a lot of that got ah, pioneered in the early space shots. Software will get to be somewhat more mature, ah, but it will never be as predictable as most areas of engineering.