Dreaming in Code | Scott Rosenberg | Talks at Google

Hi everyone, I'm Karen Wickre and I'm very pleased to introduce our guest, our author today. Scott Rosenberg, who's been chronicling the Internet for a long time, is a co founder of the esteemed content site salon.com. much of his material is available. And now this book, Dreaming in Code, which I think is a cautionary tale and a good one for us to hear about. Scott will be talking for about 40 minutes. He'll take questions and then if you want to have your book signed, please wait around. We'll either do it right here or if we have to move, we'll step over to the side. So please welcome Scott. Thank you. Thanks, Karen. Is the level good? Everybody hear me well? Great. Well, let me tell you a little bit. Just quickly, the agenda, my talk. I'm going to tell you a little bit about myself and Dreaming in Code, how I came to write it. Little bit about Donald Knuth's statement, software is hard. Why is that? A little more about communication and miscommunication on software teams. And finally, questions now. Oh, sorry, not ready for that yet. I'm assuming that I'm talking to a lot of developers here, but it would be helpful for me to know how many of you are developers so can get a show of hands. Okay, great. So my first confession is that I'm not a programmer. I did study BASIC as a teenager many years ago in the 1970s and. Okay, now it's time for this slide. Some of you may be familiar with Edgar Dijkstra's statement about basic. Said if you learn BASIC as a potential programmer, you are mentally mutilated beyond hope of regeneration. Now, some programmers I talk to agree with this, others disagree. But I have to say, in my case, I think he had a point. So there was this BASIC game that I loved called Sumer. Here's some of the code. It was kind of like an ASCII based text based SimCity, little cruder. Put you in charge of a city on the Tigris and the Euphrates. You had to make sure that the inhabitants had enough food and were safe from invaders and didn't kill one another. I'm sorry, I don't know how this slide got in here. Excuse me. So I would write subroutines for Sumer and I noticed that strange things happened to my sense of time as I did this. I would disappear into the physics building at NYU in Greenwich Village where they were giving out free accounts to high school students like me on the HP3000 minicomputer. And I Would look up hours later. It was the middle of the night. I hadn't noticed the time passing. I was in that state that psychologists call flow. And it felt great. As for what I was accomplishing, well, this is the only remaining code that I wrote in that era. Take a look. This is written on an Olivetti manual typewriter. And you can see there was no less than sign. So I had to kind of invent a little shortcut there. There was obviously no delete key. So there we go. I don't know. This does not clearly even qualify as spaghetti code. I don't know what you would want to call it. I think of it as a kind of gruel. So I became a writer and editor. I worked as a theater and movie critic for many years at the old San Francisco Examiner. I always had this sort of closeted geek side too. And in the early 1990s, I began to notice that the world of the artists that I was writing about and the world of geeks was sort of converging. And I began to write about that too. Now the web came along, and I immediately knew it was what I wanted to do. As a kid, I published mimeographed gaming magazines. You can tell this is mimeo because of the bleed through, and this was the web. Felt to me like almost the same thing, except you didn't have to worry about folding the paper and collating it and stapling it and putting the stamps on. So I joined a group of colleagues from the examiner and we started Salon. Now, at the beginning, we were really only vaguely aware that publishing on the web might actually involve a little bit of technology. Took us several years actually to learn that lesson. And finally, in 1999 or so, we'd figured it out and we started work developing a content management system as the geekiest member of our editorial team. I wound up as one of its managers. And it turned into a classic software disaster. It was a sort of a death march. And once again I found myself up all night. Time stopped. But this time it was not fun at all. And when the. Oh yeah. Well, we charged into this incredibly complex situation with little knowledge of the history or the scope of the problem. And we were just paralyzed when things went from bad to worse. I am so sorry. Okay. After the dust settled, I said to myself, okay, I'm really ignorant about this stuff. I don't know about it. The last time I wrote code was in ancient times. But other people must have figured it out. Can't be that hard. So I hit the books. I started reading. And it didn't take long for, for me to figure out that in fact, though there were plenty of people who knew more about it than I did, that it's not really a simple problem at all and it's not a solved problem. There are plenty of ideas out there. I know that here at Google there's a lot of exciting stuff happening. Nonetheless, no one has produced the one true way of developing software and I thought could make a really interesting book. So I started working on Dreamy Encode in earnest in about 2002. Now, this was a time, you may recall, that the Internet bubble had burst and a lot of people in the mainstream media were sort of sighing with relief. It was like, thank God we don't have to think about all of this computer and Internet stuff anymore. Well, I knew that was crazy. I knew I was familiar with Bjarne Stroustrup's line, our civilization runs on software. And I knew that it was true. Our civilization does run on software. But everywhere I looked, the people making that software were having a really hard time. Why was that? Now, I've always been a journalist and not a theorist. I believe in telling stories and that that's a good way of getting at the truth. Here's one of my favorite storytellers, Spalding Gray. Stories are powerful. They're sort of like consciousness compression algorithm. And my first instinct as a writer about software was to tell some stories. I thought I'd go out and find a half dozen projects and I'd weave their stories together and use that experience as a way to get at some of these questions I had. Well, about that time, it was fall of 2002, I read a column by Dan Gilmore in the Mercury News talking about a new project by Mitch Kapor, creator of Lotus. 1, 2, 3, way back in the 1980s. His new project was called Chandler. It was going to be a new model personal information manager. It was going to be open source and peer to peer, and it was going to help people cope with information overload. And I thought, great, this will be my first project. I called Kapor up, I told him about my book, and he had two things to say. One, sounds like a good idea for a book. Two, my project, he said, is too atypical. It's not going to be a good subject. For one thing, it was going to be design driven. For another thing, the organization that was sponsoring it, the Open Source Application foundation or osap, was not for profit. He was funding it himself. And I thought, actually that makes it even more interesting to Me, too often, I find the whole subject of software is viewed through exclusively a business lens. Now, people do understand money a lot better than they understand programming, so it's understandable. A lot of the time, the story of software becomes this thing that begins with the acquisition of venture capital and ends, if you're lucky, with an ipo. It's almost like the way old movies handled sex, where you would see the romantic couple embrace and then there'd just be this fast. Cut to the next morning. Your eyes were averted from everything in between. And writers seem to treat the act of programming in a similar way. I don't know, maybe they think it's too complex, or they're worried that it's going to be boring, or they think that it doesn't matter because it's just plumbing. Well, to me it was fascinating, and I just thought that the fact that Chandler was not profit would let me tell a different kind of software story. So Kapor let me come down to his office and sit in on some development meetings. They were in Belmont at the time, just up the peninsula. And before long, I found myself living and breathing Chandler. In addition to the meetings, there were mailing lists and blogs. There was a wiki that kept growing and growing, and then later there was CVS and Tinderbox, and you could keep up with the wiki via email or rss, and you could have CBS send you email too. So Chandler was supposed to help you cope with information overload. But for me, it was starting to cause information overload. And I realized very quickly that my original idea of six projects, weave it Together, wasn't going to work. It was insane. I didn't have enough time, and it wouldn't be fair to say expect readers to follow that much detail. I also realized that one story was going to be more than enough to cover the topics that I wanted to cover. Everything from Frederick Brooks and the Mythical Man Month, the history of software disasters, managing software teams, choosing tools and methodologies, communication between programmers and designers, the unfulfilled promise of reusable code, and most important of all, the problem of scheduling software, of knowing how long things are going to take. Working on software does really strange things to time. When I first visited the Chandler team, they were supposed to release a first version of their program in about a year. So I immediately doubled that. I figured two years. After three years, as the deadline for my book began looming, Chandler still had a long way to go. The team kept scaling back some of their ambitions and features in an effort to tame their schedule and they were targeting the end of the year at that point. It was 1990. I mean, sorry, 2005, but there was no way to say with any reliability when the project would really be done. And that left me with something of a dilemma. How could I end my book before the story was over? Now, I'll let those of you who decide to read the book find out for yourself exactly how I solved that problem. But for those of you who've studied computer science, I'll tell you, it has a little bit to do with incompleteness and the halting problem. Now, it's natural to look at this story and say to yourself and think, you know, this is really just the story of a team that did a really bad job of estimating their schedule. And that's true, but it's kind of amazing how often that happens. It happens on big government projects all the time. It's practically the default there. And it happens all the time at some pretty big software companies, too. Windows Vista is kind of the example in the news today. So when programmers hear about Chandler and say to me, you know what? That's just a bunch of losers. I'd never do that, I say to them, hold on a minute. Can you really tell me that you've never been on a project that started out with an amazing set of ambitions and then had to scale back and found that everything was taking a really long time? To me, I don't know, the projects that I encounter, that seems more to be the norm than the special case. Now, there isn't a lot of good data about success and failure in the software field. The Standish Chaos Report is the most commonly cited set of figures. You may have even seen this before. Quickly, they say, only the original 1995 numbers. 31% of projects fail, only 16% succeed. Their definition of success is on time and on budget, with all features and functions as initially, specifically. And then there's the rest of it. More than half in this category of challenged. I love that word. By it, they mean significantly over budget or late or reduced in scope. 2004, we see a little bit of improvement, but it's still a pretty bad picture. Now, there are people today who are criticizing the Standish Report, criticizing its methodology, because they are not actually sharing that methodology. I think that's a good point, but I think however you look at it, this is not good news for the field. Now, there are developers I talk to about this who just take issue with the assumption behind it, and they say, why should we expect software to be different from building any other complex thing, it's always difficult. Now, I do think there are differences. Let me review some of them from a fairly high altitude here. First of all, software is, at heart, completely a human construct. It's artificial. One question that comes up all the time is, why can't we build software the way we build bridges? Bridges are human constructs, right? But a bridge, after all, is built with molecules in the physical world that can be reliably assumed to obey certain laws of the physical world. Software is something that is made up of parts that we made up sitting on top of layers of other parts that we made up all the way down in this. In some ways, it's more like a work of fiction than nonfiction. We write it, and we make it all up. In his great book, the Mythical Man Month, Frederick Brooks wrote, the programmer, like the poet, works only slightly removed from pure thought stuff. He builds his castles in the air from air, creating by exertion of the imagination. So software is almost pure thought stuff, a product of the imagination. There's this dream that software engineering can evolve into a mature discipline and take its rightful place next to chemical engineering, mechanical engineering, so on. And program building could become more like bridge building. Well, that sends me to a quote from Peter Deutsch, who says, it's very difficult to have real engineering before you have physics. And there isn't anything even close to a physics for software. So if software is actually an arbitrary product of human artifice, then the quest for its physics, for first principles may be impossible. So we make it all up. But there's one other condition, and it has to work. It's an interesting combination. Now, my background, as I said before, is in theater. And one of the great plays about creation is Ibsen's the Master Builder, not performed much anymore. In it, the lead character, who is a successful but aging architect, has this encounter with a mysterious young woman from his past. And she keeps urging him on to build castles in the air. But he's an engineer. And so every time she tells him this, he responds, yes, but with solid foundations. Now, I used to hear this, and I would go, what? What is he talking about? Now that I've spent all this time studying software, I think that's actually a great way of thinking about the paradox of software. On the one hand, it's a castle in the air. It's something that we make up. On the other hand, it needs a solid foundation, has to work. So that's one big area in which software really is unique. I think. Here's Another, it's extremely hard to visualize a complex program and that has practical consequences. We can't really touch it. We have a hard time measuring it in any useful way. Yes, there's lines of code, but I don't think that really helps us very much. There's feature points, but we're usually dealing with apples and oranges. There's unfinished versus done. But when is a piece of software really finished? It's very hard even to talk about software. And I'll be addressing this in a more fuller way later in my talk. So measuring software is really hard and talking about it is really hard. And we gather around whiteboards and we draw boxes and arrows and we kind of cross our fingers and hope and pray that those boxes and arrows mean the same thing to the other person that they mean to us. Now, I know that there are lots of developers, I'm sure maybe most of the developers here at Google, who kind of hear all this and say, yeah, all right, but you know what, we do everything on the web today and that solves our problems. And I'd agree with that up to a point. Web based systems do solve one set of problems. You probably know all this already. I'm going to just kind of race through it. End users are really bad system administrators, so manage their data for them. Patches and updates, very easy to do because you do them yourself. The browser solves all of your cross platform issues. You don't have to reinvent the user interface each time you do something. And the web keeps you close to your users so you know what's working and what isn't. Well, that's great. Hooray. But moving to the web also introduces a whole new set of problems that we really didn't have in the old days. First of all, the system depends on network connectivity. The browser represents a whole new point of entry for malware and bad actors. And we end up with headlines like this on the front page of the New York Times. Attack of the zombie computers. I just love that, you know, you're handing your data to somebody else. So you start having some privacy concerns and you think that cross browser development is much easier. But the more fancy stuff you try to do, the more you end up with trouble with oddball users like me who insist on using weird browsers like Opera because they are less vulnerable to all of that malware. So it gets a little more complicated. More important though, than any of these specific problems, I think, is a larger point. It's really at the heart of my book. And so I Want to go into it a little bit more. I'm convinced that web based systems really are the future. I don't doubt that. And it's possible precisely because web based computing solves a bunch of problems the previous generation of software had. So as a result of this, we're going to ask these web based systems to do more and more. A lot of that is what you're doing here at Google. And at some point I think we'll probably go too far. We'll start out amazed by all the new capabilities and will end up being made miserable by their limitations and flaws. And then the software industry will move into whatever its next phase is going to be. I don't believe that this dynamic is a function of immaturity in the field. I think it's inherent in the nature of software. We had a version of this discussion a few years ago when Nick Carr wrote his well known essay It Doesn't Matter for the Harvard Business Review. Carr argued that it doesn't matter anymore because everybody has it. It won't provide your business with a competitive edge. It's really all just this kind of holding pattern where you have to accept you're going to spend a lot of money on software, but you should try to spend as little as possible. I think CAR was right up to a point. It's true, but only if you believe that you fully mapped out the universe of things that you want your software to do. Going to read a short passage from my book here that addresses this a little bit. It doesn't matter as long as you know in advance that the things you expect software to accomplish for a business are not going to change, and that your competition is using software to accomplish the same set of things. But of all the capital goods in which business invests large sums, software is uniquely mutable. The gigantic software packages for customer relationship management and enterprise resource planning that occupy the lives of the CTOs and CIOs of big corporations may be cumbersome and expensive, but they're still just as much as the little spreadsheets that Mitch Kapor and Dan Bricklin introduced to the world a quarter century ago. Made of thought stuff. And so every piece of software that gets used gets changed as people decide they want to adapt it for some new purpose. No sooner do you introduce a new system for employee surveys than the light bulb goes off over somebody's head, hey, why can't we turn the same system into a tool to schedule our company parties? All it will take is a few tweaks. And while they're at it. Maybe the development team will build in a nifty way for me to catalog my music collection. Then we could vote on the music that we're going to play at those parties. Have we already discovered and deployed all the usefulness, and yes, all the frivolousness too that software offers to believe so seems not only arrogant, but actively ignorant of recent computing history. By the mid-1980s, for instance, business analysts were writing off the entire personal computer industry as mature and over the hill. Just as the new wave of Macintosh and Windows style graphic interface systems was building in the early 90s, Microsoft was beginning to dominate the PC software industry and the conventional wisdom was that the entire business was consolidating. Yet the Internet was about to kick it in new directions. In 2000 and 2001, with the collapse of the Internet bubble, many observers were ready to declare the entire Net based software industry dead and seal the coffin. But right around the corner, Google was growing and helping to gestate a whole new wave of online businesses over and over. Those who have bet that there can be nothing new under the technology industry sun have lost their shirts. To believe that we already know all the possible uses for software is to assume that the programs we already possess satisfy all our needs and that people are going to stop seeking so something better. But as long as we keep asking software to accomplish new things and solve new problems, fixing today's bug still won't protect us from tomorrow's crashes. And although software methodologies are very helpful when you want to repeat a success, you can reproduce an outcome only if you have one to start with. If you're exploring unknown territory, best practices might help you move a little more quickly, but they're not going to point you to to your destination. Now, as I was reading up on software, I found, as some of you may have noticed, that virtually every single person who's written about software has ended up creating a law under his own name. And at a certain point in my work I thought, you know what? If I'm going to come out of this book with anything, I'm going to come out of it having created Rosenberg's Law. So with all due humility, here is Rosenberg's Law. Software is easy to make except when you want it to do something new. And of course there's a corollary, because there's always a corollary. The only software that's worth making is software that does something new. So I think you've gotten a taste of what dreaming in Code is about here. I should Also add that there are a lot of dogs in it. The OSAF office was full of dogs, so it's not all code. In my remaining time, I want to focus on one of the book's themes and extend it in a new direction. One heart of the software problem is communication. I think there's a bunch of different kinds of communication involved in any software project. There's communication with the computer, which is what you do when you write code. There's communication with the user, which is what you do when you create a user interface. There's also communication among the people who are creating the software, and that often seems to be the hardest and the most difficult. When a group of people works on a program together, they have to agree on a set of names. Names for variables, names for controls, names for everything. Like Dilbert's manager says, 90% of this job is for figuring out what to call stuff. So here is my one other passage from the book. This is all about the Chandler teams wrestling with names. As osaf's developers struggled to transform the innovations in Chandler from sketch to functioning code, they repeatedly found themselves tripped up by ambiguity. Over and over, they would end up using the same word to describe different things. Take item. To the designers, an item in Chandler was anything a user thought of as a basic piece of data. A single email, an event on a calendar, a task, or a note. But the back end world of the Chandler repository also had items, and its items were subtly but substantially different. A repository item was a single piece of information stored in Chandler's database, and in fact you needed many of these repository items to present a user of Chandler with a single user item, like an email. At different times in Chandler's evolution, proposals arose to resolve this problem. To disambiguate the word item, maybe the term user item could always be capitalized. That helped in written material when people remembered to do it, but not much in conversation. Maybe another term for one or the other type of item could be adopted. But some of those proposed like thing were even more ambiguous, and none of the proposals stuck. The Chandler universe was rife with this sort of word overlap. The design team kept using the term data model to refer to the list of definitions of data types that users would encounter, along with all the attributes associated with that data type. For example, the data model would specify every note, had a date created, an author, and a body text. But to the developers, data model referred to a different and more technical set of definitions that they used to store and retrieve data at the level of their code. Then There was the problem with the term scheduled task. In the design world, a scheduled task meant an item on a user's to do list that had a date and time assigned to it. But for the developers, a scheduled task was something that Chandler itself had been told to perform at a particular time, like download email or check for changes in shared information. Kapor would observe these little linguistic train wrecks and shudder. We need to speak one language, he would say. We should all speak Chandlerese. We have to fix the vocabulary. Finally, Brian Skinner stepped forward to try to do just the that. Skinner had a knack for explaining developer speak to the designers and design talk to the developers. When the groups talked past each other, he was often the one to sort out the language. Why not? He proposed set up a Chandler glossary on the wiki. It would provide a single, authoritative, but easily amended reference point for all the terminology. Skinner took up arms against the stage sea of ambiguity. He produced dozens of glossary pages. He built a system for linking to them from the rest of the wiki. It was a heroic effort, but it didn't seem to make much difference. For one thing, usage of the terms continued to change faster than his wiki editing could keep up. More important, the developers, who were already drowning in emails and bug reports and wiki pages, didn't seem to pay much attention to the glossary. And the pages languished, mostly unread. The glossary's futility might have been foreshadowed by the outcome of another naming effort in which Skinner participated. OSAF's Howard street headquarters had a half dozen conference rooms, and Kapor decided it would be useful for them to have names. The organization held a contest and solicited proposals from the staff. Skinner suggested using names from imaginary places. He won the contest. The two main conference rooms became Avalon and Arcadia. The fanciful names captured the spirit at osaf, where imagining new worlds was on the collective to do list. It was only later that everyone realized what a bad idea it was to have the names of the most frequently used rooms start with the same letter. No one could ever remember which was which. So we can probably do a better job in the area of human to human communication, but it will never be perfect. There will always be errors on that line. But unlike in the world of network protocols, people are capable of finding value in these errors. That's what I want to talk about here. Towards the end, we misunderstand something and and find something else that pleases us. There's a great novel about programming, Ellen Ullman wrote, called the Bug. If you don't know it, I highly recommend it. In this book, she has a great passage that riffs on the command in C called Malloc. Now, those of you who are programmers know Malloc. It's about allocating memory. But to non programmers like me, when they hear this, it sounds like some kind of biblical incantation of evil. Moloch. If you're not an expert in a particular field, you hear stuff differently. When I was a teenager in the 1970s, one of my favorite albums was the Grateful Dead's Live Dead. It has this song on it called the 11. Now, at this time, I was reading a lot of Tolkien. If you know the Lord of the Rings, you know, there are these groups of people who have rings and they're called like the three and the. The five and the seven. For some reason, it's all odd numbers. And so I heard the 11 and it just sounded magical to me. Years later, I discovered what the song title really meant. It's a reference to the song's unusual time signature. Instead of being in 4, 4 time like a March or 3, 4 time like a Waltz, it is in 11, 8 time. And so the title was really just musical shop talk. And I was projecting all of this poetry onto it. My point is, when we misunderstand one another, sometimes we please ourselves and sometimes we even come up with useful new ideas. We rip something out of its original context and find a new path to some desired goal. Misunderstandings can be viewed not as bugs to be eradicated, but as accidents that can enrich us, and we should try to stay open to them. A few weeks ago, the Wall Street Journal's Lee Gomes interviewed an expert at Stanford on the history of semiconductors in the early days. And so I really love this story. I want to read just a little bit of it to you. I'm quoting Stanford Professor Thomas Lee. He said William Shockley had been given a very vague mission to find a solid replacement for vacuum tubes. Starting in the 1940s, Shockley and and a band of stalwarts worked on the problem. But they failed repeatedly and spectacularly. So they switched gears and said, what are the reasons for our colossal ignorance? One of Shockley's employees, a guy named John Bardeen, designed a series of incredibly brilliant experiments to diagnose their failure. One of the experiments turned out itself to be capable of amplification, just like the vacuum tubes they were trying to duplicate. So the initial transistor invention was something they stumbled on while they were trying to diagnose their earlier Failures to invent a transistor. Now, transistors replace tubes everywhere, right? Well, not quite. Electric guitarists love vacuum tubes. There's particular warm kind of distortion that they create. Distortion is another one of these happy accidents. Distortion is signal degradation, Right? It's a bug. A good amplifier is one that will have very low distortion. Except that in the early days of the electric guitar link, Ray discovered that actually distortion sounds great. And he. And then later Ray and Dave Davies of the Kinks, they started poking pencils through the cones of their speakers to get a better distortion sound. So one man's signal degradation was another's beauty. Your bug can sometimes be a breakthrough. I don't know if any of you here read the article. It was a week or two ago in baseline about MySpace and the development efforts at MySpace, but I found it fascinating. If you know MySpace, you know that one of its most popular features is the fact that the service will let you make your page look as ugly as you want it to be. And people love this. And it turns out that this was not the intention of the developers originally. What happened was that when they first launched, they had forgotten to include the code that would filter the formatting out of the user's input. Well, see, what happened on MySpace, that's a bug that you're not going to fix. People love it. In fact, it's, you know, it's part of their success. And so, you know, we all have heard the joke about, you know, it's not a bug, it's a feature. Well, might be interesting to think of that not as a joke at all. Where would that take you? I kind of wonder if the world of software developers would do the equivalent of poking pencils through their speakers a little more often. Where that might take us now, Brian Eno, the musician and producer, he says that when he gets a new device in the studio, he doesn't read the manual because he doesn't want to only know what the people who created it intended the device to accomplish. He wants to figure out all the things it can accomplish. In essence, he's taking tools and products that were offered as scientific entities and treating them as artistic media. One theme of Dreaming in Code is this whole question of whether making software is really more of a science or an art, and plainly it's some of both. Eno has something useful to tell us about this. He calls it Eno's Second Law. I don't know what the first law is. Science is the conversation about how the world is. Culture is the conversation about how else the world could be and how else we could experience it. He goes on to say, science wants to know what can be said about the world, what can be predicted about it. Art likes to see which other worlds are possible, to see how it would feel if it were this way instead of that way. As such, art can give us the practice and agility to think and experience in new ways, preparing us for the new understandings of things that science supplies. So to me, software is plainly right in the middle, a kind of a bridge between art and science. When it works, it takes a little bit of a newly imagined world of possibility and injects it back into the scientific world as is. I think that's a pretty important undertaking. It's certainly more, much more than just plumbing. It's worth the effort to keep trying to do better, even as we know we'll keep falling short. So thank you for coming. Coming. That's the end of my presentation, but I'd love to have some questions and answers. Yes, I will. Any thoughts? Tales from the Front Everyone here has had projects on time and without difficulty. Yes. If it's turned every project that fails can fail in a completely different way. Whereas successful projects tend to be successful in only a couple of ways. Do you feel like just by examining one failure? So the question is every project that fails fails in a different way. And was I able to extrapolate from this or should I be extrapolating from this one project? First of all, I should say I don't actually consider it a failure. I still think the jury is out on Chandler. It's true, it's taken them a really long time. My comparison is to Mozilla there. I was one of many journalists who after a couple years kind of wrote Mozilla off. It seemed like they were lost in the wilderness and nothing was ever going to come of them. Put. But in fact we now know. Look at what happened several years later after everyone wrote them off. Firefox is a pretty important product, so I'm not prepared to write Chandler off as a failure at this point. However, as far as the rest of the question, the book actually though it uses the Chandler story as a narrative that runs through, has all kinds of side trips and I do try to bring in a lot of history, a lot of little bits and pieces of other writers and other develop thinkers in the software field. So I try to generalize a little more. Any other questions? Yes, please. I'm curious, what's the difference in response to the book from people who didn't have a Computer science background versus people who does. Computer science background versus people who do. Yeah. So the question is, am I hearing a different reaction to the book from people who have a computer science background as opposed to people who are more. In the field, practitioners? I have to say that to this point, most of my engagement has been with people in the field. I'd be very curious to hear more feedback from people who are more theoretical, but I don't have that much to go on. People in the field I seem to get seems to break down into two basic groups. One who says, gee, you're telling the story of my life, and the others who say, you know what, all these problems, I don't have them, why should I care? And to those people, it may be that they don't have them and shouldn't care, but it may be that they just haven't been in. I was going to say the right place, but maybe it's the wrong place. Yeah. And back there. Oh, wait for the microphone.

