"The technology that you teach to your students may be state-of-the-art — the cutting edge of state-of-the-art — but by the time they hit the job market, that technology is obsolete. That's the world that we live in; you just have to learn to deal with that. The attitudes that you inspire in your kids are going to be with them forever. If you teach them to adapt and to look beyond what everybody knows, then you have a kid who has the potential to do something major." —Jim Starkey
Database architect Jim Starkey, an innovator who was working in computer science right at the cusp of the adoption of the Internet, spoke at the STEM² Summit about pioneering special database technology through InterBase, lessons he learned along the way, and how educators can prepare their students for the next tech disruption.
In this transcript of his talk at the Summit, you'll read about:
- His career in database innovation
- How he utilized higher-order thinking throughout his career
- Four lessons about innovating in seemingly-impossible circumstances
Scott Morrison: All right folks, we'll get started. Thank you so much for joining us today. Second presentation of the morning, we have James Starkey with us.
Jim is a pioneer in Internet database technology. Jim grew up in River Forest, Ill., where he began programming in high school through a project with the Illinois College of Technology, and he earned a degree of math from the University of Wisconsin with highest honors. His 40-year career in software engineering has focused on the intersection of networks, databases, and data-access languages. He specialized in discovering the flaws in conventional wisdom.
In 1977, he created Datatrieve, demonstrating that the IT department need not have a monopoly on creating applications that store, analyze, and report on data. His work in databases show that relational systems are not inherently slow and that data consistency does not require readers and writers to block each other's work. More recently, he invented a new programming model for applications running on dozens of corporate and computers. He built a distributed relational database on that model which is consistent, partition-resistant, and available. Mr. Starkey holds several related patents. Let's welcome him with a round of applause.
Jim Starkey: Thank you. Thank you. It's a pleasure to be here. Two small things of a personal note.
The first in the previous presentation, there was a picture of Ernest Hemingway and a big fish. Ernest Hemingway went to my high school, so that's one.
The other is that it's a real honor to be here in the Kennels and science center. The last time I was in something called the Kennels, and it was Kennels' personal conference room in Maynard, at Deck. I'm an old Deck guy.
Twenty minutes is not much time. What I'm going to try to do is look at one innovation that I have done, of many. I'm going to skip through it very fast, because this is about two semesters’ worth of computer science which you are going to be forced to learn in five minutes. You can then forget it the second five minutes. I'm going to talk a little about the process of innovation at least from my experience.
This is what I do: I create technology, start a company, take a product to market, generally I get bought by a big company, go off, suffer through a non-compete, and then repeat. I'm on my third cycle right now.
Database systems — you've all heard of database systems. They exist to manage current access to volatile data. Duh. Everybody knows that.
Take, as an example, an ATM . There's some problems which are kind of obvious. Everybody who looks at one probably has the same problems going through their mind. What happens when you're moving money from a savings account to a checking account and the machine crashes. Do I lose my money? The second problem: What happens when I'm transferring money and they're trying to print my statement, does it come out wrong? Is it going to be confused?
The database solution is a concept of a transaction where you batch a bunch of updates in one unit. It's atomic — it either happens or it doesn't happen. If you're moving money from one account to another and it crashes in the middle, and machines crash we all know that, either it all happens or none of it happens. This concept of a transaction. A transaction also makes a database consistent and sees a stable view of the database.
Then of course this one, and everybody has thought of this: What keeps you from getting all of your friends at a different ATM in the city, and then somebody yells, “Go!” and you all take out the last $100 and head off to South America with your ill-gotten gains. Of course that doesn't work; the question is how do you make that work? How do you keep them from doing that?
The high-level view is contractions, transactions, control access to records so more than one guy can't modify the same record without bumping into each other. The traditional implementation of what are called software locks. They're objects inside of a database system, and a lock can be unlocked — you can have a shared lock, any number of guys can have a shared lock, and you can have an exclusive lock so only one guy has access to that record. The traditional implementation is that when a transaction is running, everything that that transaction touches, if it reads it, it gets a read lock; if it writes it, it gets a write lock. And this keeps two transactions from bumping into each other and doing inconsistent updates.
The problem with the traditional implementation is that, of course, people who are reading the database will block people who are writing the database. People who are writing the database will keep/block people from reading the database. This was fine back when we had batch systems, but when we started to have things like faxes and departmental stuff and interactive stuff, we started running into a really big problem. The ultimate nightmare is that somebody prints a list of all the employees in the company and goes to lunch — or worse, goes on vacation — leaving all of those records locked, and everything in the company grinds to a halt, because all of these records are locked and nobody else can run any transactions.
That was the problem. To get around it — and this was back around 1982, looking at this — I came up with this idea. I was driving down Route 3 and said, "I know how to handle this," and that is rather than using record locks, what we're going to do is create multiple versions of records. They're linked together, and we'll tag each one with the transaction that created that version, and then we'll do the bookkeeping to see who should see what. If you try to update a record, you have to make sure that's the most recent version otherwise that you can't. It completely manages a database system which is completely consistent and concurrent without having to tie up the database system. If two people try and take out the last $100, one of them will wait until the other one completes. Sorry, you missed it.
It's a really interesting technology. It has no record locks — nobody's blocked. Two guys try to update the same record, one wins, one loses. I introduced it in 1984 in a product put out at Deck internally. It was called JRD, which is Jim's Relational Database. I'm Jim. And shipped it. It worked fine. It worked fine.
The operating system that it ran kind of went away eventually. When I introduced it, there was a lot of skepticism on the part of other database developers: This isn't something they've been taught. This isn't something they used. This isn't something that everybody else knew about. The academics were extremely skeptical. They said, "Ugh, that's silly; that's not the way that's done; this is all wrong."
That was a long time ago. Thirty years later, now it's virtually in all major database systems. It's a different technique; it solves the problem; the solution is completely different from the solutions that preceded it.
Let me draw a couple of lessons from this. First — and this is really, really important — not everything that everybody knows is true. There's a lot of stuff that's folklore — common knowledge. It's just wrong. Much of innovation is sorting out the stuff that everybody knows that's true, and that which isn't true, and digging down the rat holes between the stuff that everybody knows is wrong and seeing if there are solutions to problems there that have been completely overlooked.
Thinking about this process, this goes back to a very similar experience I had when I was in kindergarten. William [Hatch] School, Know Park, Illinois. I don't remember the name of my kindergarten teacher, but I wish I did. I remember the day very clearly when in the kindergarten room, she's sitting in the chair, all the kids are sitting on the floor around her, and she says, "Why do ships float?" We said, "Everybody knows why that is: Because they're made out of wood." She said, "Some ships are made out of steel, and they float." We said, "Yeah, but that's different; that's because they're full of air." She said, "Well, submarines are full of air, and they sink." Oh. Hmm.
I don't remember how far she went into Archimedes' principle. I'm quite sure she didn't go into center of buoyancy and center of gravity of the boat. What really struck me to this day: that huh. We all knew why ships floated — or we thought we did — and we didn't. What's going on here?
Same teacher; same circumstances. She must have done this regularly. We were all sitting around and she said, "Okay, who knows what the word ‘unique’ means?"
Everybody knew what the word “unique” was. This was the dark ages, guys, but we still had TV sets. They were little TV sets — we're talking probably talking 1955, 1954. We'd watched enough TV that we know that “unique” means it tastes good, or it's really great, or it's wonderful. [...] Yeah, we were so sure what the word meant, because we used it all the time. We'd seen it. And that was not what the word meant.
The third one is even more complex. We are doing a unit on airplanes. Not very much depth. No Bernoulli versus Newton. She said, "Why is Orville Wright lying on the wing?" This time we had enough sense to say, "I don't know." Maybe they hadn't invented chairs, but I don't think that's likely. There's a pattern here. When you are confronted with something maybe you, you're quite sure you know the answer to, maybe you don't really know the answer.
Okay, a little personal history. My introduction to computers as high school freshman. Local college, Illinois Institute of Technology, had an NSF-funded program to teach FORTRAN to high school kiddies on weekends. Three weekends in FORTRAN, signed up for it, and I was enamored with computers. That hasn't ended.
That was my first. The second was, my sophomore year, my high school started a computer programming course in 1964. This was a little early; the school didn't have a computer, but we had access at IIT. I was in the first time they gave it, and the kids in the class really became the core of the Follow 1 program at IIT. We had a pamphlet that explained how computers were supposed to work, and I turned that into a computer language and did an implementation for the computing course. Then I had the very weird experience of being a high school sophomore/junior having a language I invented being taught at college. I said, "This is weird. This is not they way the world's supposed to work." Maybe there's nothing here.
[college]
That's me in 1974. Now there's a couple of things. My hair's a little bit longer. It was a little darker at that point. This thing here, this is the state of the art of home computing in 1974. That is a Model 33 Teletype. It went at the outrageous speed of 10 characters a second. 110 mod. Talking to a two-stick coupler that would dial into the ARPANET, which was the precursor of the Internet back when it had 47 computers on it. This is the equivalent of, say, a millisecond after the Big Bang, but nobody knew there was a Big Bang because we didn't have any idea where the ARPANET or Internet was going to go.
The second lesson I picked up along the way is that possibilities are never zero, one, and infinity. Something may be impossible. Things that are impossible exist, and sometimes we have to recognize them eventually — that there isn't a solution to that problem. Generally, if there's one possibility, one solution for something, there are going to be an infinite number of solutions. You need to explore all of them. There's nothing that works where there's only one way to do it.
Lesson 2A is the cardinal sin of engineering : to fall in love with your first idea. This is where all bad design comes from, and we all know lots of bad design. Most engineers, most innovators think about a hard problem, they come up with a solution, and say, “Wow, this is great; this actually solves it; this is wonderful,” and just rush into it and start implementing. This is how we have record locking in database systems rather than multiple generations of records.
You have to be — if you're going to be an innovator — you have to thoroughly understand your subject matter deeply and profoundly.
Secondly, you have to have lots of ideas. That comes with experience and practice.
You also have to be your own critic. You have to be your own serious, dedicated critic, because ideas are cheap. Sorting through which ones are okay and which ones are great is really the essence of good innovation. You just can't fall in love with your first idea.
Lesson Number 3, and this is one that's — until you've actually been out in the world innovating in a serious sort of way, it seems kind of superficial —but this is important. That is: Innovation isn't normally welcomed. When you have a good idea, it's likely to be disruptive, and everybody isn't going to say, "Hey, that's really cool; you found a new way to do database systems." They're going to say, "Aw, come on; nobody does it that way."
Innovation is disruptive. You are changing the status quo. Any serious piece of innovation is challenging the existing order. You have to experience, anticipate, and deal with pushback. Really thick skin is important. When something works and it's generally accepted, then you become a hero. Then you have grey hair.
Lesson Number 4 — this is important for you guys as teachers: Innovation requires skepticism. You say, "Fine, I don't really know how ships float; we'll figure that out." If you tell somebody something is fact and you've got a little creativity, the kid is going to say, "Well, how do you know that's really true?" You really can't do innovation without questioning everything you see. That can be really annoying. I know, because I've been on the annoyer end of this many times, and not all of my teachers really liked that. Some of them loved it, but not all of them. Like innovation, innovators can be disruptive.
Given the short period of time, I'd like to take three weeks and teach you all about concurrency control. Here's what I think is the takeaway: That is, the technology that you teach to your students may be state-of-the-art — the cutting edge of state-of-the-art — but by the time they hit the job market, that technology is obsolete. That's the world that we live in; you just have to learn to deal with that. The attitudes that you inspire in your kids are going to be with them forever. If you teach them to adapt and to look beyond what everybody knows, then you have a kid who has the potential to do something major.
Questions?
Audience member: Yeah, how would you recommend teaching kids at an early age — elementary, even middle school, high school — how to program? How to get them thinking in that sort of down the road, to prepare them to be programmers?
Starkey: I don't have any idea at all. For me, personally, programming is very, very close to pure mathematics. It has more in common with theorem-proving than it does with anything else. You're laying out the control flow and trying to get this really malicious machine to bend to your will.
In terms of picking up programming skills, I don't think it's important at all. Around 1900, somebody did an economic survey and looked at trends and discovered, by 1920, every man, woman, and child on earth is going to be a telephone operator because telephones... It's time to invent the dial telephone so we can have automatic switching so we don't need Mabel.
If you looked at this 15 years ago, you'd discover that every man, woman, and child on earth in 15 years was going to have to be a C++ programmer. That didn't happen for a bunch of reasons. Programming is in computers that are now ubiquitous. You need people who know how to deal with them.
It's really not the programming skill that's the essential part. That can be taught; that can be picked up at any time. It's being able to look at a problem, figure out what the real problem behind the apparent problem is, and deciding what needs to be solved and where the resources should go and that sort of thing. I would say, talking off the top of my head, I wouldn't worry about teaching programming per se. The thought process is important; the actual skill isn't.
Morrison: I have a question for you. I feel as though you've teased us. You were at sort of like the dawn of civilization. You were at the dawn of the internet.
Starkey: Yes.
Morrison: You talked about the ARPANET, right, and can you explain a little bit more about what ARPANET means — what the word actually means? It's just fascinating to sit in the audience and to think that you were there when the first, I think you said, 46 computers were connected, and nowadays, we're on our phone, we're on the Internet, and it's not even a thought anymore, and you were literally there at the dawn of it, so I feel as though you have to tell that story a little bit, because that's fascinating.
Starkey: I'll be happy to talk about that, but let me start by saying that, although we really liked the stuff we were working on, nobody who was working on it had any idea that it would go from 40 computers to 3 1/2 billion and basically tie up together almost everybody on Earth who has access to electricity and cause dictators to be overthrown. This is just absolutely astonishing.
Okay. ARPA is the Advanced Research Project Agency of the Department of Defense. It's now called DARPA — they put “defense” in front of it so people can remember who's paying the bills. ARPA is an agency that was set up to fund basic computer-science research. They had a bunch of different projects spread around the country, and Connie and Blair Roberts, who was head of ARPA at the time, said, "Why don't we build a network that connects all of these guys so they can all communicate and they can all share ideas?"
To do that, they had to invent a very interesting technology which is now so pervasive that nobody thinks about it. When you are dealing with the telephone, you dial a number and it sets up a circuit — at least, it used to — sets up a circuit, an electrical connection going through all sorts of stuff from here to the guy you are talking to. That's called circuit switching.
What the ARPANET did was demonstrate what's called packet switching, and that is you've got computers that are linked by an ad-hoc set of wires, but everybody's not connected to everybody. When you want to send a message from Computer A to, say, the NORSAR tip — which is in Norway — rather than setting up a virtual connection to him, you had a packet of data, digital stuff, bits, and you send it off and you send it to the next guy, and he figured out who to send it to, and eventually it comes to the other end. This means you don't have to have wires from everybody to everybody. This is what's the Internet's based on. The packet switching is called IP, which is internet protocol, which is the machine-to-machine protocol.
The ARPANET only had eight bits of number-for-notes for the computers on the ARPANET. It had an intrinsic limit of about 255 computers, because you couldn't use zero. That was bigger than anybody had built a network. For a research network, that seemed just wildly large. What happened was this: The ARPANET worked like a charm. The computer science community loved it. I was working for a company in Cambridge, a computer corporation from [inaudible 24:36], which had this thing called data computer, where the network hit the disc with the software in between. That's when the picture was taken. I got into this rut about networks and data, and I've been in that rut ever since. It's worked out okay for me.
The military — who had actually paid for this thing — decided they wanted their own ARPANET themselves, but they didn't want the long-haired computer-science types on their network. They set up what they called a MILNET, which was exactly the same technology and was a mirror image of the ARPANET. Then, they found that not having the long-haired guys was boring. They said, “Okay, what are we going to do here?” You've got these two networks, they're sort of compatible, but you can't talk between them. The guys who invented the packet switching for ARPANET sat down and spent a couple of months thinking about this, and they said, “Okay, we're going to... We've come up with this idea called the Internetwork, which was a network of networks,” and they're going to call it “Internet.”
We had the ARPANET and we had the MILNET, and now we had a network of networks which was the Internet, and it went from 40 or 50 computers here and 40 or 50 computers there to the three billion that we have now. How these did — such a fantastic idea which went orders of magnitude beyond their imagination of where it could go, but it works. It was interesting, but we didn't know we were pioneers.
We would go, using email, especially in the early days at Deck. Email was great. We said, “It would be really nice if I could send email to my parents. No, that could never happen.” That's the way it goes.
Okay. I'm probably way over time. I'm sorry.
Morrison: You're good, we have five minutes actually. Question, Nicole, are you here?
Nicole: I want to address — get back to what this gentleman asked — because a lot of schools and teachers are being told teach the kids how to code. Code academy, this is coding, and I agree with you that it's more the logic that you're teaching, and you think you can teach that by learning how to operate a weaving loom. I agree that it's the logic, but you can also teach by learning programming. You can also teach that logic. A lot of these teachers — a lot of these schools — are being told you have to teach the kids how to program. Some schools are making it part of their core curriculum, that they have to include computer programming.
Starkey: I'm going to say this is way out of my depth. I have... Before I retired from my last company, I had this mandatory class that I gave once a week. I called it a master class. Everybody has to go. These were mostly seasoned — these were all seasoned professional engineers. Really top-tier guys. My last database system was so unlike everything else in the world that I decided I wasn't going to hire any database types, because I'd spend more time having to un-teach them than to teach them new tricks. For me personally, I was highly motivated, even trying to teach these high-level guys new tricks. There's just a lot of resistance, and I don't really know how to do that.
If I had to face 3rd or 4th grade, I'd melt down. I don't know. People used to say that computers are smarter than people, are dumber than people but smarter than programmers.
Morrison: Thinking skills last forever. Higher-level thinking, all the things that we've been talking about in this series as well. One of the things you talked about, Jim, was that you said one of your ideas came to you — the solution to a problem — while you were driving down Route 3. I would imagine that if Route 3 was the solution to everyone's problems, we'd have a lot more traffic on Route 3 than currently exists. If you could just — in about two minutes, because we have about 2 minutes of time — clearly it wasn't the drive down Route 3 maybe that led to the solution to the problem, but take us through your thinking process.
What are the thinking skills that have stayed with you throughout the years? What are those enduring core competencies that you learned in school or along the way that you still employ today, and I think that maybe touched a little upon what you're asking. Enduring core competencies in your thinking process. Take about two minutes.
Starkey: Most of the time, I'll flatter myself and say I tend to come up with what strikes me as a good idea every two, -three years, and then what the world thinks but they don't count in the grand scheme. They come to me suddenly. The idea for the technology in my last database company — which was kind of neat, because you're got a database system that runs on a bunch of computers, you want to make it faster, you just plug another computer into it, which is not the way things normally work.
That one is, I was working for a company [...] which had bought my previous company, and I was getting pretty tired of arguing with these guys, open-source guys. I said, “Okay,” so I went in to take a shower one Sunday morning, and I'm just thinking, How am I going to get myself out of here, I'm really bored and I don't think I'm making the...I'm not excited about what I'm doing.
All I really know how to do is start database companies, and why would the world need another database company, for God's sakes? There are an endless number of database companies. I started thinking about why the world might need another database company.
Oh my God, I just had this great idea. A completely different way to build a database system — a complete break from everything that's been done in the past.
I went through a lot of hot water. I came out of the shower and I told my wife, "I just reinvented the whole database world." She said, "Oh, that's nice."
I'm afraid that's fairly typical. If I have a problem I have to solve, a technical problem — the last database company there were 40 or 50 of them, what I tend to do is first clear my mind of other things. Think about it with a blank pad of paper. Having a notion to look at seems to work for me.
Staring out, looking at the water, starting companies sometimes has its benefits, and trying to keep my mind, going through possibilities and one of them will stick to the wall. If it's a really hard problem, I do something; I tell other people to do this, and that is come up with any solution, even a bad solution. Once you have an existence — proof that there is a solution — then it's just a question of coming up with a better one. Forcing it, getting it to an existence, proof for an idea, and then taking the time and thinking about it some more. Once you have something that does work, making something that's better is a lot easier. That's the way that I do it.
Morrison: I think that's a great way to do it and it's a great way to close. To me, it almost seems like it's the rough draft of a solution. If you think of the writing process in school, you have a draft of something, and when you work it through to its final copy. I think just getting a solution and having a rough draft of a solution is a great way to start.
Thank you for your time. A round of applause for Jim, please.
Starkey: Thank you.
Images courtsey of the speaker and their LinkedIn profile.
KnowAtom is a founding partner in STEM².
