Sixty Years of Humanizing the Craft with Mel Conway

Transcript

Mike Amundsen: Let me start out with a short introduction. While most of us here know our guest Mel Conway from his 1968 paper “How Do Committees Invent,” his influence on the way we program computers today reaches to many more areas of study.

Raised in Northern Ohio, Mel Conway earned his master’s degree from CalTech and his PhD in mathematics from Case Western Reserve in Ohio in Cleveland. It was at Case Western where he first encountered the first COBOL specification which launched a long career in fixing the COBOL compilers of many types. And he began to think about how humans and machines interact. After a stint with the Air Force Electronic Division where he gained lots of hands-on experience as to how large organizations work and how systems are built, he worked on several projects including Sperry Rand’s UNIVAC, designing and implementing a unique software-hardware combination for medical imaging, and many other projects.

It was in the early ‘80s that Conway became involved in designing and implementing what later became known as Mac Pascal. It’s a work of what he calls a “single representation model,” which he’ll talk about later that made it possible to support compiling, debugging, and more all in a very small amount of space. Some of that work let to what we know today as developers as line-by-line compiling and it was first pioneered by Mel.

Recently, he’s been working on a new project on making computer programming and development of applications generally accessible to everyone, which he calls “humanizing the craft”. And I’m very honored to have him here with us today on the API360 stage and won’t you please again welcome Dr. Mel Conway.
Mel Conway: Thank you.
Mike Amundsen: So, let’s start with the easy question, what is Conway’s Law?
Mel Conway: Okay. Well, have you got a graphic for this? Yes, it started off when I became a graduate student in 1958, which is 60 years ago. The world of IT was decks of punch cards, running them through mechanical processors. And each machine, there were maybe a half a dozen machines in the repertoire, each machine had a single function. And programming consisted, and a file was a deck of cards, and each program consisted of moving process of files from one machine to the next and that was programming. That was how you sequenced the process. It wasn’t with in the machine, the machines just dealt with looking at data and doing some simple thing, like deciding which hopper to move the card to.

What I noticed, and the manufacturers were just beginning to come out with computers and there were very few tools and just mainly assemblers. And we were a little coterie of graduate students playing with computers and I noticed that the products that the manufactures were building were really clunky compared to the stuff that we were building. And that was first insight I had into the idea that the organization, the nature of the design organization affects the nature of the product.

Well, in '59, the first generation COBOL specification came out and I’ll tell you it was a really pig of a language. And it was, not only that but it wasn’t well defined, it was incomplete. And it was designed by a committee of representatives from government and the computer manufacturers. And their concept of a compiler was, a compiler was another data processing system were you would have multi-phases copying tape to tape to tape. So a compiler was basically a data processing system, like a payroll.

Well at Case, we had machines, you know, with a couple thousand characters of memory and a reader and a punch. And I realized that if we’re gonna design a COBOL compiler, it’s going to have to be a one-pass COBOL compiler, which was a totally strange idea at the time.

So I set out to answer the question, “What would a one-pass COBOL compiler look like?” And it took me several years. And the real lesson that came out of that exercise was when you design a system to meet a particular requirement, there’s actually a family of designs that are possible. There are many designs, most of which you haven’t thought of. And as soon as you organize to build a particular design, you have ruled out a lot of the other designs that you haven’t thought of. And that has major implications for getting the job done because usually the first design is wrong and that means your organization is wrong.
Mike Amundsen: So let me ask just, this sort of comes to the point about what you experienced in the Air Force also, right? So some decisions are made up front, right?
Mel Conway: Oh, well, I was in the Air Force in '62 and '63 and we were procuring really large, mission-critical computer systems like a logistic systems for the whole Air Force and it was pure waterfall. It was a multiyear process in which one group designed a requirement, another group came up with a functional design, you know, about five stages and it was several years. And of course the cliché at the time was by the time it gets built, it’s obsolete. But now we…
Mike Amundsen: That was a cliché in the early ‘60s, right?
Mel Conway: Oh yeah, yeah.
Mike Amundsen: Okay
Mel Conway: But another thing I noticed was that the legal constraints required that each team could not design for the next stage because there would be a conflict of interest if they did that. And so there was isolation between each stage of the waterfall. So you got really weird results because the group, like, for example you have to design the hardware or choose the hardware before you choose the software. And the software people were faced with this machine that just wasn’t appropriate. You know, if they had had the choice, they would have picked something else.
Mike Amundsen: So that reminds me of the story you tell of about your work on IBM 650, didn’t you… That was acquired to do a particular job, right? But you ended up working on some airplane parts, right?
Mel Conway: Well, where I learned about the 650, we had one at Case and my first job in IT was as an IBM trainee. By the way, many of you may not know that in the ‘50s and ‘60s, IBM was the 800-pound gorilla. IBM was the combination of Amazon, Google, and a couple of others all put together in one, you know, and the word was… Well I’ll tell you that later. No one got fired for choosing IBM. And IBM was dominant.