Hi. I came in right at the very end, but I asked someone and they said that you hadn't brought this up yet. So I want to ask. So you've just made this comparison between science and art, and. And I support that. I really think that that's a very solid comparison. And in the past, when I was going through computer science in school, I really noticed how I wrote programs and did assignments that were about what I was going to produce and whether or not it was correct. And in my electives, I was forced to read very large quantities, quantities of other people's poetry and writing. And I've never, either in school or in my work experience, been exposed to a situation in which I was expected to consume code. Now, refactor code, understand code I had not previously seen. Always, always I was being brought to code with an element of agency, the opportunity to invoke change. Never was I brought to code as an appreciation of culture, an appreciation of the art behind what's going on. How do we bridge to a situation in which we treat it as art, which must necessarily involve a large portion of consumption, being part of our culture?

Yeah, it's a great question. I don't need to repeat it because of the mic. So there's a guy named Dick Gabriel who's written a lot about this. I actually quote him in the book. And he was a programmer who went back to school and studied poetry. And he said, you know what? As a student of poetry, I am learning much more. My work is being examined much more rigorously by my peers. And by my teachers than it ever was when I was a programmer. And he says, and I think there's a point to this, that one of the big problems, one of the field, is that so much of the work is under lock and key. So in a world where open source is still kind of an insurgency and not the norm, most code is not available to be studied. So you can't have the great works of the field available. Gabriel says it's like imagine that Moby Dick belonged to one company and Shakespeare belonged to another company, and if you worked for the wrong company, you couldn't read the other classics. And to me, clearly, if you're going to build a shared culture around programming artifacts, the artifacts have to be available. So in that sense, I think the open source approach is a good direction.

