Command Line Heroes - Minicomputers: The Soul of an Old Machine

Episode Date: January 28, 2020

They don’t fit in your pocket. But in their day, minicomputers were an order of magnitude smaller than the room-sized mainframes that preceded them. And they paved the way for the personal computers that could fit in a bag and, eventually, the phones in your pocket.16-bit minicomputers changed the world of IT in the 1970s. They gave companies the opportunity for each engineer to have their own machines. But it wasn’t quite enough, not until the arrival of 32-bit versions.Carl Alsing and Jim Guyer recount their work at Data General to create a revolutionary new 32-bit machine. But their now legendary work was done in secret. Codenamed “Eagle,” their machine was designed to compete with one being built by another team in their own company. These engineers recall the corporate politics and intrigue required to keep the project going—and how they turned restrictions into advantages. Neal Firth discusses life on an exciting-but-demanding project. One where the heroes worked together because they wanted to, without expectations of awards or fame. And all three discuss how this story was immortalized in the non-fiction engineering classic, The Soul of a New Machine by Tracy Kidder. If you want to read up on some of our research on minicomputers, you can check out all our bonus material over at redhat.com/commandlineheroes. You’ll find extra content for every episode. Follow along with the episode transcript.

The year was 1978, and a battle was raging in the minicomputer industry. Just a year earlier, Digital Equipment Corporation released its 32-bit VAX 11780 computer. It was much more powerful than the 16-bit machines in the market. Sales of the VAX quickly overtook their slower competition. Arch rival Data General was desperate for a new machine to compete with the VAX. They needed a 32-bit computer of their own, and they needed it fast. But that competition between Data General and DEC wasn't the only battle going on. There was also a turf war brewing inside Data General. And the spoils of both wars would be the creation of an incredible machine

under incredible circumstances. A 13-inch laptop weighs maybe three pounds. We take for granted our computer's portability and convenient size. But back in the 70s, most computers were still room-sized mainframes, multi-million dollar machines weighing several tons. Then, when hardware costs plummeted, the race to smaller, faster, cheaper machines began. The minicomputer opened the door for engineers and scientists to have a terminal of their own.

It was the machine that led us to where we are today. Last season on Command Line Heroes, we took a deep dive into an area that is central to software development, the world of programming languages. We looked at their history, the problems they solved, and how they've evolved over time. Languages like JavaScript, Python, and C, Perl, COBOL, and Go.

This season, season four for those of you counting, we're diving deep again. This time into the hardware that our software runs on. We're going to tell you seven special stories about the people and teams who dared to change the rules of hardware. That laptop on your desk, that phone in your pocket. Command line heroes put their soul into every piece of hardware you've owned and heroes before them. Their passion for building, their bold moves to make our hardware a reality, have revolutionized the way we program today. I'm Saranya Dbarik, and this is Command Line Heroes, an original

podcast from Red Hat. In our season premiere, the story of an engineering team racing to design, debug, and deliver a next-generation computer. Their work became the subject of the 1981 bestseller and Pulitzer Prize-winning book, The Soul of a New Machine by Tracy Kidder. The book follows many of the guests you'll hear in this episode. Back to Data General, company president Ed DeCastro hatches a plan to compete with DEC. He splits up the engineering department, moving a team from its Westboro, Massachusetts headquarters to a new office in North Carolina. Their assignment? Develop an advanced 32-bit design that would crush the Vax. They named their project Fountainhead.

DeCastro gave the team almost unlimited support and resources. Fountainhead was going to be his company's savior. The few remaining engineers left behind in Massachusetts? They felt seriously slighted. They knew they could build a Vax killer, probably a better one than what Feltonhead could build. But DeCastro wouldn't give them a chance. So the leader of that group, Tom West, decided to take matters into his own hands. A self-taught computer engineer, Tom West ran Data General's Eclipse division. Eclipse was Data General's most successful line of 16-bit minicomputers.

