The One Reason there's so much change in our society

This is a talk given at a startup incubation center. The audience was 20-somethings billionaire wannabees who yearn to follow in the steps of Uber, Air BnB, Pinterest, or some other unicorn. Most had no memory of life without cell phones, and some didn’t remember not having smart phones. I wanted to persuade them that the amazing opportunities that beckon them came from astounding advances in semiconductor technology and to warn them that very little has changed other than computers being bigger and faster.

------------------------------------

My parents were missionaries. I grew up in Japan right after WW II. I watched tightly-spaced lines of men and women carrying gravel in baskets on poles slung across their shoulders. That was the only way to fix the roads – their machinery had been destroyed. I watched the Japanese go from 3rd world in 1950 to challenging the US for economic supremacy in 1979, 30 years later. They did this through education and hard work. My brothers went to Japanese public school. We have a 180 day school year, theirs is 220 days. 8 am to 5 PM, a half-day on Saturday. The Internet is making high-grade education available to anyone with initiative. That’s the most important development of our time. Education brings change, though, so you have to be flexible.

Be flexible. On my way from Japan to MIT in 1963, my grandmother took me to a Western Electric plant and the manager showed me my first computer. One of the tape drives went into high-speed rewind! I loved it, took a freshman elective, and I’ve been earning a living in the computer business since June of 1964. My jumping on something new did me a lot of good. Technology changes so fast, you have no idea how you’ll make a living. You may work in areas you’ve never heard of. You may work in areas nobody’s heard of.

Not all new things work. I worked very hard writing a book about Artificial Intelligence because I wanted a new career. I consulted for Symbolics, LMI, and TI, all 3 of the major players in Artificial Intelligence at the time. The book made a good business card for a while, but didn’t lead anywhere.  AI didn’t create a new market. Some of the ideas worked well, but they ended up as mere software techniques.  I couldn’t hang my economic hat on AI because I was too early. Most new things go nowhere so you’ll have to try many things.

You have to flex because things will change. You must surf the wave of future shock. When I was growing up, most countries were fixing the damage of WW II. US manufacturers had essentially no competition and the US economy grew like crazy.  When I arrived at MIT in 1963, there were no Japanese cars on American roads and few foreign cars of any kind. There were very few cars in Japan, too. My parents didn’t have a car until after I’d left for college and I wasn’t used to cars – they move faster than bicycles.

I was hit by cars 3 times my freshman year, right there at 77 Mass Ave. The coming of the automobile separates pedestrians into two categories – the quick and the dead.  I wasn’t quick; I nearly got dead.

I graduated from MIT as we landed on the moon. Our economy was growing; our technology was out of this world. It was easy to get tech jobs. When I worked in Andover, just up 495, in 1984, we had to go to England to get 50 programmers. Our educational system has never, ever produced nearly enough software engineers.

You face a much more competitive environment than I did. As you know, the US faces intense economic competition from foreign countries. This has very little to do with technology. Did the Japanese take over the US auto market through improved technology? No, their technology was essentially the same, but they were much better organized and operated their manufacturing processes much more consistently because they sweat the small stuff better than we do.

Ford once had a joint venture with Mazda. They offered a model whose transmissions were made in a Ford plant and also in a Mazda plant. Before long, dealers were complaining that Mazda-made transmissions were very smooth and quiet and Ford’s were noisy and shifted roughly. Why? Because the Japanese machined parts to much tighter tolerances than the Americans did.

If you take a shaft at the high end of its tolerance range and put it in a hole at the low end of its range, it won’t spin smoothly. The Japanese kept much closer to ideal dimensions. This was a matter of culture and carefulness; it had nothing to do with technology. Technical change is easy, cultural change is very hard.

You face organizational competition. You face cultural competition – Asian culture has advantages over ours when it comes to mass production. We may be more inventive overall, but the Asians can grind it out.

You also face competition from political change. When I graduated, neither the Indian government nor the Chinese government let their citizens compete in the global economy. They walled themselves off.

Now, the Chinese compete with us in manufacturing and the Indians compete in software and call centers. You face two billion more competitors than I faced.

Our government has lost its mojo and is drowning us in regulations. When I watched the moon landing, I thought the stars were ours, but NASA gave them away.  Apollo was a “project,” something to be done once or a very few times. Project management requires a certain mind set. The shuttle was supposed to be a process, something to be done repeatedly and done often, that’s a totally different way of thinking. NASA never made the switch to a process culture. They kept herds of expensive engineers at mission control scopes to launch the shuttle. These guys had nothing to do most of the time because there weren’t many launches. Cost exploded!

I’m glad to see that the dead hand of government has backed off the space program a bit so that entrepreneurs like Space X and Virgin Galactic can take a crack. We may regain the stars for my grandchildren.