I'm familiar with the response that you've given. I've heard many people give it before. I largely reject it for a simple reason, starting with school. In school, I'm not held to those rigorous peer standards. I'm not expected to read the assignments that my peers turn in. I don't know of many programming schools in which this is different. Maybe there are. Maybe you got lucky and you went to one. Right. But in corporate world, in any form of software engineering that I have seen, any development methodology that I have seen, I have not seen one in which a portion of the time is given over to the consumption of code written by some other portion of the development team, where you do not have the element of agency. The idea that you should just be reading what your peers are writing and commenting on it, even if it's not on your series of timelines. We don't do that as a culture. And it's not because it's locked up. I mean, we have very large code repository here. And I'm not expected as part of my job to be reading and commenting on the code that's already committed, that's already working, that's already supposedly part of the product.

Yeah, well, I think you make a great point. And in fact, some of the reason for this may just be the exigencies of the business world. I think of my career as a writer where when I was in school, we actually had my college paper. A tradition of everybody kind of marking up everybody else's work and criticizing it. But once I got into the business world, forget it, nobody has time. You've got another deadline, you can't do that. Now that, I think, sadly, is the norm, not just in the programming field, but in a lot of fields. Where if we all had a little more time to reflect on our area of expertise, we might actually do better. Any other questions? Oh, Hi. I read this at the back of your book. This little quote, praise for Dreaming in Code. And it says Dreaming in Code is the first true successor to Tracy Kedders the Soul of a New Machine. And this got me excited and scared at the same time. Excited because the book is great and it's a fabulous read and I'm looking forward to reading this. But everybody that I know that work in similar companies that. I guess it was Data General that was described in Tracy Kidder's book told that this book is not at all realistic. This is not how we work. And, you know, this is a great read and great narratives and everything, but this is not true. And I was wondering if you have any comment on that. Well, I certainly don't know enough about. I can't say to what extent the Soul of a New Machine was or was not accurate. I do know I spent three years with the team at Chandler. They have obviously seen. I showed them the manuscript after it was edited but before it was published. So if I had made mistakes or if they felt that it was an inaccurate portrait, they would have the chance to weigh in. I didn't guarantee that I would make changes, but I wanted to know their feedback. And as far as I know, they feel it's a fair and accurate portrait. So, you know that I'm not so worried about that. I do feel that for people who loved the Soul of a New Machine, I'm glad that people are comparing my book to it because I love it, too. I just want to make sure that people. People aren't disappointed because my book is somewhat different. Soul of a New Machine was kind of at the beginning of the computer era. It introduced a lot of people to the whole idea that this could be an interesting subject. And today, you know, it's 25 years later. Computers are everywhere in our culture. People are more familiar with them. And I wanted to write a little bit of a different kind of book that tells a story, but it tells a story. And in order to ask and try to answer this question about why things often seem so hard. So the books are different in that way. All right, then. Other questions. Thank you very much. Thank you. If you want to get your books signed. Right? Yeah, I'll be happy to sign books if anyone wants me to. Thank you.