Tom could build machines, he could ship them, and he knew what the market wanted. After setting up Fountainhead, DeCastro told the remaining engineers to keep working on improving last year's product line. Tom and the others were unimpressed. We were not happy with that at all. Some of us, you know, left for other jobs and others of us were depressed and worried about our careers and not feeling very excited. And we predicted that the other group was going to fail. Carl Alsing was the manager of the microprogramming group at Data General. He was Tom's second-in-command.

They decided to come up with their own project. This would be a whole new design using the latest techniques, build a 32-bit computer that would beat the Dexfax. So we put together a proposal for that and went to the president, Ed DeCastro. And he said, nope, no way. No, the North Carolina group's taking care of that. You don't have to worry about it. So we were discouraged and we went back and came up with another proposal called Victor. We looked at ways of making the old last year's product better. And we had in there a little switch, a mode bit in the system that when you turned it on, it would enable the computer to act like a modern 32-bit minicomputer, although slow. And we took that to Ed DeCastro and proposed it. And at the end, he said,

you have a mode bit in here. I don't want to see any design with a mode bit. North Carolina's taking care of the new designs. So again, we were discouraged. And I think this is when Tom West decided that we were going to do something clandestine. Tom came up with two stories. One was for DeCastro. They would work on an enhancement of the old Eclipse product line, make it a little faster, add a few new buttons, a different color. Tom pitched it as insurance, just in case something went wrong in North Carolina. DeCastro approved it.

And then Tom told another story, a better story, to his team. So Tom West proposed to a few of us in the team that we build a really good modern machine that's completely compatible with the previous machines and did all the latest high-tech stuff that we needed. And virtual memory and 32 bits and error-correcting codes and all those kinds of things. Multitasking, multiprocessing, lots of memory. Guys, we're going to build the latest market-killing new machine. The codename for this market-killing new machine? The Eagle. Nowadays, it feels like there's no limit to what you can do with the memory built into our computers. But back then,

a big breakthrough happened when 16 bits gave way to 32 bits. All of a sudden, your address space went from 65,000 bytes of information to over 4 billion. And with that increase, software could deal with larger amounts of data. That left computer companies with two basic challenges. Transitioning from 16 bits to 32 bits, sure, but they also had to keep their old customers, the ones using the old software, happy. So they had to create a machine that would keep old software running,

a 32-bit computer that could be backward compatible. The VAX, for all its power, didn't have an elegant solution to that second problem. But Tom was determined that his Eagle would. Eagle HQ was located in the basement of Westboro Building 14AB. Tom assigned Carl to head up microcoding. Carl assigned Chuck Holland to manage the coders, which became known as the microkids. Meanwhile, Ed Rosala would oversee hardware.

He assigned Ken Hallberger to manage that team, which was appropriately called the Hardy Boys. Tom had an ally and VP of engineering, Carl Carman. Carman also had a bone to pick with DeCastro because DeCastro refused to put him in charge of the North Carolina group. Carl Carman knew what we were up to and said nothing to his boss. And so he was funding us, but we needed to keep the salaries down and we needed some really good, smart engineers. So we decided to go after college recruits. One advantage of that is that they don't know what you can't do. They think that you can do anything.

Jim Geyer was two years out of college and working at Data General when he got assigned to the Hardy Boys. The machine that was being developed down in North Carolina was much more high-end computing, almost mainframe in nature. And well, I mean, that's a pretty big thing to jump into to compete with IBM and the other mainframe companies at the time. We thought we had the edge because we were trying to do something that was not quite as ambitious. And we were really, really, really focused on a neat, clean, simple implementation with low cost and fewest components and so forth.

Low cost, simple design. They realized that they needed to use firmware to control everything. The more functionality they could put into firmware, as opposed to hardware, the cheaper and more flexible it could be. And they'd be able to make changes as needed. Of course, modern-day computers are all built this way. But in 1978, the approach was brand new. The kind of design we were doing was very minimal. I mean, we were looking at ways of making things simple and straightforward, uncomplicated, because we knew that it couldn't grow to be a big expensive machine. It had to be just a few boards, a few circuits, and that's actually an advantage in making it fast. You know, there's a difference between designing a product that's safe, risk-free,