So we had this IBM 650 which was their first computer. By the way, my first three machines were vacuum tube machines. This is a 650. The basic configuration was the central box plus a reader and a punch, a card reader and a card punch. The machine had a 2000-word drum memory. Each word was 10 digits or 5 characters. In order to get speeds, it ran at twelve and a half thousand RPM and it made this horrible squeal. And you just had to learn to live with that screech when you were an IBM 650 user.

So, how do people solve mathematical problems? Because my first job as a trainee was at Cleveland Pneumatic Tool which was building the landing gear for the Boeing 707. They would hog these big pieces of aluminum into cylinders, and struts, and things like that. And the 650 spent all its time chugging away at matrix inversions. Now, you got a 2000-word machine with just a couple of fixed point instructions, no floating point, no transcendental functions.

So the breakthrough was Bell Labs created a product called a Bell Interpretive System in which they took 1000, they took half the memory to build an interpreter and the interpreter presented to the other half a language of mathematics. Basically, a bunch of about seven, three-address arithmetic operations plus a whole bunch of transcendental functions plus floating-point arithmetic. And so in the other 1000 words, you can do a heck of a lot of mathematics.

So that was where I first saw the example of coming up on an intermediate, domain-specific language that totally enlarges the power of the solution as a whole. And that was one of the, that was one of the lessons that a powerful, intermediate, domain-specific language can massively enlarge the power of the whole system. And I’ve used that in about a half-dozen different cases.
Mike Amundsen: So that sort of goes to the notion of languages themselves and designing languages. There’s a couple things we’ve talked about before. You say a good application development language does not express algorithms.
Mel Conway: Yeah, okay.
Mike Amundsen: What is that about?
Mel Conway: Well my overriding concern for over 50 years has been simplifying application building. And one of the things I learned from the IBM world, the punch card world was that the people, the labor for that IBM had to move from the punch card world into stored programming, didn’t know anything about sequential thinking, sequential strategizing. These plugboards, this was an IBM 407 I think, which is basically a printer. All that haywire stuff was just mapping card fields on to printer positions. There was very little sequential logic.
Mike Amundsen: To just make sure, you had to explain this to me. This is kind of like programming. People would wire these up, the different colors and different lengths of wire, right, is that…?
Mel Conway: Yeah, the lengths denoted, the colors denoted the lengths.
Mike Amundsen: And then after wiring it up, you’d slide this into the IBM, in the slot in the machine?
Mel Conway: Right and every hole, there was a corresponding connector, a spring on the back. And each wire had a metal thing that stuck into the hole and then it made contact with the connector on the back. But the thing is there’s almost no sequence here. It’s all data mapping.

And so the IBM people, the workers in the IT shops didn’t know how to do sequential thinking. IBM invented this magnificent thing called RBG which basically permitted them, permitted these people to wire plugboards on a line-by-line text basis.

Mike Amundsen: Instead of the physical boards?
Mel Conway: Right?
Mike Amundsen: Are we looking at a microservice? Is that what this is?
Mel Conway: Well each of those half-dozen IBM machines was a microservice. There was a sorter, a collater, a printer.
Mike Amundsen: Right, yeah.
Mel Conway: Yeah and you built everything with it but those half-dozen machines. Yeah. Okay.

