 Good morning, everyone. It's really great to be here in this beautiful place. You can actually see the Golden Gate from the stage. Well, not from here, but it's amazing. It's really great. OK, so half a lifetime ago in 2005, I went to this small gathering of enthusiasts of some obscure web project in Frankfurt. The event was called Wikimania, if I remember correctly. And at that conference, I got to listen to a keynote speaker who apparently invented the wiki. And when he talked about this invention, he talked quite a bit about how people in the technical space collaborate and how engineering works. So later on in my career, when I learned more about design patterns and about the development process, his name came up time and time again. And more recently, when I looked into the topic of technical depth and I researched how this term came to be, there he was again, right? That a guy again. So please welcome Ward Cunningham. Well, thank you, Daniel. I did think that on my gravestone, they would put that I coined the term wiki. And now I think it's actually going to say I coined the term technical debt. Technical debt is much more of interest to every corporation in the world. They seem to have a lot of it. I was kind of remembering how it is I turned out to be here. I don't travel much anymore. But I had an invitation sitting in my inbox when this kind of election happened. And I thought, oh, my gosh, I have to do something. And then I looked at my inbox and there was the invitation. I thought, well, I'll come down and talk to you folks because you're doing stuff. And it's really important. Now, it also took me two days to get here from Portland through ice and snow and a lot of technology. And now let's just see if I can get logged in here. That would be the, ah, it says no. Ah, great. Now, are we on? Yeah, great. So let's just begin at the beginning. So in a little bit of conversation by email and so forth, the question is what do I really have to talk about? And it turns out technical debt is a lot of that. And technical debt, at least as I coined the term, is misunderstood greatly. And I will address that at some point. But I think a bigger thing, and this is something that I notice broadly, is that it's hard to survive success. That computer programmers have a tremendous power over the world. And as something you work on becomes successful, you just feel that power vanishing. And it's discouraging. So I don't know if this really applies here, but I do know that the Wikimedia Foundation is evolving. And so I thought I had to tell some stories about what I've seen in my career. I was a consultant for a number of years and had an opportunity to step into lots of different places and work with lots of amazing technical teams. In fact, I wanted to just mention one was a fellow had made a lot of money and had the ability to hire a team of people to work on his stereo. And this isn't actually his stereo, but it could have been. It was a very, very complicated stereo. By stereo, hi-fi, I think we call it a media center now. And he hired a lot of technical people to work on this. And if you think about it, this is a dream job. Everybody wants to work on the best media center ever. And their first day, they get in there and find out just how complicated this thing has become. And then every day after that. And it took me a while to realize this. And I can't even guarantee it's true, but I believe it's true because it explains a lot of kind of strange behavior that every day they came to work and they said, oh my god, today I'm going to get fired. I have my dream job and I'm going to get fired. And this idea of being productive, being creative in the presence of fear is something that I think is deeper. It's a quirk of being an expert of something that very few people understand. So I'm going to kind of hit a number of things. In fact, here's my one slide. So I got one slide. This is a condensation of a few things that I said I could talk about. And they said, well, that'd be a good abstract. And I say this is my one slide, but I will warn you that I have 40 builds. And it's going to take a while. And the reason I'm going to leave this up there is because this is a progression of thought that will, I hope, lead to a lot of questions. And it would suggest we'll take 10 minutes and then we'll have 50 minutes of questions or something like that. And I've practiced this a few times and it's more than 10 minutes, but let's just jump into it. Probably the most important thing, I think, for working on Wikipedia is that it is so successful that there's no place to look for guidance. Eiffel Tower is pretty successful, too. And there isn't an Eiffel Tower 2.0. There's no place to look. And so here I put the Wikipedia up on top of the Eiffel Tower's little meatball up there. And if you're up there and you look around, you just see empty space. So now that doesn't mean that people don't come with a lot of suggestions. Oh, it ought to do this or it ought to do that or blah, blah, blah, blah, blah. And pretty soon you get this idea that you're a giant failure when you're really a giant success. So that's pretty weird. And here's my wiki sticking off the side. At least I'm off the ground. And I had a five-year jump start as far as wikis go. And we managed to assemble up 36,000 pages. And it was an advocacy side. It was about changing the way people talk about computer programming. And in fact, we succeeded. In fact, we succeeded to the point where it actually became kind of useless. There wasn't how we're gonna talk about computer programming 2.0 to do. So it's kind of lived its life. Yet a couple years ago it went read-only and two people complained. This year it actually went offline because my one little server couldn't handle the scrapes that were going on. And oh my gosh, you know, the complaints poured in. You know, it was on Hacker News that a wiki is down. So we got that back up. But it's, the funny thing is that I share some experience that you folks share. In fact, I was at an early conference and I met Jimmy Wales and we decided to go have lunch and, you know, six or eight tag alongs. And this is the first time I'd actually met him and we're telling stories. And they're all the same stories. And I say, I don't even know this guy. And he's not like me, we're very different people, but we're telling the same stories. And I say, oh, well, of course, we both ran wikis, right? And so there's something about how people, oh, and hey, economists have finally caught on, you know? They said, well, first of all, it's impossible. And then the fact that it's there and they're looking it up, stuff on it themselves, you know, that there's something going on. Now, the other thing I wanted to mention is it would be irresponsible to have something as successful as Wikipedia without an organization behind it. So of course there's an organization and that organization collects a lot of money and I think some people here, 70%, I heard, you know, are even drawn a paycheck. And so it's a really important thing that there's this encyclopedia and all the other projects. But if I say encyclopedia, I mean encyclopedia and the other projects. And then there's this organization. But organizations are a weird thing in their own right. They're like alive and if you're alive, you just don't wanna be dead. So there's this preservation attitude and it's easy to get confused if you think of them the same thing because they're not. So I'll poke at that a little bit as we go on. But kind of working our way through what's going on here, the thing that is the fabulous accomplishment of my Wiki and your Wiki is that it's a place where you can be creative. You can see stuff happen there that is so far beyond what you imagined would happen that you can't help be excited. Now maybe you see some stuff going on you just wish wouldn't go on and you wanna see stop it, you know, and you say, well, I'm a programmer, why don't I just program it so you can't do that? Well, of course you don't have that sort of power. You have very little influence over how Wiki works. And as a double E, so I think of everything in terms of fields, but the one that helps me is to think of it as like waves, ocean waves, think of the ocean waves are a thing, but they're not really a thing, it's just water and understanding standing waves. What's making them stand there? How does that work? And you have this enclosure, maybe some sort of vessel or as a water skier at one point and I remember water skiing in a lake that was in a reservoir so it had stone walls and you do one trip around that lake and it turns into a sea of standing waves because the energy has no place to go and you can't ski there a second time around. It was just really amazing. Whereas this other place I skied, had reeds and shallow water and stuff like that and the waves would go in there and disappear. So I think of a Wiki is kind of like those stone walls. They're there to hold the water, but the water's gonna do what it's gonna do. And that is, now if you really completely understand water, which most people don't, maybe you can guess what it's gonna do, but if you really, really understand people, you could guess what they're gonna do too and you'd be wrong. But here's a cool thing about waves that you throw a rock in the pond and waves go and if you track one of those little crests, it travels at a speed, but if you track that group of crests, it travels at half that speed. You can have the same thing going at two different velocity, factor two in fact, almost exactly. And so this is a little picture of a wave at different frames in time and that's just how weird water is. Just imagine people. So, you can't, I mean, we have a lot of responsibility to make sure the system is healthy and sustainable in all this, but it's gonna be what it's gonna be. Now, as we start talking about the system, I say, well, how can we make 10,000 great decisions and then just end up with a mess? And what do I mess, of course, is a technical term here that means bigger than you can understand. And so here's another little mess. That's a gas turbine engine made by Siemens. That was the most complicated picture I could find that probably worked. And if you hired on to work on that thing and you wanted to move one bolt, you're one centimeter, you would face tremendous amount of review and so forth and people would tell you, you don't know anything about bolts, let alone gas turbine engines. And you could call that a mess, but it isn't a mess. It's some of the finest engineering in the world. So this is, when you work on something that's big, this is just what it's like. So now I wanna go through step by step and I hope you can read that. I'll read them for you. We're gonna stack up some bricks here. And this is where I'm gonna get all agile on your extreme programming. I think one of the things that we realized when computing was done on a computer on your desk with screens up there on your desk, which wasn't when I'd be in, when I'd get you punched cards and sorted them in a deck. But we could work together. We could work together because you and I could be sitting at the same computer pointing at the screen and talk about what just happened there. And when we have a conversation about what's going on in the computer, there's really three participants, you and I and the computer. And we learn a lot about what the computer wants to do together. So that's important. Now work together, the conversation, so much invention is in the air between us. You can't even remember who thought of it first. So what happens when you do that is the next brick there says a quality consensus. And if we wanna have good decisions, we have to understand what good means. Good is a hard thing to nail down in computer programming. And I know that because I read blog posts that are crazy what they think good is. But what really matters is what do you and your peers think good means? And how are we gonna get something to be good enough? What's, and this is not just spaces versus tabs. This is how you name variables, what the metaphor is behind those variables. What is the thing we're even working on today and why is it more important than the thing we could be working on? All of that consensus, if you don't agree, then you end up tugging against you there and you're not working together. So you see work together, quality consensus is something that you get from working together and it lets you work together better. So they're related. So here I'm gonna stack another one on here. I call adaptable priorities. And having a priority one is nice because then you know what to work on. But tomorrow it could be priority three because there's another one. The idea that how do you do your work when what's important keeps changing? How do you know what's important and so forth? But you can do that if you have this sense of how you do your work. I mean, when you go home at night, you go to sleep and you forget what you're doing. You have to learn it again the next day. You could actually learn a different thing as long as there's this sea of practices that you know how to do. So the quality consensus and all that, it's what you do. And then what you do it to can change moment to moment. Now in that world where you're working on two or three different things, only one at a time, but two or three different things, it's hard to have a sense of progress. How do you know that you're actually accomplishing anything? And that is even harder, especially if you're working on really hard things. That sense of progress, well, you know again, the stack of things underneath answers that question. You know if you and I are working on something and we finish at the end of the day, we say well what did we accomplish today? You know, well we did this and that failed. We did this other thing in that failed. So there's two things that we learned today that don't work, you know. But there's a sense of covering ground and it's hard to know that yourself if you're always working on the most important thing and it isn't getting done, you think you're failing. But if you're working and you can have a conversation about how it's going, you know, because a lot of thought happened through the day and to recognize that thought gives you a sense of progress. And when we talk about XP and that, you know, and especially Agil, it turned into a management thing. You know, it's more about measuring progress and it does a lousy job. But if you have a team of people and you say are we making any progress at all, the answer I think almost always is yes. So maintaining that sense of progress is important. Finally, I think this is finally, I think there might be one more, accumulate technique. In other words, it's okay to spend half your day figuring out how to be more effective in the other half of your day. Because it's only if you do that does the rate of progress speed up. You have to use the computer to make your work better. Don't do today's work the way you did yesterday's work. Find a better way to do today's work and share that experience. Now, if you're working together with other people, don't make it the same person all the time. You know, y'all be working with somebody I haven't worked with before and I'll do something. I'll say, hey, wow, how did you do that? Can we stop and talk about how I did? Or they'll do more likely they do something. I say, how did you do that? And this conversation about how to get work done is really important. This, you know, in pattern terms, we call it pattern discovery, there's an evolutionary environment. Oops, and more, you know, I sort of wear these black tags so I get lots of pictures taken. I hold my hands up here to get lots of pictures taken. But the accumulation of technique is the thing that happens that makes progress go on indefinitely. You can make progress indefinitely. And finally, I wanna put up here what I call acceptable debt. In other words, for all kinds of technical reasons, sometimes political, sometimes you made promises, sometimes you just need to be done, you know, for a month and beyond to something else. You get to this point where you have to say, this is good enough. This is good enough. If I come back to it a year from now, I'll be able to look at it and tell what I was thinking. And you know you could make it better, but this is, I call it acceptable debt, to distinguish it from technical debt. That means you're an idiot, you know, and you did just a bunch of junk and it just happened to work for a week and you thought you were done. That's that, some people call that technical debt. I call that foolishness. That's like thinking you don't have to pay back your credit card, right? You know, oh, I got to buy a bunch of stuff. You know, and you know, now there's police cars outside. You know, what's with that, right? So acceptable debt means I'm making a technical decision that this code that we've been working on together is good enough to rest for a while and we'll be able to pick it up and do good work later when we know more about what that good work needs to be. And so that is the technical debt that is good debt because it's built on accumulated technique so that you know how to do it. You know how to leave it in a good position. There's a sense of progress and you know when you're stopping, you know when you're starting again because you can feel it moving or not moving and that means you're still in control of your debt. You're in control of what's going on. I'm going pretty long on this thing but this is the essence of what I taught people to do and it's all about programming. People who don't program simply can't understand this and I don't know why they write books about Agile when they can't understand this simple thing but they do and if somebody's beaten you with an Agile book, you just tell them, look, Warren himself told me that this is what's important so keep that in mind. Now one thing that comes down to this is like I said, you and I are programming that third thing is the computer and we talk computer to it and talking computer is something you really need to know. You need to know how to talk its language because it's not going to talk your language yet and I call that reading all the code and there was a point where I worked on a media Wiki site. We had 20 million pages in media Wiki and I learned a lot of PHP. I knew I'd done one PHP project before that but this was big and I want to talk about how I felt comfortable with media Wiki and also some crazy stuff we did. One of the most crazy things we did is we programmed in Ruby. Ruby was a new thing then and we were going to be hip even though we were working on PHP, we put a little Ruby on top there and then anytime we did something new we'd just do it in Ruby and wedge that into this big body of PHP code. So here's a couple more Ruby things and we did this after about two years of this. The whole thing turned upside down. Watch this, look at that, did you see that? That was so good I got to do it again here. So there's some Ruby code, some Ruby code and then we just said, oh, let's make this be a Rails program. There it is Rails with little bits of PHP all over and that just meant when it started, it started a Rails app and then we looked at it and we said, well, that's pretty amazing that we pulled this off at all. We really felt in control of our environment and then we looked at it and we said, you know, that's a bit of a waste of time too. We could have all just learned PHP, right? And that happens but it does give me some cred for having done a massive refactoring in the media Wiki code base and this was a few years ago. I understand it's bigger now. But one of the things I did early on was I read the whole code base and this isn't the PHP code. This is code I was working on last week which happens to be some event handler from Antler, Antler 4 which generates tables that can be interpreted in Java or JavaScript. This is a JavaScript, something or other. It's crazy stuff and I didn't actually use my technique that I'm gonna show you but I wanted to show you this in real code. What I do is I'll scan that and what is the shape of that code? And this is just one function. Actually it's one half of one function so it's not hard to look at. But here's what I'll reduce it to. I just delete all the alphabetic characters. You know, all the new lines. And it just turns into that. Can you see that? I wish it were a little bigger but if you just imagine all the curly brackets, all the parentheses, the equal sign pluses and pluses and it's especially nice because, you know, for loops. It starts out with a for loop and it has that left parent equal semicolon less than dot dot dot semicolon plus plus. You know, that's what every for loop looks like, right? So that it kind of stands out. And what I did is I just wrote a little script that did this to every function in MediaWiki, sorted them so that some more things were together and made a little browsing clickable thing. I'd say, wow, that's strange. What are all those dots in a row? And I click on it and it shows me the function. Now here's another one, all those dots in a row. Different things, same idiom, whatever. And so I browsed all of MediaWiki by looking at these cryptic strings and the sorting causes similar code to be similar and I developed a sense of how it was written. I learned the idioms that were being used in MediaWiki and my conclusion, by the way, was this pretty good code, you know? The everything in there that I saw was there for a purpose. It was carefully named, it used common. Every now and then you'll see something same, same, same, almost the same. And I click that almost the same. Why is this one different? And you know, there's a pretty good reason for it. There's something about the way errors were handled that were different or something. And so this allowed me to bring all my past experience to a code base that I didn't understand. Let me browse it in a way that I could get a comprehensive knowledge and I've done this over and over and over again. It sounds so simple, just delete all the letters and it leaves behind a signature. I call this the signature survey. Survey the signatures in a code base and it works. So these last two things, you know, that stack of bricks and reading code, this is the essence to me, what agile, what extreme programming is. And I do want to say one more thing and kind of move on to some other stuff. I want to say when we wrote this thing, which wasn't initially called the manifesto, but there was some arguing about who's going to own the thing and we renamed it. But the claim we made, and this is, I don't know, 15 years ago, this was the end of a lot of period of discovery. So I think of the stuff I did was 25 years ago, but here we were so modest. I want you to understand, we said we are uncovering better ways of developing software. We're uncovering, we didn't even claim to be done, but we said we're discovering things. And we're discovering by doing it. We're doing the development of software. We were a bunch of software people doing software and helping others to do software. So our relationship was all about software and we noticed it was categorically different than what we had learned. Now one thing is computers were fabulously more powerful when this was written and they had the graphical interfaces and, you know, no punching cards or anything, it was a transformed industry and all we were doing is noticing that, you know, in this world there's a better way to write software. And then we noted through this work we've come to value and named four things. And those four things have become really important. We noticed we did a translation project and we noticed as we got people to translate it that they couldn't translate the four things because it doesn't actually say much. You know, they're so brief. They're so, whatever they are, you look at that and you say, of course, I believe that. You know, it, and then we'd say, well, what is a software tool anyway? You know, and so people argue about all kinds of stuff. It is an emotional document and it presents something, but the most important thing is we were doing it. We were helping other people do it. And if you do that long enough you'll develop these techniques, like I mentioned, that just make everything run big. And by the way, you know, if you're gonna fight cyber war, say, anything we suggest here doesn't help because it's a different kind of thing. We live in a different world than we did 25 years ago. So expect it to be different. And there are people who wanna call that agile too, but you know, I'll disagree with them. So how am I doing time-wise? Am I, am I using all your question time? I hope I'm answering some questions here as I go forward. I see some smiles, so it must be okay. And how many people actually live and work here in Silicon Valley, you know? So a third maybe. And I wanna just say that it's a hard place to be successful. I don't know if you feel that or not, but it is, as long as I've been in computing, I say no matter how much money I make, I know somebody makes 10 times as much. And that's pretty true for even the people who make 10 times as much. It's a strange place. It's the envy of the world, but they don't even know what they're talking about. They don't even know what they're envying. Now, before I go rant on the Valley too much, I have to say that these phones are fabulous. Here's the inside of a phone. And this is not really a product of Silicon. It's a product of the world. And the fact that we can make these things and make them so cheap is pretty marvelous. And that depends upon this organization of supply chains, which is marvelous. Here's a site that's a favorite of mine. It's called, it's at MIT. It's the Observatory of Economic Complexity. So what they did is they figured out how to kind of say, well, who knows what where? And in fact, they were able to project that backwards in time by looking at trade data and doing some fancy network analysis that they even got a science paper out of, just doing the, can you imagine, economists writing in science. But I just looked this up in, here their most recent data is 2014. And at the top of the list, the most economically complex product that a region could have is CERMETS. I'm thinking, I don't even know what a CERMET is. But it's some sort of ceramic that is mixed with other things that make it less brittle so that it's malleable like steel but has ceramic properties. I did notice when I first looked at this, is there's an awful lot of chemical engineering that the world, my tech world lives on top of chemical engineering. And so that's what this organization gives us, the ability to have this level of specialization and depend upon each other. And it's just fabulous to see how that works. But I do want to make a different point. I want to talk about why it's so hard to live in the valley here or even just know people who wish to live in the valley. And I have to make it really simple. This is some clip art I stole from Carver Mead in a recent talk. Carver Mead was a graduate student under Feynman who liked to make things simple and Carver likes to make things simple. So he says, well, I want to talk about gravitational waves but let's just talk about pushing a car down the road and what does it mean to get that car working and allowed him to start with some really simple formulas for momentum. I want to start even simpler. I want to talk about return on investment. Return on investment is set all the time here and it's basically the distance formula after you throw a few logs in there or take them out. Distance is equal to the rate times the time and that's you're gonna get farther if you go faster or work longer. Now that's not what people when they say ROI they really mean the rate of return on investment not the return on the investment. They're not interested in D because they don't actually care what you make as long as you do it really fast. And so what they do is they solve for R, the little R what is the rate and that's distance over time. And if you want to have a good rate just don't waste any time. Just keep that time real small because that makes the rate get big and the people who are putting money into your business they don't care what you do. They're not all they want to see is a return. They want a high rate of return and that is a meme that has spread the world over. That is a meme that was founded here in the valley and has spread the world over and it confuses people as to what they're actually doing. You know, if you're not getting a good rate of return if you're not working fast enough you're a loser and that is so wrong that I feel I have to mention that to say that if you're doing good work, if you've got measure of progress, all that stuff I put in the stack and you have the budget to keep doing that like maybe you work for free, that's what I do. And then it's really putting in the time put in the time to get good work done. And I wish I could say there was a magic thing that just gave you both a high rate of return and a high return at the same time and maybe genius helps there, you know, but it's really no, so anytime I hear somebody talking about how we ought to do this or I would, I have to say are they thinking rate of return or are they thinking return? And it's amazingly black and white. So, and it's not any more complicated than pushing an old car down the road. So now I want to talk about one last thing and this is something that I get asked more and more on account of the fact that I'm getting older and older every year. And it's like, how do you stay technical? Does anybody worry about that? Think, you know, how am I gonna be in this business five years from now? Yeah, I thought you were all pretty young. Okay, more and more you discover that all these techniques you learn, everything you know about software, you know, any respect you get for it disappears. It disappears pretty quickly. Like, if not in a year, certainly in five years. And so you live in this world where you have to keep reinventing yourself. And I think of this in terms of patterns. I have a set of patterns, they work pretty well. Early in my career, I learned how to debug a program and it hasn't changed much, but the programs I debug are dramatically different and to be able to work in the current world, you really have to invest in learning those new things. In fact, I would say that if you're a curmudgeon, you know, you say, well, all this new junk is really the same stuff as I did 10 years ago. It's just that they changed all the names. And that's not true. It turns out what they did is all, it's true that all the names changed, but it's not just what they do. There's probably one new name in there for one new innovation. And if you can go find that innovation and put it to work for you, then you've mastered the new technology. And you get to bring all the rest of the patterns, you just can't call them what you used to call them or your peers won't recognize you. But you can keep up, it is not hard to keep up, but you have to be able to let some old stuff go. So that's important. And I want to mention by pulling up a little bit of JavaScript here, this is, I spend probably half my time in JavaScript. And I want to say that JavaScript is progressing faster than anything else I've ever done in my life. And I'll say progressing, that implies, like I just said, that there's better stuff down the road and we're moving in that direction, but it just does seem like a churn. And the reason I do it, first of all, I have a nice editor, this is Sublime, and I can write simpler code. This is a little parser for the markup. You see all those reg-exes there? That's, I still write parsers by a bunch of reg-exes. And I get them one per line and I can get away with that. And I love to talk about that, but that's the thing I said I wasn't gonna talk about. But the other thing is pop in here and the debugging environment, the environmental support for JavaScript is pretty phenomenal. And the fact that you can, like on anybody's computer, you can walk up and say, well, let me debug that. Pop up the debugger and say, well, this is how the computer and I talk is pretty marvelous. And so I was a small talker for 15 years. The small talk was small and beautiful. I have to say that JavaScript is huge and beautiful. You know, there's a lot going on there and I like it. And I am able to do it because I was willing to set that small talk behind. So that's my story. Here's me holding my hands, posing for a picture. Click, click. Okay, you gotta be quick. What I wanna do now is somebody help me watch the time here and make sure we finish in time. How many minutes do we have? Like zero? I don't know, I'm just gonna keep going until they throw us out. Here's my slide. I took all those little pictures and brought them forward as a reminder of the kind of things I talked about. And I would love it. I like this idea of coming up to the microphones. If you come up to the microphones and ask a question, then I can give kind of a flip answer. And if you don't like the answer, just get back in line again, come around and ask it again. Right, and so please, please show that all these pictures were worth the trouble that I can remind you what they were. Is there a lunch or something coming that people wanna go to? Ah, very good. Now if you ask a really stupid question, then a bunch of people will come up and ask better questions. There you go, exactly. Don't be too good. Don't be too good. One thing, thanks for the fun talk. One thing I noticed recently talking to younger devs around Berkeley is that the tool use of graph data structures has really bumped up. And for one reason is graph has a scalable property that's useful in these times. But another reason is that the literacy, where you start as like a smart high school person, the literacy level of computer science basics is so much way higher than 25 years ago, right? When I was doing C++. So that's, I'm interested in that. The graph data structure is that, do you have something to say about that? Oh, 15 or 20 things I could say about that. I will say that I worked with a group. We hire a lot of code school people who've learned Ruby and were originally a Ruby shop, so that's pretty good. But I'm a fan of D3, which is a great visualization package. And a couple of them came over to me and they said, well, we wanna talk about how we can do this project in the company that we're gonna do it in D3. And then they kind of sheepishly said, well, we're not too good at the graph algorithms. And I'm thinking, oh my gosh, D3 is gonna kill you. But I didn't say that. I said, oh yeah, okay, well it'd probably be kind of like this and was encouraging. And then I said, how about if I create some test data for you? Oh yeah, yeah, test data, that'd be great. So I wrote a little Ruby script that generated some graphs. And I made them simple and I sent them to them and they found that really useful, because it's like test-driven development. I'm only writing the tests. It's data-driven development and I'm making graphs that are data and then they do that and they say, well, what about this other thing we're worried about? I was, oh, let me make some more new data. And I just made the data progressively more complicated because I knew enough about the kind of graphs they were making that it would work. And that was, and so somebody should be lining up over here to ask the next question or I'm just gonna keep talking about graphs. It actually worked well because they could manage, and I think this is something you learn in code school, you manage your own learning to the point where when there's a problem in front of you that you don't understand, you go figure it out. And so I was basically presenting them a series of problems without announcing I'm gonna give you a series of problems and teach you graphs and it worked pretty well. Over here. I have 55 minutes left? 20, oh, that's perfect. I thought, the original suggestion was talk for 10 minutes and then I made these slides and just getting through them was tough, but I love this stuff. So, okay, go ahead. This isn't directly related to anything, but I figured. No, nothing's related here. All right, great. I wonder how you feel about open source software in general. There's, I guess, a political aspect to it and a pragmatic aspect to it, and I don't know if you subscribe to either or both of those in terms of. That's a very good question because open source software is truly misunderstood. Sorry, I was told I have to say my name. It's your own Corinne. Ah, nice to meet you. I was sort of, I mean, when GNU came out, I was in the UNIX world and I thought, well, that's nice, you know, but I had all the software I needed, so I just ignored it. And somewhere along the line, I ended up doing this Wiki thing and people said, oh yeah, yeah, open source, open source, and I said, oh yeah, I should probably open source this. I never really did properly license it, but some other people came along and threw something in front of it. I just looked at the licenses and every user will read all the licenses and I just, it just drove me nuts reading the licenses. So that, if you think of open source as a contract with your users, you know, it's good in that regard because you're a creator and you ought to be able to know what terms you're using. On the other hand, I think that my relationship with open source has changed dramatically with GitHub. GitHub and its commenting and pull request and all that. It basically took so much of the burden off of an open source creator, it became a place for me to work where I could work on the distance. I could go and go and go. And I've been working on a new Wiki, by the way, for five years and the first one took a couple of weeks and this one's not as far along and it's five years. So I feel a little bad about that. So I think about this distance formula a lot, but there's a community around it and the community is great people and I can't, I mean, every pull request, even a drive-by pull request. Oh, you did this one thing wrong with delegates. Great, so I go study delegates a while so I can understand the pull request. It puts me, because I bring something to the thing where people will pay attention to me and talk to me. And so as a creative, I think it's a fabulous space. So open source is great. Now, one of the brilliant things that happened with MediaWiki is that it was open source and there's a lot of copies of MediaWiki around. And I'm kind of following this thread about do we want to be microservice architecture and if we're designed to run on 1,000 computers, what does that do to our open source project? I think that's a serious question, although I will point out that most people who contribute are contributing because they like what you're doing, not that you're helping other people do their own wikis. But I do think that MediaWiki's benefited dramatically from being open source and that's something you don't wanna throw away carelessly. Go ahead, we'll go left here. Hi, I'm Adam White and I get paid by the Wikimedia Foundation to do the same thing every day and I really mean the same thing. And so a thing that's on my mind after you talk is that you have some good things to share about the fact that how you do things should evolve. And I'm wondering if you wanna talk about evolving what we're doing and maybe the frame that I think about this in is like Wikia can support, I don't know, tens, hundreds of thousands of wikis of people all doing completely different things and Wikimedia Foundation has been supporting the same subset of wikis which is people doing a rather conservative thing all the time and wondering if that's... Yeah, that's a good question because if you wanna do something cool, it helps to be daring and I do blind stuff all day long every day and draw a salary for it and because I didn't... God, I forgot to get rich, you know? What was I thinking? So I consider myself lucky to draw a salary and the health insurance thing but I do much more daring work in open source than I do in my day job. In fact, I often will do something at home just to see if I can do it and after I know that I can do it, I would dare even suggest it at work. Even as CTO, I would not suggest things if I hadn't known that it would work and so a lot of the daring work is, you know, done off production. I also think that having worked for a living and know that business wants pretty modest things from technology that it helps to recognize the little spurts of creativity and just how you do your work or whatever, even if you don't even really believe in the big project and I've worked on plenty that I don't believe in, you know, to find that execution can have a lot of variety and especially if you're willing to write tools for yourself and you get good at writing tools, that's, I get a lot of strength from that but no, it's, I said that technologists exist to give policymakers choices and that means, I mean, I think of it as every single line of code is a decision made, you know, but it's a decision that if I'm programming with somebody else then somebody will notice but most people don't have a clue of what I do so I was lucky that Wiki became something but no, most of what I do is invisible and anybody who wasn't close to it would say it's the same old thing. Hi, I'm Andrew, I also work at the WMF. Thank you for the talk, it was really great. One just quick comment before my question. I want to mention saying that your analogy about the car reminded me of, it says we're going, we're walking slowly because we're going far. Yes, it's the endurance, you know, and for sure. So my question is about, if you could, it's not a question, I guess, just if you want to talk a little bit about how software and computer code relates to human language and human communication and if you had some insights on to, in software, some insights about how software, how computer code is a form of human communication, I think that relates to agile because a lot of the things you say in agile are, it's about software development as a social activity, how people work together to develop software. And so there's a big component of that is communication through code. And I find a lot of the time, you know, how you name a variable or even how you space the code or how you find abstractions in the code and organize it based on those abstractions is part of you communicating with other people. And there's also a whole movement of literary programming. So maybe you could talk a bit about that. Thank you very much. Yeah, absolutely, absolutely. I should mention that I was very strongly influenced by George Lakoff and he and Mark Johnson wrote this book, Metaphors We Live By and Lakoff has done a lot of other things. Very systematic study of where meaning comes from and how it's propagated. And the idea is that you'll say one thing but you really mean another by analogy or something metaphorically and that these metaphors just become part of our language. There's no way to not think in terms of metaphors. And so extreme programming which was the early and most successful agile methodology had a practice in it called metaphor. Because I put it there. I said, look, we need to think and I could have said storytelling. What is the story that the software tells? But it's more like how are we gonna choose to think about the things we created? And this is an object oriented time. We're always exploring that. What are we gonna think about the objects that we name? And I said it was really important and you might write your code, look at it and say well this code turned out to be very different than what I thought we were writing and we have to change all the names to be consistent with what it is today. And that changing the names, it means it needs to be part of a consistent metaphor about what we're really doing because most code in the world, you know, like having input and output, you know, that just visualizes a program as a little machine and a conveyor going through it. You put some stuff in the input and it comes out the output. That's a metaphor. And how we think about code and now it would be more inclined to say story or something like that, but this idea that we might get on a wiki and by telling stories using terms that are defined by other wiki pages that we might brainwash ourselves into the future by writing and that's actually what happened. That's why my wiki became less important because the words just entered the vocabulary but they were all practiced by writing pages in terms of these other words and you could just click, click, click for definition. So although people said this whole metaphor thing, nobody understands that nobody's gonna do it, nobody's gonna sit down and think of what the metaphor they're using for a program but they did it all the time on wiki. And so, you know, it's caught on in a weird sense. Just like all the pattern stuff, nobody goes and reads a pattern book anymore but if you listen to anybody talk, they're just citing patterns left and right as they learn the words. So we have about 15 minutes in addition to these four people, I have at least one more question coming from IRC. Let's take IRC first. Can we sneak in there? Because I'm not sure we get to everybody here and somebody's gotta watch the clock carefully. Okay, so I'm literally reading here. So someone said we are walking slowly because we are going far. Question, can you talk a little bit about how software and computer code relates to human language and can you share some insights about how computer code relates to communication? That relates to agile because it's about software, dev as a social activity. So there's a big component of that is communication through. Okay, I think I heard two questions there. I'm gonna go for the other one and instead of talking about metaphor, I just wanna talk about what it takes to read code. And one of the things you're diving into if you just commit yourself to reading a lot of code is even if it's in a language, a computer language you know, it's just completely foreign because you're hearing a different voice or a different set of voices. And so when I jumped into Media Wiki, I felt like I was in a conversation that was going on without me. And what I had to do is I had to read enough of it so that I found how these people talk. And it's very technical, it's precise. It's like people say, mathematics is the language of science. So they use the word language there correctly, I believe. There's some people who say Morse code is the language of telegraphy. And I learned it well enough that I hear words instead of letters, that's pretty cool. But to look at a lot of code and see thought, you know, to see the product of a human mind on the page and then imagine what that human mind went through to produce that is something that, you know, you might have said, my friends would have done it differently. And that's judgmental. But if you want to say, I just want to see what people were thinking when they wrote this code. And if they were careful enough to make what they were thinking manifest, I think it's a joy. It's, you know, I wish I spoke more than English, but I don't, but I speak lots of computer languages. And I've looked at, and at this point, I'll say lots of different dialects of JavaScript, for example. They're getting too much time over there, but they've got a longer line. Hi, my name is Derkin Hartman and I'm a volunteer developer. Let me reword my question a bit based on the last question. If we are speaking about the language and the vocabulary and things like this, looking at how we now have wikis and they're mostly targeting prose and text. I mean, that's where it came from mostly. What do you think the lessons are in terms of technology if we want to take this to new forms of storytelling or whatever, with new media types and other directions that offer ship can go to? What can we learn from what we've learned from wiki and markdown and these things? I think one thing we've learned is that natural language typed in on a typewriter is actually pretty amazing what you can do with that. So don't ever leave that behind. But I've, I worked briefly for a company that was going to invent user-generated content videos. And I learned a lot about videos and I learned how hard it was. One of the pleasures of that is actually working in Venice Beach when Andrew Lee was down there in Venice Beach and we spent a lot of time talking about that and he turned me in. You know, he of course, he's a video zealot. Turned me on to lots of things that are sort of formulaic about making good video. I remember the BBC Five Shot was an example that he had done a great little video about how to use that as a set of patterns that will guide you to making acceptable video on pretty much any newsy subject. And so that I think is important. Of course, video storytelling is really hard. I saw that Andrew had something out, he says, well, maybe these kind of year in montages are the sort of thing that video would really work for and he did a couple, which I watched before coming here and I say, hey, great work. Because I saw 2016 was a great year for Wikipedia, watching Andrew's video. I think VR is a different challenge. I think VR has the opportunity, every VR I've seen is just a bunch of random things thrown into a room with a checkerboard floor or something like that. But it seems to accept random things. I mean, it might be possible to lay out an organization like this space and say, well, let's just make an exhibit space and here's a bunch of exhibits. There was a great video, what was it called? Monday morning or something, a Will Vinton video that was basically that, it's claymation. Guy in a museum where all the exhibits were just dynamic, it was great. But the challenge is that the production of video, and I assume the production of VR, maybe visualizations are a little better, it's hard to imagine how that's done collaboratively. Of course, I was told when we started with Agilus, he says, no, you can't develop a program collaboratively because you don't know who to blame. And blaming was so important. And then beyond wiki, collaborating where nobody owned anything, explaining why you can't possibly develop a computer program with collaborative ownership. And they were collaborating, it was the weirdest thing. But no, I think as we get more and more developed media that has a process of production that we have to invent new processes that are amenable to collaboration. And I think it will be a new art forms. And it'll be hard to make, the technology, and people come and tell you how to do it. But Andrew had a lot of neat tips, and so he's a good guy, don't let him get away. All right, this time you have to come up with a question now. Yeah, a bit related to the question. I was wondering, would like to share some things you learned from your work in recent years on the federated wiki. Yes. And to give a better background, so my name is Tim and Byer. I work for the Foundation too. Also a long time Wikipedia editor. I remember your keynote from Wikipedia 2005 with, I think it was related a bit, that Daniel mentioned. And over the last few years, I've kept this list on my user page. It's called a timeline of distributed wikipedia proposals. It's like all the time. Oh, that's a great page, I know that page. Okay, cool. Yeah, I was just telling everybody, it's all the times where somebody thought, hey, we have these linear revision histories and it would be great if it could be more like GitHub, we could fork and merge articles. And so it's been proposed so many times, it never actually succeeded. I'm kind of wondering if it's because it's technically difficult because it maybe actually ignores some of the things that maybe Wikipedia are successful. Anyway, I was just wondering if you could share some things from federated wiki, which might be especially interesting for Wikipedia. So, I mentioned, I didn't call it federated wiki, I don't think, in 2005, but I said I see a future where servers are gonna talk to each other and I'll have my own server and they'll enter the conversation and every morning I'll come on and see what my server has found for me. That was my vision and that this was more personal than the conversation that we have on Wikipedia where we have to agree before the edit stick, that there could be disagreement and there would be a pressure for them to be resolved but that it wouldn't be as excruciating a pressure. I was dreaming about this and mentioned it and I was told that it actually stirred up a lot of conversation, but five years ago I had the chance to spend a year among a number of things developing this and I was quite surprised that it didn't turn out to be a server to server thing. It was a browser to browser thing where I could be in a browser and I could reach out to a bunch of different wikis and pull the pages together and expect them to form a story that maybe has never been told before, especially if it included some calculation because there's JavaScript in there and it can calculate or visualize or whatever, that it was a new medium for a new style of collaboration and I am more convinced that that's important, maybe not for encyclopedias, but as a way that we in the world can talk to each other than ever. What I have learned is that nobody wants to work that hard. They like pushing the like button. Just let me just say if I like it and move on. We're not even really a culture of reader or a culture of viewers. Oh, I like that picture. You had a nice breakfast yesterday and like. And that is pulling the level at which we have conversation as a people way down because it makes people money. So Federated Wiki, I'm content to work on it. I've discovered a handful of things. We've grown to about 1,000 sites and I would say that on any given day, if five of those sites have edits, that's a good day, it really depends upon who is promoting it and I promote developer to developer. If anybody wants to succeed with Federated Wiki and has developer talent, then I wanna work with them, but I'm not the community advocate. Community advocates have to come and bring their own community and have a technical person to talk to me too. And that is something I could get away with. People come along and say, oh, well, if you just put a Facebook button down at the bottom, you get so many tweets. And I said, well, if I was judging myself by how many tweets I got, you don't get tweets in Facebook, whatever you get. And this is more that our little R versus big D in the distance formula. Now, I'm also, know that a lot of great work was done a few centuries ago and the people who did the work never got to see its appreciation. If it turned out to be that, well, you know, maybe we'll have some conversations here. I'm here all week and we can talk about that and what I've learned from it in depth, but I think it is, although we share the W and the I and the K and the I, it's a very different thing and intentionally different. Not enough to talk about it, but it's you guys have your leadership in a direction that I admire and I'm happy to learn what you're doing and love that I had a chance to participate. And maybe that, we'll have to call that the last question. Do we finish up here? So we have a hard stop in five minutes. Hard stop, we're up to the hard stop then. And there's three people with questions, I don't know. Okay, no more people come stand up, but those who are already standing will do your question. No more questions from IRC? Thank you for the great questions, by the way. I have one here. Oh, okay, another IRC question? Yeah. Earlier you said Wikipedia has nowhere to look for guidance, which can be problematic. At the same time, Wikis are losing editors and one of the potential places they are going to are social networks. Do you think Wikis should try and unincorporate social networking features? Bonus, or should Wikis be social networks? Should Wikis be social networks? Four minutes, four. No, I'd say absolutely not. I'd say that's absolutely the wrong direction. And one reason I put you up on top of that, because I don't care how much money they're making, it's down there, it's television. And that's not to say there isn't good television, and some of it comes from San Francisco, but it's a much more noble thing than that. Now, does that mean that it can go forward without changing? Of course not, and that's where this whole, how do you get the waves to do what you want them to do? And the answer is you can't, but you can make changes and you can observe it. I don't actually follow most of the conversations out of the foundation, but I do read the research list. And I like the research list because they're saying true things about what people do. It's like, here's the physics of water only, it's talking about people. I also wanna say that having read it for a number of years, I'm convinced they're just barely scratching the surface. There is so much to know about what people do that is not known through that research. The nice thing about it is it's repeatable, and I really appreciate the people who produce the feeds and anybody comes and asks them crazy question and they treat them very nicely. That is really great work and that's more likely to expose something if you're talking to people who really live and work as editors and then you have some stats that are probably true and you reconcile those and that gives you a hint. That's much more likely to be valuable guidance. And you know, over there at Facebook, they're studying this stuff like crazy to figure out what they can get you to do too. They're studying themselves to figure out what they can do. You guys have to study yourselves and the fact that you're open and there's so many people willing to help, that's a position of strength that very few people have. So that's the answer. Last question and quick answer. Hi, my name is Matt Herbst and I've discovered the C2 Wiki back when I was a teenager two decades ago and it blew my mind, taught me to love camel case and people patterns in projects. And I appreciate that you brought it back up because I saw it was down earlier this year. Been recommending it to everybody. I was curious about you mentioned that for the last five years you've had a new Wiki software platform that you're developing other than Wiki, Wiki Web. Was this the federated Wiki? It is the federated Wiki, yes. Okay, so that's wrong. And one thing I did is about year three. First of all, I expected Wiki to last six months and the fact that it actually worked at all and people treated it with such respect was amazing. And then we actually covered ground. We accomplished our advocacy goal. We changed the way people talked about computer programming and that was pretty neat. And then we got the sock puppet thing and it was popular enough. It scored very well on Google that it attracted Riff Raff. And the community was willing to fight it off and I didn't give much help because I was the only programmer. And I just said, look, when these guys start launching robots at each other, that's the end. And then it happened a couple of years ago. Some guy got on there and started fighting with the old timers and said, no, you're doing Wiki wrong and whatever. And people tried to help him and he was abusive. And then he started publishing scripts. He says, here, look, here's a script that'll delete all of this and here's a script that'll delete all of that. And I said, no, we're not gonna run those scripts and I won't read only. And two complaints, right? So it's like it had lost its value because it was fixed in its goal and it met it. Now then I'm thinking, well, I wanna make this thing where we don't have to be so narrow, that we can talk broadly about how we're gonna live on the earth. It's not a scientific question. It's like, how are we gonna share resources when they're in short supply, that kind of question. And I fed the original Wiki into that. So it's in there, but if you wanna write, you have to put up a server to write on. So people who don't even wanna construct sentences, the last thing they wanna do is put up a server. And my hope is that, this is with Docker or something is gonna become much easier, but right now it's, you have to type npm install dash g Wiki and you got it. Ward, thank you very much. Well, thank you for the chance of speaking to you. And I hope that there's been something in all this that's very useful. I'm around for a long time and I'm proud of you. We have now a short break and then check the program for more.