and a product that's going to win. And we were not worried about risk. We were worried about winning. We wanted it to be fast and cheap, and we wanted to design it quickly. So we only had three or four boards in there, a minimum amount of hardware, and we made up for that with firmware. The Eagle team faced a lot of tough constraints. The VAX was the highest performance 32-bit computer on the planet.

Eagle had to match it. But on top of that, it had to be compatible with their 16-bit architecture too. Getting all that done with less money and time than any other team made Eagle feel like a serious gamble. But Tom West's team was all in. There were two systems running 24-7 that we had two shifts of engineers working on them. We all had to be trying to figure out everything. So we had to learn what everybody else's part did. That was both challenging and extremely educational for me, but we were all engaged with each other to try and go, what's the next step to figure out this problem? What do we need to look at? Everybody like pouring through schematics and other pieces of documentation

to figure out, look at this signal, look at that computer state, look at this sequence of steps that the microcode is going through. Is it doing the right thing? Oh, wait, it's going the wrong direction. Uh-oh, why did it do that? This was serious business, and that was the work ethic. It was intense in the group. There were sometimes arguments about which way to do something. There might be one way that cost a little bit more money and another way that was cheaper, but not as fast or not as effective. And there'd be heated discussions and meetings with some effort to make a consensus. And we made those choices, though. And then we worked together. We worked day and night.

We divided up the hours for the prototype. We only had two prototypes and it was really important that both teams get to work on those prototypes. So there were people working the night shift and people working the day shift and people getting tired. But, you know, there was enough excitement about it

that it was rewarding. And so nobody complained too much about the working conditions. The working conditions. Some accounts from that time say that to get what he wanted from the team, Tom West practiced something called mushroom management. Feed sh** and watch him grow. Inside a cramped and hot workspace, the hours were long and the schedules unrealistic. Tom himself has been described as enigmatic, cold, uncaring. One engineer even referred to him as the Prince of Darkness.

Was Tom West so intent on winning that he exploited his team? Did he sacrifice the well-being of the micro kids and the hardy boys to get the perfect machine? Tom was an interesting guy to work with. He expected a lot of you, and he didn't give you a lot of direction. He expected you to figure out what you needed to do. And pretty much if you weren't able to do that, you weren't on the team. Direction came from Carl or Ed, the line managers that Jim and the rest of the team worked with on a daily basis. But these young engineers were also in it to win. And they liked the opportunity they were given to figure it out for themselves. I personally won the first honorary micro kid all-nighter award. I don't know, maybe we were overconfident, brash, young upstarts who didn't know any better. We were confident. You know,

we kind of thought we were pretty smart and could figure things out. And we fed on each other's, maybe those are egos in that sense. I was having a lot of fun doing it. I think most of us were having a lot of fun doing it. Carl disagrees with the term mushroom management. He said it was just the opposite. They all knew exactly what was going on and what was expected. It was upper management who did it. At the same time, Tom West was under a tremendous amount of pressure from multiple fronts. And that pressure got passed along to the group. Tom was keeping the true nature of the project quiet.

So he didn't speak much to the engineers and he remained kind of aloof. And he told them, of course, that they weren't to discuss the project outside the group or at home, not even to use the word eagle. So we also conveyed that this was very urgent, that we had to do this in a year, that the competition was already in the market. And if we were going to hit the peak of the market with this thing, we had to get it done now. And so they were under a lot of pressure. And there was an expectation that they would work nights and weekends and there would be no time for, you know, going on picnics with their family or anything that wasn't work-related.

I wanted to find out what it was like working in the trenches of Building 14AB. So I sat down with Neil Firth. He was one of the micro-kids. He joined the team fresh out of school. What was it like to work for Tom West? Did you get to interact with him a lot? Not necessarily. He was kind of this ghosty figure that we saw him around. He tried not to interfere so that we could lead ourselves and achieve the goals.