So the thing I realized at the time was that a lot of people don’t know how to strategize sequentially. So if you’re going to make application building available to a lot of people, you have to figure out what to do about algorithms. And I realized early on that static is good. In other words, if you’re going to make application building accessible to a lot of people, you’ve gotta eliminate algorithms. And so I came up with this notion that the purpose of an application construction language is not to express algorithms but to hide algorithms. And in other words, programming languages and application languages are two different species.
Mike Amundsen: I find that… like you had to kind of explain that to me again. That notion I think was really a surprise to me. Programming language and application development language are two different sort of different classes or different classes of things, right?
Mel Conway: Right.
Mike Amundsen: Yeah.
Mel Conway: And there are actually different classes of application. And the best language in each of applications is essentially static. And each class of application is defined by an underlying algorithm that is running at run time but the programmer doesn’t have to worry about it. That’s the idea behind the implicit run-time algorithm.
Mike Amundsen: So this sort of leads to the ‘80s when you were working on a project that eventually becomes Mac Pascal. So there was this sort of unique aspect to this and I’m gonna show the device. This is the device that you wrote. This was a Pascal Trainer, is that right?
Mel Conway: Well, this was a single-board computer that Rockwell built as a test environment because they were producing the 6502 chip which was a second source to I believe Motorola. That was the chip that got into the Apple too and Rockwell was the second source and they built this single board.
Mike Amundsen: This was a microcomputer, right?
Mel Conway: Yeah. It’s a microcomputer. The input/output was basically a serial IO. And it had a TelTech keyboard and a 20 or 40-character display and a strip printer. And this was how the people who were building hardware or using these chips developed their stuff.

Well I proposed to Rockwell that they needed a Pascal Trainer. By the way, the internal memory here was 4K Bytes of ROM. Now, there was also 20K Bytes of ROM. So you could build an interesting program but it would be fixed. Your data was 4K Bytes. So they bought the story that they needed a Pascal Trainer.
Mike Amundsen: You wanted to write a Pascal compiler, interpreter? What were you…
Mel Conway: Well the question was how do you do a Pascal thing in 4K of ROM. Well, the way it would have been done at the time, the only input/output device was an audio cassette recorder ,the kind you go buy at Radio Shack. And it was tape input tape output. So you key in your program, it writes it out on audio tape then you have a compiler. You read in the auto tape, you produce another file, you run the file, and you do the linking. You write out the object file, you run the file, and then you execute. This takes a half-hour or an hour and then you find out that you made a mistake.

So I couldn’t do that. I wanted immediate feedback. So I basically had to invent a way to have an instantaneous Pascal machine. And the solution was an internal representation of Pascal which was based on the syntactic, the formal syntax of the Pascal language, which was equivalent to the source language that was coming in but it was executable. It was basically a tokenized representation of the program. But you could translate back where you didn’t have store the source code. You keyed in the source code, it translates into this tokenized form. And if you wanna look at your source code, there’s a backwards translator. So there’s a forwards translator and a backwards translator. And as soon as you key it in, it executes or it can execute.

You get a couple of interesting things out of this. You get source code debugging. You get single stepping at the source code level. That’s all a byproduct of this idea of a single representation of the program.
Mike Amundsen: So you did this in 4K for this machine, what we know now of as this whole step-by-step compiling and all these other things?
Mel Conway: Right.
Mike Amundsen: And that leads to something else.
Mel Conway: Okay. Well, I had this Rockwell thing and I said, "Let’s try to put it on an Apple II." So I took my 4K ROMs and I put them on an Apple II board. And I monitored it in Apple II and I started carrying it around.
Mike Amundsen: You built the board, you wired the board?
Mel Conway: Well yeah, it was a wire app board. I was really into hardware at the time.
Mike Amundsen: Yeah.
Mel Conway: So I had a board with 20K Bytes of ROM that would plug into the Apple II and it became a Pascal Trainer. And we started carrying it around. And this was in '82 and I got an introduction to Mike Boich who was the product manager of the Macintosh two years before the introduction of the Mac. And we got out and we showed it to him and he looked at it and he said, "This solves the problem we have."

