Pang: How did your relationship with Apple work? Did you seen them very often when you were working at this stage, did they have to approve things at regular points, or was there was more autonomy?
Yurchenco: There was a lot of autonomy. I can't remember very much review at all from Apple on this. I think what we eventually did was, we delivered prototypes, and if they worked they were happy, but the day-to-day, and the design decisions that were being made-- there was kind of a spec, but I can't remember ever seeing a fully written-out spec at that point. [Pang laughs] Although that's not so-- you laugh, but even today-- Apple was barely more than a startup at that point, and even today we do a lot of projects that don't have any specs, there's just lots of arm-waving and agreements at meetings, and then you argue later what you said, but writing specs takes too long in this industry, you gotta get too many people on board and make too many decisions with not enough data.
Sun: We have a philosophy around that as well. You can build a prototype, and show it to people, and get them to respond to you. Before you do that, they're telling you what they want: they say, "Well, can you build this and this and this for me." And you write that down on a piece of paper, and that's the beginning of the spec. You come back to them, and you show it to them, and they say, "That's what I asked for, but that's not what I want." That's because you can't sit there and visualize-- out of nothing-- the future.
Yurchenco: Most people can't.
Sun: You need to touch and feel something. You need a this, and a that, and you say, "Can I have this but not that," and people can start to put it together, and people can start to do that. The point I'm getting at is that rather than sitting around and writing specifications we'd rather build things and get these things in front of us, and have the interaction that way.
Yurchenco: Be that as it may, there are still some things you have to establish up front in terms of goals. [Holds up mouse] The resolution of the thing, because that drives a whole bunch of engineering. How many pulses per inch of travel this thing puts out, what the operating conditions are, will it fit in one hand or two hands, will it have one button or three buttons? The designer, me, sitting down here with a piece of paper, has to have a decision on these kinds of things, because it affects what I draw on the piece of paper. So there's always a tension between the approach of keeping things free and open and just sort of build things and showing them to people, and getting things nailed down so you can move ahead on the process.
Sun: Right, right. Clearly that resolution issue was-- there was a model set with the Xerox mouse already, so that gave us something to work with.... I worked at H-P on precision encoders. This was a low-precision encoder, and H-P was making a high-precision encoder, and transferring the technology involved understanding the limitations particularly of the molding, what the minimum window size was that we could reliably mold, and that would translate into resolution for the mouse.
Pang: How complex a project was this compared to some of the other work that Hovey-Kelley had done for Apple? I know there had been some work on the Apple III, for example-- Jim Sachs talked about working on a reset switch, for example--
Yurchenco: [laughs] That was-- he's poking at Kelley. Kelley actually did draw a key cap at one point, and it's become company legend, because it's just about the only thing he ever drew! David's an organizer, he's a social engineer.
But I would say that this was probably up there, in terms of the kinds of projects were doing at that time, because we had a lot more responsibility here in terms of, they basically handed it to us and said, "We need this, go do it." So we had to start from scratch, basically, figuring out what it was, and looking at what other example we could find, and taking it all the way through to looking for vendors and working with vendors to get the parts done. So in some ways it was the most involved project we had had up to that period time. Certainly as an application of technology, where we're integrating the electronics ourselves, it was. We didn't do the software, but Jim did the circuit drawings, and he actually did the boards, here's one of the prototype boards [holds up board], it says H-K right there on the corner.....
We were cheeky. A client would come in, and ask if we could do something, and we always said yes whether we had a clue or not, it was just, "Sure! We can do that!" Fortunately, at least from the Valley, the clients were were attracting those days knew even less than we did, so they were in no position to... see if we were telling the truth. And our attitude was, "Maybe we don't know this right now, but we can sure as Hell learn it, we're smart guys, we can go figure this out."
And it worked. We never hesitated, if we didn't know something we'd find someone and pick their brains or they'd consult for us, tell us what to do.
A lot of design I think just sort of-- I think really good design engineers, really good product designers, are just born this way. They're the kind of people who've tinkered all their lives, and they just know how things work. It's just part of their world view. And in a way you don't educate them, you just give them opportunities, give them more and more responsibility and more and more opportunities to do this stuff.
The technical tricks you learn, you pick up just by talking to people and looking at stuff and so forth. It's not something I'm convinced that engineering school has a lot of impact on. They'll teach you calculus and strength of materials and so for, and if you're a little drone designing a rivet for a 747, that's probably pretty important. But if you're in this business, where you get to design a whole product, I think you have to think broader than that. And for the people who are really successful, it's intrinsic. They just know it.