Mark Mitchell: An early interest in computers leads to lifelong ambition

Ann Steffora Mutschler -- EDN, January 19, 2012

How did you get interested in engineering?

A: When I was in elementary school, they still had budget for various enrichment programs. They had a woman—Vivian Wills—teaching accelerated math and computers. I give her tremendous credit because, especially at that time, … there were not a lot of women in computers. The school had managed to get its hands on a grand total of two Commodore PETs. I think we had one 8-kbyte model, and we might have had a 16-kbyte model that had an extra bank of RAM in it; they had tape drives. In about the second grade, I got curious about these things and would start going in during recess even before I was old enough to take the classes and started learning a little bit about how to use them. Like kids today, I wanted to play games on them. ... Of course, the games weren’t really sophisticated. She could tell I was interested in computers, so I started even ahead of the coursework learning to program them in Basic and, then, a bit later, by the time I got to the end of elementary school I managed—by working odd jobs—to get my hands on a Commodore 64. I programmed that thing both in Basic and in assembly language.

What advice would you give to engineering students?

A: There are a few things that I think students don’t get much visibility into that are really important. One is the difference between computer science and software engineering. A lot of what gets taught is computer science, so they learn about algorithms and data structures—and all those sorts of things are very important—but the discipline of software engineering is a really collaborative thing. That [distinction] is the key difference.

Computers have gotten complicated enough that the myth of two guys in their garage building some piece of software is pretty well done. It takes, even to build anything of any consequence, probably 10 or 20 people working on it for a year or two. So you have to learn to work well with others, work on projects, and manage schedules—that is not taught, and it is pretty important.

The other thing is—and I don’t know whether this [subject] is teachable—but when you come to a piece of software, you look at it, and your thought is, “Oh my goodness, this is an ugly, hairy mess. I can’t believe they put it together like this, and we need to just take this [thing], throw it out, and start from scratch. I know better. I’ve studied the latest techniques, and I know how to build this [thing] from the ground up so that it’s way better.” You’re going to have that instinct a hundred times, and you’re going to be right about one out of a hundred times. [The attitude] is incredibly pervasive. It’s one of these things that every young software engineer [has]: You look at some horrible pile of code, and what is really hard is to tease out what parts of that [code] are, despite maybe some ugliness in the structure of it, essential complexity that has to be there for the thing to do what it does.

What has open source done for the software-engineering community?

A: In general, the engineering community really loves it and it’s intuitive for most engineers because I think most engineers and scientists like to share. I think the general feeling [is], “I’ve discovered something I want to share with you. ... If you’ve already built a wheel, I just want to use it, I don’t want to have to build my own wheel. I want to add to the state of the art, not recreate things." That’s a real, natural tendency among engineers in all disciplines, and maybe scientists of all disciplines. Why go do the same experiment someone else did? You want to do the experiment, publish it, and someone can build on top of it.

Open source really makes sense to engineers at that level, but it certainly changed the discipline and practice of things because now one of the common engineering activities is actually integration and customization of open-source software. So, as you’re going off to build, for example, a system for navigation, a CD player, and the stuff that sits in the front of the car up under the dashboard that you can play with while you’re driving, now that system very well may be running on Linux. The exercise then for the people building that system is to get a lot of open-source technology and then try to customize it, manipulate it, [and] add things on top of it to make it into that system.

The open-source solution … means that you can move much faster, and it’s much cheaper because you’re using all this stuff that already exists. It’s just code from somewhere that you got somehow, and you have to work with it. Even more of the discipline is about comprehending other people’s work and building on it as much as it is creating from scratch.

What is the biggest challenge the embedded-software industry is facing?

A: The biggest challenge we have as an industry is in these really large systems. We need them to be reliable, we need them to be secure, and we need them to perform well. We’re hitting the limits of our ability to scale not in a technical sense but in a process sense. We don’t understand the systems well enough to make them perform well, and we don’t have time to make them perform well. The techniques and tools we have aren’t sufficient. That’s our big hill to climb.