The AP computer science language had just been changed from Basic to Pascal. And Apple wanted to get the Macintosh into undergraduate computer science programs. They needed a Pascal. An instant turnaround Pascal was ideal for undergraduate computer science. So actually based on a contract with Apple, we got PC funding and we built Mac Pascal.
Mike Amundsen: And this is where this notion, this is where you get immediate feedback.
Mel Conway: Yeah.
Mike Amundsen: You have now, the distinction between the programming and the execution language is meaningless.
Mel Conway: Yeah, there’s one representation. I mean, internally, it’s 16-bit tokens. But you don’t know that because translating back, it looks just like what you typed in.
Mike Amundsen: So you’re hiding the algorithm as well with it?
Mel Conway: Oh, yeah, yeah.
Mike Amundsen: So that leads to this notion of what you called “humanizing the craft”. So Windows and Mac altered the programming landscape because now we’re also doing event-driven modeling, right? So when we finally get to Windowing, right, we have event driven to deal with. So how did that affect the way you think about programming.
Mel Conway: Well, in the early ‘80s, the introduction of a Mac and Windows totally blew away the programming community. Because they had to change their application model from stop and wait for the next input or that was the way they did interactive application. Or run the job to completion which is the way they did tape-to-tape applications.

Now, it’s an event-driven model where you do something and you don’t know what’s going to happen next. It depends on where the mouse click, where the next mouse click comes in. And there were a couple of years of pain trying to figure out how to write applications for this. And Microsoft built Visual Basic which was a very nice, user interface builder. Which basically got around that problem for building the UI by having a pictorial static description of the user interface. So there was a nice example of a static application building language but it was just for the user interface.

So, you know, I asked myself, “How do you do this for the whole front to back of an event-driven application?” And I realized that you ended up having to stop thinking about coding. You had to start thinking about… Instead of coding at the keyboard, you had to start thinking about the way a potter thinks. You have your hands on the work and the process of building an app is no longer input process output. It’s modify the working material in stages. So again, it’s one working material, single representation and you modify it in stages and you’ve got your hands on the work. So those are the two ideas. The modify the work, replace input process output by modifying the working material in stages and you need hands-on tools.
Mike Amundsen: So you told me that there is a story that involves Cheerios that got you sort of to this point. And there are two things about this story that amaze me. One is that is has to do with Cheerios but the second is that you tell me there are two ends of this that spanned 35 years in your own thinking.
Mel Conway: This was an epiphany that occurred in two parts 35 years apart. In the ‘70s, my wife and I were involved in the formation of two schools, primary schools and they were influenced by thinkers like Montessori and Cuisenaire. And the insight from people like Montessori in particular was the root to the brain is through the hands. Children have to learn hands-on. So that was nice. I learned that okay, that’s how to teach arithmetic in first grade.