Let’s talk robots. Robots have been used in manufacturing for 50 years if you count automatic machines controlled by relays.  If you widen your definition and include programmable machinery, the Jacquard loom was invented in 1801. A series of punched cards had holes which told the machine which threads to pull up to weave patterns in cloth. Weaving a portrait of Mr. Jacquard required 24,000 cards. Mr. Babbage owned one of these portraits, and it inspired him to try to develop his analytical engine. So in a sense, programmable “robots” are more than 100 years old. Punch cards are enough to control simple processes, but more complex processes like having a robot walk need subtler control.

Let’s talk control. “Process control” meant punch cards, then relays, now computers. My first programming language was FORTRAN. Not Fortran II, not Fortran IV, or Fortran ’67, just Fortran, no qualifying adjectives. My first computer was in the basement of MIT’s Building 1, it had 28K words. That’s K for Kilo, not G for giga or even M for mega, just K, kilo. When we built the Apollo rocket, the astronauts didn’t want a computer flying them. “We got the right stuff!” they told us. “We can fly anything! Just give us a joystick.”

Trouble was, they couldn’t. We did a lot of simulations and they simply could not fly the rocket – human reflexes are too slow. Unfortunately, that meant that more and more functions had to be put in the computer. Ever hear of “feature creep?” The tendency of computer systems to accumulate so many features they can’t get done on time? The Apollo Guidance Computer was an early example.

The AGC was a giant exercise in feature creep because the closer we got to lift off, the more help the astronauts needed. We ended up with a 36K program, just a bit bigger than my first Fortran machine. It had 16 bit words; you can represent the distance from earth to moon in 16 bits to about one-meter accuracy. You can get to the moon with 36K, but the software cost 900 man years. That’s ten man-days per instruction. You can get to the moon with a tiny program and have it work the very first time you try it for real, but you need a one-ohm shunt across the US treasury to cover all the testing. We got it done on time and it worked. The project ran a tad over the initial budget, just like the Boston big dig, but the big dig was also late, and we weren’t.

How are the mighty fallen! Government-funded software got us to the moon 50 years ago, now the government couldn’t even set up a relatively simple insurance web site. We’ve lost our mojo, we’ve also lost government confidence and government competence. It’s up to the private sector to get anything constructive done.

Modern robots are a lot more capable than earlier ones. There have been advances in materials – Kevlar, titanium, ways to make ‘em lighter and stronger. We have smaller, more powerful motors, but the biggest advance has been smaller, faster, cheaper computers. In 1967 or ’68, one of my friends spent a couple of summers working for an MIT project to have computers translate from one language to another. They had an IBM 7094, one of the biggest computers of the day. It had 64K 36 bit words. It had drum storage, a ponderous rotating thing about the size of a washing machine; it held a few hundred kilobytes. Again, that’s K, not M.

You simply cannot do language translation with so little storage. The project failed.

I worked at the New York Times in the 1970’s. They had a linguist write rules to hyphenate words so they could set type with computers. The NY Times had lots of pages with narrow columns and there are lots of hyphenated words. He was trying to write rules to fit into a 64K byte computer along with all the typesetting software. He had a hard time hyphenating the owner’s name – “Sulzberger” didn’t follow any of his rules and he didn’t have enough memory to define a special case.

How many of you have smart phones? Please take it out and look at it. You take it for granted, but in your hand, you are holding more transistors and more RAM than existed in the entire world when we landed on the moon. All that storage and all that computer power makes a huge difference in what you can do.

While we’re on smart phones, do any of you recognize the name “Kernigan?” Fame is fleeting indeed. 40 years ago, all the software folks in the world knew that Dr. Kernigan helped Dr. Ritchie invent both C and UNIX. When PCs came out, they were very hard to use. At a computer conference, Dr. Kernigan said, “I have a dream that one day, the computer will be as easy to use as the telephone.”

At a conference just before the iPhone came out, he said, “Someone reminded me that I once wished that computers would be as easy to use as telephones. I’ve got my wish – I can’t understand my telephone either.” Steve Jobs’ gesture interface and icons have now granted Dr. Kernigan’s wish – your phones are more complex and more capable than any pre-1990 mainframe, and far easier to use.

The New York Times’ hyphenation problem has been solved. We no longer use rules. We have an entire dictionary with hyphens in it, and it takes a trivial amount of space. You can’t buy a hard drive smaller than 150 gigabytes any more. My first personal hard drive had 5 megabytes. M, not G, but it sat on my desk and not in a truck.

Language translation?  There has been improvement in algorithms, but most of the ideas were documented way before we had computers big enough to run them. Google’s translation system has new-ish ideas, but a lot of what they’ve done is inventing new ways to handle massive amounts of data including monster natural language dictionaries. They converted the entire world-wide web into a massive indexed database IN RAM. Their searches are fast because they don’t read from disk, it’s all in RAM. Having that much RAM and computer power makes free machine translation possible. It also makes robots possible.