This was brand new stuff for what they were doing. And he didn't want to influence us by trying to impose things that had been done for the previous generation of processors. It sounds like an intense place where you really want to keep moving and keep getting things done. How did you deal with the fact that there just wasn't a ton of time? It wasn't a factor, to be honest. There was really no issue with there being enough time. We would take the time it took to achieve the result. That's where the spouses had to be very supportive and understanding because they didn't necessarily see us immediately. You could equate it to some of the Silicon Valley people at the time or the Jobs Wozniak type, let's just get in and get this done.

We're not quite, you know, all live in the same apartment and code on the floor type people, but it had some of those characteristics. And during that time, what kept you going? Why were you so motivated? Quite frankly, it was solving a problem. I've always been a puzzle and problem solving guy. In fact, most of the team was that way. All of us had that in our background and we all enjoyed it. So, you know, solving those puzzles, getting those things solved, discovering a way to do something that had never been done before. So what was your most memorable moment on the console. And then we waited a little while, and then another letter, and then another letter.

And then we suddenly realized what we were running for test code was the diagnostics that were being designed to run. And so the microcode simulator was simulating the hardware running this microcode, and it was starting to print characters as if it was actually operating. So it was, you know, maybe 100,000 times slower than real life, you know, when it actually came out and operated. But that was one of my most memorable moments. Looking back on it now, do you feel like you were exploited? No. I mean, I was aware of what was happening.

I knew what was happening. So, no, I do not feel exploited. coming out of college that would have never been that I would be in a project that significant or have an opportunity to play such a significant role in a project like that. I'm wondering how you think about the sacrifice of invention. Because if you think about all the great things that we make, usually we have to give up something, right? Something's got to give to make something truly amazing. Did that happen for you? And if so, what was that thing that you had to give up? I wouldn't say that there was a thought-driven process on my part for giving up something. I think it was much more that I became a little more attuned to

what I was doing and how I did it impacted those around me. But I never necessarily saw it as a sacrifice. And the people I was close to, they lived in a world where that's just the way things happen. I hear the horror stories, if you will, about today where, you know, 24-7, you wake up, you plug in your coffee IV, grab some pizza or dim sum and you start coding and eventually you fall asleep in your keyboard and then you wake up the next morning and repeat the process. We certainly were nowhere near that level of sacrifice. I still had a wife. I still had friends. We still got together. It certainly wasn't a nine-to-five job, but it provided me with a lot of personal and technical achievement. And I was able to share that with my wife and my sister and my mother and my father and my father-in-law.

So those people could appreciate that. Yeah. So what do you think is the key to making something truly great? Key to making something truly great? Interesting question. I think it depends on the people involved doing it because they want to, not because they have expectations of achievement or wealth or fame, because those things are very fleeting and almost never satisfied. But if you're going in trying to achieve a goal and you and a bunch of people work together on it and achieve it, that really is satisfaction when you achieve that. Neil Firth was one of the micro-kids on the Eagle Project.

He's currently the president of Visim Worldwide, a software company. As chronicled in Tracy Kidder's book, Tom West's aloofness and distance was deliberate. It was his attempt to keep a clear head above all the day-to-day chatter so that Eagle's goal could remain intact. Even more than that, though, he wanted to protect the team, isolate them from the politics and corporate brinkmanship happening around them. He also protected the microkids and the hardy boys from preconceived ideas about what was possible. In 1980, the Eagle was complete, a year later than Tom had promised, but done nonetheless, unlike Fountainhead. Just as the senior team had predicted, the Fountainhead group had failed and their project was shelved. Here's Bill Foster, director of software development at the time, on Fountainhead's struggle.

I think the biggest mistake that was made was it wasn't given any limitations. More or less it was let's do the world's best computer. Well, when should it be done? Oh, we don't really have a date for that. How much should it cost? Well, we're not sure about either. And I have to fault Edson with this. He didn't put enough boundaries on the programmers and on the engineers. And if you turn a bunch of programmers and engineers loose, guess what? They're going to make something so complex, design something so big, it'll never get done. Let's remember for a moment, back when Tom and his team decided they would build the Eagle in secret.