Well 35 years later, I was watching my year-and-a-half-old [grand]son sitting in his highchair trying to grab a Cheerios from the tray of the highchair and get it into his mouth. And, you know, if you’ve watched babies develop, you’ve seen that this this is a real struggle. Getting the hand on the thing, getting the hand to the mouth, getting it in the mouth. And I had this epiphany that I was witnessing every human being executing the program that is built into the brain of building the hand-eye-brain system.
Mike Amundsen: You say this comes from the notion that the brain is actually built to build?
Mel Conway: That’s right. There is a theory that basically when a baby is born, what the brain has is not information about the world but information about building the brain based on experience. And the next couple of years are gathering experience to build the brain. Well, another idea here was that if I’m gonna eliminate algorithms and simplify programming or application building so that everybody can experience that that was an end goal. You know, the vision is everybody’s an application developer. Well that’s pretty revolutionary considering we’ve basically now got a priesthood.
Mike Amundsen: Yeah.
Mel Conway: But it turns out that there are three interesting models for moving from priesthood to primary school. There’s arithmetic, reading, and the calendar. There were all…they all started as properties of the priesthood and they ended up being taught in first grade. And it took centuries and it took revisions of the model and pedagogy and a lot of stuff. But I realized that the primary school child is the proxy for the whole population. So what I wanna to do… To think about the population is to think about how would you have a primary school child do application development.
Mike Amundsen: And that leads to these principles…
Mel Conway: Yeah. Well, the insight before that was when I saw my grandson struggling with the Cheerios, I realized that the way you’re gonna make application development accessible to everybody is to exploit the massive investment that nature has made in the hand-eye-brain system. That means hands-on tools.
Mike Amundsen: And another way you’ve said this before is that programming by typing is not a natural act.
Mel Conway: Yeah, coding at a keyboard is an unnatural act.
Mike Amundsen: Yeah, which reminds me of the Alan Perlis
Mel Conway: Yeah, he said the same thing.
Mike Amundsen: Okay. So yeah, it’s almost exactly the same thing and you worked with Alan, right?
Mel Conway: I did. Alan, on the 650, he built the first one-pass algebraic compiler. It was called IT, I-T, internal translator. And we went down to Carnegie where he was at the time and saw that. Brought it back to Case and started teaching numerical analysis using that using that tool.
Mike Amundsen: So software is child’s play. This is a project, a presentation, you’ve worked on it, and that’s kind of wrapped up in these six elements. Right?
Mel Conway: Well child’s play means how do you make application building into a hands-on process analogous to what a potter does at a wheel? And that raises the question what is a software tool. What does it mean for a hands-on, software tool to be hands on? And it turns out, I was building a prototype and by the way all this exists in…
Mike Amundsen: Right. We worked with it yesterday, right?
Mel Conway: Yeah. He’s my first user at least.
Mike Amundsen: I didn’t do so well the first time.
Mel Conway: Well, we didn’t have the time but I have a hands-on tool. It’s based on a model which is the flow model. I Tweeted about this and if you…yeah. It’s called software child’s play and you can… It’s a 40 -minute video which is about halfway through it, you start seeing demos. But in playing with this prototype and this occurred over actually a couple of decades, I started off with something very different. And this was a sandbox that I played around in. And I came up with six design principles for a software tool to be hands-on and that’s what these are.

This unity is one representation and also another idea, that is there’s no such thing is starting an application. Once you drag out the component onto the work space, it’s running.
Mike Amundsen: You have a live canvas. So when you drop something on, automatically it’s now the running application, right?
Mel Conway: Right. And you saw that when I dragged a window component out onto the work space, the window opened up. The window component wasn’t wired to anything but it was already executed. Okay. So that’s unity.

Transparency means the tool is invisible. You think you have you hands on the working material and of course that’s an illusion. But there are good examples of, namely, page layout and what’s Excel? Spreadsheets. Those are good hands-on illusions. Okay, so that’s transparency.

Continuity, it’s analogous to the mathematical concept of continuity, small changes produce small effects. That’s certainly true at the potter’s wheel. In software, you know, it’s a problem but… So the modification is small changes produce predictable effects. And immediacy means you get your feedback immediate. You see the user interface of the program you’re building, you see your work space. You make one change in the work space, the result shows up immediate. So you’ve got two things running at the same time that are tightly coupled.

Interactivity means you’re now… This suggests another way of building applications experimentally like a child with Lego bricks or a sandbox. In other words, and this is the opposite of waterfall. You don’t really know what you’re building when you start. You find out as you go along and that’s what interactivity is. You build something, you see how it looks, you either like it or you don’t. If you like it, you decide well now I know what I’m gonna do next.