Question: Are self-driving cars robots? I say they are. They have massive processing power and massive data coming from cameras and other sensors pointing in all directions. Self-driving cars will be safer than human-driven cars before long. They’ll kill people, sure, but it’ll be fewer people and different people.

Let’s get to anthropomorphic robots, robots that look like people. Google’s cars need more computrons than we can pack in a human form, but they’re getting smaller. We’ll get the package small enough to look like a person, or we’ll put most of the computing and data storage in the cloud. Face recognition software has gotten pretty good. Once it’s declassified, or leaked, the computer can recognize people and respond individually.

Voice recognition software is a lot better than when I was in college, again, because the software is faster combined with somewhat better algorithms. Computers still can’t speak nicely; books on tape have to be read by humans, but you can understand the computers when you dial into one of those automated customer service centers, sort of. The bits and pieces are coming together. There’s more work needed on having computers speak and we have to make Google’s car computer smaller and make the sensors better, but we’re getting there.

But you’ll notice that things took longer than expected. When I graduated from MIT, AI researchers thought they’d knock vision off over a summer and then get on to the hard parts. Some years later, I took a summer AI course. I hate driving; I wanted a driverless car. Digital mapping had begun to come to life. I wanted to know what they thought were the biggest obstacles to a computer driving a car. They said, “Vision, of course. A long way to go.” They were right. It’s been more than 30 years, but we’re getting there.

Along with being flexible and looking for new opportunities, you must realize that you may have to be more patient than you expect. That’s inherent in writing software. We have to talk about software when talking about robots because software is the biggest part of the problem. What is software, really?

Software consists of a human who understands a task explaining it to the computer. Computer languages are primitive; the last breakthroughs were structured programming and object-oriented programming about 40 years ago. The computer does precisely what you tell it to do; the problem is telling it precisely what you want. If you knew how you see, or hear, or walk, you could teach the computer, but you don’t know how you do it.

When the computer doesn’t do what we want, we call it a “bug.” I’ll tell you a secret that 95% of software managers don’t know. When we’re coding, ‘most every day the computer throws what we’re doing back in our faces and says, “You turkey, you haven’t told me what you want.” It takes a strong ego to put up with that day after day. Unless a programmer sincerely believes that the program will rise from the ashes and function wonderfully if he fixes one more bug, he burns out and quits from frustration. Ya gotta believe!

This is death on estimating schedules. When the manager asks when the program will be done, the answer’s, “Next week for sure.” The programmer isn’t lying, he sincerely believes that or he’d quit, but it’s generally wrong. Think salesmen. 99% of prospects say, “NO!” Unless the salesman sincerely believes that the next person he calls will buy a million and put him over quota for the month, it’s hard to keep banging doors.

Galloping optimism by true believers has carried AI research for the past 40 years. The researchers sincerely believed that the next grant would solve vision, or translation, or robot hand control, or walking, or human reasoning once and for all. They wrote grant applications that way. They weren’t lying, but they were wrong. Except for computers being able to speak nicely, I believe we’re nearly there.

I’m no prophet, though. I believed we were nearly there when I wrote my book back in 1989, and we weren’t.

As we get back to robotics, let me give you the Peter Pan theory of history. The Peter Pan story opens, “This has all happened before and it will all happen again.” Peter Pan tells of a boy and a girl whose interaction makes a good story. Boy-girl interaction has indeed happened before, and it will happen again, maybe to you.

Back when we were developing the Apollo software, we used IBM mainframes with maybe 128KB to do our simulations. Memory cost about 10 cents per bit. It was a wonderful day when IBM got down to a penny a bit and our computer got to a megabyte, I remember the joy! How much does a megabyte cost at 1 cent per bit? 9 million pennies instead of 90 million pennies. How much does a megabyte cost now? Picopennies.

We handed our programs through a window to the high priests of computing. They’d run our program, wrap the printout around the deck, and pass it back. We got one run per day unless we stayed all night to get extra runs when nobody else was around. If you wanted higher priority, you bought the operator doughnuts or pizza.

Then the PC came along. We could run anything we wanted, if it would fit. I remember an editor of PC magazine asking me, “My PC has more memory than an IBM mainframe and adds and subtracts faster. Why do people buy mainframes?” Do you know why? To sort phone bills. Lots of phones in the 212 area code. There are 20 business days in a month. Every day, you take 1/20 of all the phone numbers in New York, sort all the calls they made by time, add up the price, and print a bill. That is not a compute problem, that’s an I/O problem. So is pretty much all transaction processing. You call, they ask your account number, pull it up on the screen, and tell you something. No computing at all, just I/O. A mainframe is an I/O engine.