For two years, this was happening. And the whole time, the president of the company had no idea what was going on. When the machine, now officially called the Eclipse MV8000, was ready to ship, the head of marketing went to Ed DeCastro to greenlight the marketing campaign. Carl Alsing explains. The head of marketing, he said, well, we're ready to do the rollout for the Eagle, and we're going to need several thousand dollars. We're going to have a press conference in six different cities around the world, and we're going to do a tour, and we're going to go to many cities, and we're going to shoot a film and show it, and it's going to be a big splash. And Ed DeCastro

said, I don't understand. Why are you doing that? This is just another bag on the side of the eclipse, a skin job. And marketing manager said, nope, this is a whole new machine. This is a 32-bit machine. It's got virtual memory. It's compatible. It's going to beat the VAX. We've got the whole thing here. And Ed DeCastro was really confused for a bit. He thought we were failing in North Carolina and that was going to be the end of it. And we had saved his bacon. So, yeah, he invited us all up and we had a little lunch meeting. There were sandwiches and soda.

And he said, well, you guys did a good job and I'm surprised. And I didn't realize you were doing this. But we are going to roll this out. And I understand there's going to be a film and some tours. And you guys are going to be part of that. So thank you. And eat your sandwiches. The Eagle, now christened the MV-8000, appeared on the front cover of Computer World magazine. All the media hoopla during the rollout

turned that team of secretive, basement-dwelling employees into minor celebrities. After all, they had saved Data General. But the good times were short-lived. Tom West could no longer shield the group from the company's internal politics. The team was unprepared for the animosity. Others within the corporation envied their accomplishments and were appalled that they got away with the secret project for so long.

Soon, a new VP of engineering replaced their ally, Carl Carman. The new guy broke up the Eagle Group and shipped Tom off to Data General's Japan office, all before a single MV8000 was sold. I thought we built the best 32-bit super minicomputer that money could buy, and I thought that was a great thing for Data General, and I thought it was going to kick digital around a little bit. And not that we ever took the world away from them. Competition in that time was just way too tough. And it's hard to be a winner in high tech. But I thought that we'd done something worthwhile. When the Eagle was released, it did save Data General.

But after losing market share to DEC for three years, the company never really recovered. And the industry had moved on. Many computers were no longer the big thing. The microcomputer race had already begun. Paving the way to the personal computer revolution. Data General went on and did other versions of that, improvements on it and other models, and it carried them for a while. And so they enjoyed some success.

But, you know, things change, the market changed, and they turned themselves into a software company, and then they ended up being bought out by somebody else and now I think they're a file drawer at some company in Hopkinton, Massachusetts. A year later, many in the Eagle Group had left Data General. Some were burned out. Some were ready to build something different. A few headed out west to Silicon Valley, keen to find that next creative spark. Regardless, there didn't seem to be much point in staying on at a company that didn't recognize all they'd done to save it. That same year, in 1981, Tracy Kidder's Soul of a New Machine was published. Now the world

would know how the Eagle got built. If you're asking me what the Soul of a New Machine is, I guess I would say it's the people and the things that they go through, the sacrifices they make, and the effort they make, and the excitement they feel about that and the satisfactions they're hoping to get, maybe get, maybe don't, but they strive for that. The machine, in a way, was kind of a bit character. It was the people who were the real guts of what it was about. In the next episode of our all-new season on hardware, we go back in time to the world of mainframes and tell the story of another group of rebel employees. The computer they built gave birth to a programming language that changed the world. Command Line Heroes is an original podcast from Red Hat.

This season, we're compiling some great research for you so you can learn more about the history of the hardware we're talking about. Head on over to redhat.com slash command line heroes to dive deeper into the Eagle and the team behind it. I'm Saranya Yadbarek. Until next time, keep on coding. Hi, it's Saran. If you're hearing this, you made it all the way to the end of this episode.

Thank you. I'm here because I have good news. For every piece of hardware this season, we have even more for you to listen to. Bonus episodes with additional interviews and stories. You can find those bonus episodes at redhat.com slash command line heroes. Just follow the links for this episode, then scroll down to bonus episode. That's redhat.com slash command line heroes, or even easier, use the link in the episode notes. See you next time.