And then reversibility is, we all know.
Mike Amundsen: Yeah. So one of the things that I experienced when we were talking yesterday, you and I at talked at some time, you were gonna build some tools and some components. It’s a kind of a componentized system. One of the things that happened over the space of the last few days is you’ve suddenly decided, "Oh, actually I don’t wanna build this whole shopping experience. I actually wanna build just a shopping cart.” So you needed a whole new set of components. How long did it take you to build those components?
Mel Conway: Well, it took a day. About 10 years ago, I built an app that would run on an iPad that would look like an order taker’s entry station at a restaurant. You know, I connected Microsoft Access to my tool. I entered the take-out menu for my favorite Italian restaurant and I built up a menu app on an iPad.

Well , Monday of this week, I decided, "Hey I’ve got a shopping cart component in there. I think I’ll turn this into a shopping cart." And I refactored the thing in a day, just basically by removing wires, moving things around, and reattaching.
Mike Amundsen: It’s through this immediacy and interactivity and unity that made that something that you could actually build in a day.
Mel Conway: Right and I built it experimentally. You know?
Mike Amundsen: Sure. Yeah. I think that’s the other thing we talked about before is this notion that when the cost of an experiment is not so high, you’re more likely to do that. This goes back to your experience with government where big waterfall often meant, I set my budget the first day, right? So that meant changes in the future could really be a risk, right?
Mel Conway: Yeah. But, it turns out there were two things I discovered in the Air Force that were really deadly. Deadly incentives for software agility. One is that you got a budget for the project at the beginning and that determines the size of the organization. And the other is empire building. Management empire building which…and both of them tend to enlarge the organization which means you’re ruling out really interesting designs.
Mike Amundsen: This goes back to the thing you were talking about in the beginning about as soon as you make a choice, you’ve ruled out a series of possibilities, right?
Mel Conway: Yeah, I may not have said this in so many words but every design choice rules out some… Every organization choice rules out design choices. So how are you gonna build the optimum system? You’re gonna build it with a flexible organization, experimentally. You can build something and somewhere down the road, you’re gonna realize what you should have built. In Brooks’ parlance, plan to throw one away, you will anyway.
Mike Amundsen: Right. And second system effect applies here as well, right?
Mel Conway: Yeah, right.
Mike Amundsen: The idea that the second system is always way overblown. Right?
Mel Conway: Right. About the third time around you get to do it right.
Mike Amundsen: Then you can get it. So you need to get to that third time quicker, right?
Mel Conway: Yeah, right.
Mike Amundsen: Does anyone have…we have a few minutes for some questions. Does anybody have any questions for Mel, anything at all? Yes.

Audience Question: So which one is your favorite programing language [inaudible 00:35:20].

Mel Conway: Which one is what?
Mike Amundsen: Which is your favorite programming language?
Mel Conway: That’s funny. I kinda like JavaScript these days.
Mike Amundsen: You’ve been working to rebuild the application you started 10 years ago, this interactive thing you talked about. You’ve been working to rebuild it with JavaScript, right?
Mel Conway: Well just the user interface part. I’ll tell you. You know, this, I look at my prototype now. I think of it as an archaeological site. It’s layers and layers of abandoned garbage on which you try to build some kind of a structure, you know? An it’s sort of…
Mike Amundsen: So will we find the Roman ruins somewhere down in, yes? Right?
Mel Conway: Yeah. Well, so I decided, you know if this is ever gonna be ready for primetime, you’re gonna have to start from scratch. But I’ve got the… I know how to do it now but I’m not gonna do it with that thing. So the question is what language do you do you use for the whole system and I see two languages emerging one is Go and one is Node.
Mike Amundsen: Yeah.
Mel Conway: I don’t know but..
Mike Amundsen: Who knows? Maybe you’ll get both.
Mel Conway: Yeah, right.
Mike Amundsen: Any other questions, anywhere? Yes.
Audience Question: So not seeing the software with the child video, did you see Apple’s Swift app that they had on iPad the other day? And is it something like that where you’re kinda like drag and dropping and learning programming that way?
Mel Conway: Well the short answer to your question is no. I may have seen it but I don’t recognize it by that name. My model is a wiring model. Components are sort of little object-oriented functions. It’s all unidirectional flow. The connectors on the left are inputs. These connectors on the right are outputs. The database is over here. The user interface is over here. Everything goes from left to right.
Mike Amundsen: When I was working with you yesterday, I never typed any code. I may be typed some data elements but there’s no sort of code lines to type here, right?
Mel Conway: Yeah. You use the keyboard to parameterize things like, "What text do you want in the title bar of this window?" and that’s about it.
Mike Amundsen: Yeah. One more, we have another question, anything ,yes?
Audience Question: So from an organizational prospective, you know, trying to get back to microservices, would you briefly explain how you think your law applies to a microservices architecture? Does that make sense?
Mel Conway: Yeah and my short answer is no, I can’t. You know, everybody else on this program has really much wiser words on this subject than I do. I basically do research. I’m learning a lot from you guys. And, you know, I’ve asked myself this question, “What is what I do related at all to what you guys do?”