Now we have the cloud. As in the old days, the computer isn’t on my desk, it’s someplace else. The computer used to be someplace mysterious, then it was on my desk, now it’s someplace mysterious. Your PC moved from your desk into your pocket. This has all happened before and it will all happen again.

The cloud saves money - if your program is too slow, fire up more computers from the cloud and shut down unneeded computers to save money.  Cloud applications run in small pieces to be started and stopped as needed.

We call these mini programs microservices; that’s the latest buzzword.  The idea goes back to the Apollo days. All computers were tiny by today's standards; microservice was all we had.  Suppose you're running a simulator to train the Apollo landing pilot. One small computer generates simulated radar signals, another runs each display, another pokes the Apollo guidance computer with fake data, and so on. The simulator coordinated a bunch of little computers to get a big job done, just like today's clouds of microservices.

We defined standards for what we called Remote Procedure Calls in the 1960s, then Object Request Brokers gave us CORBA around 1991. Having been through this a time or two, I can tell you that getting to microservices will burn your fingers back past the elbow at least once, maybe twice as old problems come back wearing new clothes.

Remember when we went from mag tape to relational databases and online transaction processing?  We had a problem.  Suppose the bank takes a dollar from me to give to you.  That’s two database changes.  Suppose the bank computer fails after taking the dollar from me and before giving it to you. The books won't balance.

After much suffering, we developed the idea of grouping database changes into transactions.  The program starts a transaction, makes changes, and commits the transaction.  If anything goes wrong, it rolls the transaction back.  It’s all-or-nothing; either all the changes happen or none of them.  After years of pain, All or Nothing  a.k.a Commit / Rollback works in spite of network, hardware, or software failure anywhere. Databases are distributed and replicated all over the world; this is not simple.  Thinking about it makes your hair catch fire.

Service-based architectures have 7 common problems for which you need cut and paste solutions before you start.  If you don't have those 7 design patterns in place, each of your development teams will solve these problems in a different way at great cost.  Let’s talk about just one. When you call a microservice, you don't always get a reply. That could be because the message didn’t get to the microservice, the service might crash, or the reply back to you could be lost.  You don't know what happened, so you send the message again.  The service may see the same request any number of times, but must do it only once.

Once And Only Once is as messy as the relational All or Nothing.  The other 6 problems aren't as interesting, but all of them reward you for giving out standard code samples. Between 70 and 90% of the code in distributed systems deals with these 7 issues.  If you supply cut-and-paste drop-in code, your programmers focus on business logic. Eliminating more than half the code saves you a lot of money.

The cloud will bring many old problems wearing new clothes, but your programs can reach all the data in the cloud and all that compute power via WI FI just as smart phones do. You don’t need the power in your robot, the robot can call the cloud for tough problems like, “Am I vacuuming cat hair, or vacuuming the cat?” Your applications can call on extra computrons as needed. You can do massive I/O and massive compute on demand without having to lug the computer around all the time. Better yet, you pay only for what you use instead of having most of your server farm sit idle most of the time.

We are, we are, we are the engineers. We’re the STEM guys, MIT, Carnegie Mellon, Stanford. We grow new businesses; we make the world better by creating wealth. We’re at war with the Ivies, Harvard, Princeton, and Yale. Ivy grads go into government to make the world better by passing laws. They’re good government guys, known as goo-goos. Their laws make it harder and harder for STEM guys to create jobs, that’s why jobs move offshore. We STEMs fight the goo-goos every inch as we try to make the world a better place.

The worst thing is that goo-goos think profit is evil. Profits are pried from the bleeding fingers of downtrodden employees. They don’t realize that profit fuels civilization. How did the Babylonians decide that there are 360 degrees in a circle? How did the ancient Indians invent the concept of zero? They had enough farming surplus that a few men could spend time in research. How did Euclid and Socrates and Plato and Maxwell have time to think? There was an agricultural surplus.

How did we get the iPod? From the profits Mr. Jobs made on iTunes. How did we get the iPad? From the profit Mr. Jobs made on the iPod. If government had taken his profits away, we wouldn’t have them.

GooGoos say government should take money from “the rich” and benefit society. Back in the 1960’s, our government put man on the moon in 10 years. Now, it couldn’t get a web site to work. Most money government spends is wasted.

Consider this. What are we going to do with all the people who can’t get jobs once anthropomorphic robots take over burger flipping, janitorial work, and the remaining manufacturing jobs? We already have unmanned factories. What are all those people going to do? We STEMs better find something…. Remember this:

The reasonable man adapts himself to the world. The unreasonable man adapts the world to him. All progress comes from unreasonable men.