And it occurred to me just today that the model for this is Clayton Christensen’s book, “The Innovators Dilemma” in which he described the model of the disruptive technology and how it works its way into the mainstream. By finding a niche apart from the mainstream where the big guys don’t even see it until it becomes mature enough. And then it just sort of metastasizes. And, you know, I’m at the disruptive technology stage at this point. You guys are the engineers.
Mike Amundsen: So do you have any sort of last words, warnings, advice? We talk about these things, this notion that static is good. This sort of leads me to this idea about domain languages or that there are instances of these where there’s sort of an optimal kind of solution, right?
Mel Conway: Well yes, and generally the solution that’s going to be useful for the most people for a given application domain is gonna be a static language.
Mike Amundsen: And that also then relates to the notion of hands-on? Like one of the other things that’s really important to you is this idea that it’s actually you have your hands on it rather than someone’s [inaudible 00:39:52].
Mel Conway: That’s part of the illusion of, you know, making it available to the first grader because the root to the brain is through the hands.
Mike Amundsen: And that’s why you do transform in place. That’s why you don’t want input process, output process like those cards?
Mel Conway: I can’t…I don’t know how to do input process, output hands-on. You know?
Mike Amundsen: Right.
Mel Conway: I never figured that one out which is why I forced myself. I said, “What am I gonna do now?” Because all we have are compilers, you know, that you have an input file and you have an output file, linkers, etc. and it just doesn’t work. So then I started thinking about artisans and the potter at the wheel came to mind.
Mike Amundsen: And that’s where you have these principles. So these six principles, I mean they’re not recent, right? They’re actually really all of your experience over all these years has led to this set of principles.
Mel Conway: Yeah. Actually, I wrote a patent. The reason I patented the Flow model was because I couldn’t show my prototype to any corporation because, you know, when to try to sign in at the front desk, there’s a little form that says, “Anything you tell us belongs to us unless you’ve had prior disclosure.” So I had to write a patent just to patent this idea.
Mike Amundsen: So you worked several years to write the patent.
Mel Conway: That was in '96. You know?
Mike Amundsen: Right, yeah.
Mel Conway: So I’ve had 20 years to think about this. And that’s where the hands-on stuff came in.
Mike Amundsen: So, sort of this gentleman’s question. This idea that we’re now in this sort of distributed component world. We’re in this world where I need to pay attention to things that are installed in many places on AWS, in the cloud, and so on and so forth. Can what you’re doing, can what you’re working on be applied in that kind of sense, in that kind of distributed space?
Mel Conway: That’s the question I want to answer. That’s my next role is to figure out how to take this desktop thing and make the run time be the web. Yeah.
Mike Amundsen: So it’s this notion of interactively creating systems that span distance in the same way that I might have thought about creating something for [inaudible 00:42:13].
Mel Conway: Yeah. Without abandoning any of the hands-on principles and without abandoning the modify in place model, how do you build distributed applications?
Mike Amundsen: And that’s what you’re going to have for us the next time we’re together, right?
Mel Conway: That’s today’s job, yeah.
Mike Amundsen: All right. Well, thank you very much. Thank you very much, Mel. It’s been great talking with you. Ladies and gentleman.
Mel Conway: Thank you.