 So, let me start the talk by telling you guys what are you going to be hearing today. The talk is from zero to co-founder, right? So the talk is for those who want to leverage the dojo program to accelerate their learning, eventually become committed for co-foundry, and also for those who want to learn about the processes the staff teams are using. So there are a number of topics we will be covering today. The first one is stream programming. It's a programming style that the staff teams are using. We pair when we program. There's always another person in this to you. We try to solve the problem with two persons as a whole. Another topic is test-driven development, TDD. So it's another programming that needs the staff teams are using. This co-foundry co-base is developed with TDD style. So every single piece of code or logic is covered by tests. And the goal for the teams is to have 100% test coverage for the entire system. And then we're going to talk about a CF foundation program called dojo, which the developer can leverage to accelerate their learning, not only the co-base and also the CF teams processes, and eventually they can gain the committed access at the end of the program. And since not all the committers and not all the team members in the team are centrally located together, there's a lot of remote collaboration happening. So we need some tools, we need some tooling to help to make this process possible and we'll cover some of this process and tools that we're using to make remote collaboration smooth and easy. So before I get into any of this topic, let me first introduce ourselves. My name is Simon. I'm from IBM. I'm the current anchor engineer for the CLI project. Before I got into co-foundry not too long ago, I was just a traditional programmer. I call a lot, but I don't really practice, like, pair programming, and I didn't really practice any TDD style. And I'm Derek. I started working at Pivotal just out of school, so I've been practicing extreme programming in TDD from the beginning, essentially. And I've been on co-foundry projects for about a year and a half now, including the services API team and the CLI team. So, Derek, we've been managing extreme programming for a couple of times now. Can you tell us a little bit more about it and what's the reason we're doing it? Sure. So extreme programming, sitting next to a guy all day, high fives. But what is it really? So it's when two people are sharing one workstation, one will be typing and navigating with the mouse, and the other, the navigator, will be guiding, contributing through just making sure the process and everything is going well. And the idea is that you will switch these roles every couple of minutes to an hour, depending on the field of the code or what particular thing you're attempting to do. So I'm going to talk about some of the benefits we've seen with extreme programming. A shorter onboarding period for new team members. There's a huge cost in bringing someone new to your team, right? They have to learn the code base, they have to learn the process, they have to learn a lot about what you do. And pair programming really helps alleviate this issue because they're consistently working with someone else being brought on to the process and just being nurtured and shown what the team does. So it really helps speed up that process quite a bit. Increase discipline. Increase discipline comes from working side by side with someone else. So you always have this immediate feedback loop in terms of what you're trying to execute on or what you're trying to do. So you're often going to do the right thing instead of the wrong thing, because you have two sets of eyes on the piece of code or the piece of logic you're trying to implement, instead of down the road in a code review or something of that nature. Collective code ownership. This is something we really stress at Pivotal on Cloud Foundry. And that's everyone owns the code base on the team. So there's no, I have this section, I'm in charge of this algorithm and it's mine. Everyone rotates through all pieces of the code base, all stories, all features, all bugs, as much as possible. So this really helps to reduce blame and also increase everyone's understanding of the general code base and not like, oh, this guy left. I have no idea what that 3,000 lines is really supposed to be doing. Mentoring. So younger developers now can get sped up and just start to learn process a lot faster. This is because they pair with senior devs who are often just passing that knowledge off to them and allows them to really speed up on the code base and being a good developer. Better code. So better code kind of comes from all these things, right? The huge part of this process is to produce better code at the end, produce tested code so that you have fewer bugs and fewer iterations that you need to go back and work on bugs that were part of you missing them the first time. And a huge reason this happens is because of TDD. That's right. So TDD, why is it? So TDD is actually a programming technique that we use and the main goal of TDD is to produce, create good code that actually works. So how do we do it? So in TDD is actually a software development process that relies on very short development cycle. First, the developer will write a test that details what's the behavior or the new function that you want to be, and then the developer will just produce just enough code to meet the test pass, right? With test passing, now you can reshape or refactor the code into a better standard, better design. And that's the full short cycle of a TDD. So here I have a graph to better illustrate how TDD versus traditional programming. So on the left-hand side in TDD, you can see the first step, the very first step is to write a test, not the code. And at this point, the test is not going to pass just because there's no code there, right? So we will write a code, after writing the test, we will write a code to meet the test pass. And after the test is passing, now you can refactor all you want and make sure the test is still passing, and you have a cycle done. And you can repeat this cycle many, many times in an hour. Whereas in traditional programming, as you can see, you don't really write a test first, but you design. You design what you want to do, you design the behavior, and then you actually go write a code. And after that, you go back and verify whether the code is working or not. So one of the biggest drawbacks for traditional programming is there's actually no good way to tell whether your changes might have any negative impact to the system. Does it introduce any regression system? Does it adversely impact the system as a whole? You don't know that because there's no test to tell you that. So in TDD, tremendous test coverage is one of the benefits that it gives us, but it actually has many other benefits. So this is another one. TDD calls usually they're maintainable, flexible, and easily extensible. What does that mean? So the testing process in TDD actually is integrated into the development process. It's integrated into the most granular level. So when you call, you can make sure every single standalone piece of logic or every single standalone piece of code, they are tested. So you can easily add new function, add new behavior or remove function or behavior without worrying about are you going to introduce regression? Because all you have to do is to run a test. If the test is fast, you're not breaking anything. The second benefit, TDD is faster than writing code without text. That's right. TDD can be really, really fast. You can develop in TDD so much faster than... So let me put it this way. Writing code without unit tests, skipping unit tests is faster until you actually want the code to be working. So in our experience, in traditional programming, that's a big part of our development effort is actually spent after you finish writing the code. You debug it, you find something wrong in the system, but you already chart the code into a repository. You spend time to debug the system while it's not working. So for example, I think we all have gone through this. I spend one hour to write a new function, and then I test it. You got the behavior I want. It's working. I put it aside. It's done. I'm happy. And then I found out there's something wrong with the system. And then I spent another five hours to debug it. Just to find out the code I just write because it's conflicting with a test or with a code, a module that I've written two years ago. But there's no test there to verify that. And I spent five hours debugging on a code that I only spent one hour to write. So with TDD, writing the test first actually eliminated a big part of this effort. And the reason is that because it allows you, with the test being there, it allows you to think, it allows you to get the code right, a big part of it, more right in the first try. And with the test being there, it also helps you eliminate a lot more bugs. You can debug much easier by running the test. So another benefit is it improves the design without breaking it. So improving the design is actually step three in TDD. So code written in TDD style, you don't really need to refactor it most of the time. But at that time, you want to integrate in your system or you want to integrate in your third-party module. At that time, you can easily shuffle the code or you can refactor all you want as long as the test is passing, you're not breaking anything. It's a curable documentation. So, like it or not, developer, they don't really want to read written documentation. We just want to dive into the code and start working on code base. I do it all the time. I don't know about you guys, but I believe you guys are doing the same. So, only when I get stuck, I get stuck so much, I surrender, go back and read the manual. But in TDD, the use cases are written as tests. The programmer, developer, they can easily just go to the test and look at what the test is doing, and from there, they can understand what the behavior of the code is supposed to be, how it's supposed to function. So, TDD tests emit excellent documentation. So, there's a lot of benefits. But like everything else, nothing is perfect. There's always some drawback, especially when you're a new TDD programmer. You have a hard time to learn. It's really, really hard to learn. And I'm the first-hand sample in the beginning of me adopting Cloud Foundry and trying to write code in TDD. I was struggling, really hard, right? I would spend an hour to write a piece of code, and then I would sit there and say, now I need a test. And I don't know how to write a test because I don't know what to cover. And the reason of that is because I don't think in terms of TDD. I don't write the test first. I don't think about the behavior first. So, the struggling keeps on going until I had the opportunity to join the Dojo program. That's actually the turning point of my learning. Cool. So, I want to talk to you guys a little bit about what the Dojo program is for Cloud Foundry. So, traditionally, to gain core committer access to an open source project, it'll take up to a year, if not longer, if at all. It's not easy. So, what the foundation offers right now is the ability to gain committer access through this thing called the Dojo program. And what you'll do in the Dojo program is extreme programming and TDD and learn a lot about our processes and this is for a span of about six weeks. And at the end of this, you will have core committer access and traditionally be able to rotate to another team within CF and continue to work on the project. And Simon, you recently went through this about six, seven months ago. You want to tell us your experience with it? Yeah, sure. So, I was in the Dojo program for eight weeks and during which I was in Diego team. I learned a lot about the Cloud Foundry core bases. I learned a lot about TDD. I learned a lot about the CF teams processes. And in these eight weeks, it actually transformed me from a traditional programmer to one today. It's pretty amazing if you think about it. I can easily spend twice as much time to learn TDD on my own and I wouldn't get nearly as far. So, let me share my Dojo experience by telling you what you can expect during the program. So, in the Dojo, you can expect you will be pairing a lot. There will be always a personness to you while you code. They will always be looking over the shoulder to make sure you don't slack off. They will always ask you the right question for you to think and they will be questioning every single of your decision. And that's a good thing. That's because your pair might not always be right, but then they introduce this different angle to approach to a problem. They force you to rethink what approaches you should take to solve a problem. They force you to re-assemble if your approach is correct. So, solving a problem with two people is always better than one. So, this is actually a picture of actual pairing happening. So, I get this picture from an old slide from Dr. Matt, so the credit goes to him. As you can see, there's two persons looking at two monitors and even though they're looking at two monitors, they're looking at the same content. It's actually one computer. Both of them have access to the keyboard and the mouse. They can type and move the mouse at the same time so you don't really want to do it at the same time. So, usually what happens is one of them is the driver, the other one is the navigator. The driver will be typing on the keyboard coding doing actual work and the navigator will observe. The navigator will try to see and the navigator and the driver should swap row every now and then so you don't get bored. So, the second thing you can expect is to write in TDD. A lot of it. So, as I said before, TDD is really, really hard to learn on your own. And during the Dojo program, it's really helpful to have someone that's fluent in TDD sitting next to me. They force me, constantly forcing me to think in terms of TDD asking the right question. They ask me how do you want this code to behave and what kind of test you can write right now to make sure the behavior is there and the test is validating the behavior correctly. And if I'm stuck, if I don't know what to do, my parent is there to help me solve the problem. And when we finish the problem, my parent is there to help me to verify everything's going alright. So, another thing you can expect is there's not a lot of interruption in the Dojo program. You'll spend most of the time coding. And that's a good thing for a programmer. We want to code most of the time we don't want to be stuck in a meeting all day. But there's also a few meetings that will be attended. These meetings are many designed to help with the agile process to make it more smoother and better. And basically, there are also channels to encourage discussion, conversation, and to bring up issues for the team to discuss. And depending, every day will be a daily stand-up. So, during the Dojo program, there's actually two in a day. There's a big stand-up, there's a small one. So, at Nile Cloud, everybody will gather around for the big one. They talk about three things. The stand-up will be very brief. Only these three things will be talked about. The first one will be help and interesting. So, anyone with an interesting topic, they can bring it up with their people. Or if they have any issues, they can also bring it up and ask for help. And the other one, they will introduce new faces. Any new people going to pivotal, they will introduce them and they will say hi as a group. It's a very friendly group over there. And the last thing we talk about is events. So, there's quite a lot happening over there. It's fun. Maybe there's a TED talk during lunch. They will talk about what events happened that day. So, after that, the big group disband into small teams and I will go back to the WHO team and that's where the teams stand-up happening. We'll gather around the white board. We'll talk about what we have done the day before. Any blockage, any issues come up, we'll discuss it. And then we'll also decide who to pair with who for the day. So, another meeting is the IPM, iteration planning meeting. So, this is the meeting that usually happens in the beginning of the week, usually Monday. The teams come together with the PM. We'll scope and estimate the work that we're going to do, go through for the week. We'll bring up any potential blockage or difficulties. And the team will also come together to vote on the difficulty on the story or the work we're going to do and record them in the backlog. And the last meeting you can expect to go to is the retro. And this is a fun meeting. It usually happens on Friday so, yeah. This is the meeting basically for you to talk about the feelings. And you talk about the work that you have done in the previous week. It doesn't have to be technical work. It can be anything from technical blockage or you can complain about the cologne of your pair. And it's a place for it to vent. And if there's any issues coming up during the retro, there will be an action item generated. And the action will be taken to resolve the issues and problem. So we will make the project better next week. So after the eight weeks, I rotate off the dojo program and transit into the COI team. And that's actually when I met Derek. Yeah, so I want to talk to you guys a little bit more about the COI team. And first, why Simon rotated from one team to another after immediately finishing the dojo program. Huge reason we do team rotation with that collective code ownership. And that gets it throughout the company. It gets you vision on what the rest of the product is doing. So it keeps people fresh. It keeps people engaged in different parts of the product. So the COI team is an interesting team for the foundation because it was the first team to be split 50-50 with IBM and Pivotal engineers. So there were one pair of Pivotal devs and one pair of IBM developers. So the second part of that is after Simon's rotation, he was no longer coming into the office. So we had to do remote collaboration alongside his colleague. So we had a couple of tools we would use to handle things like pairing remotely and meetings because you want to get that in-person feel. You don't want them to feel disconnected just because they're not in the office. So we're going to talk to you a little bit about those. Thanks. We handled these with Google Hangouts. Simple, easy to use. Anything that we needed to traditionally write down on a whiteboard, we'd end up putting in an Excel spreadsheet or a Word document, really, whatever fit best got us what we needed out of the meetings. Second was the actual pairing. This is the hard part, right? This is seven to eight hours out of our entire day working with someone else. Pretty smooth. And we was ScreenHero. ScreenHero did what we needed, given you needed a relatively good internet connection. But what it allowed us to do is each have our own mouse cursor and keyboard and share a computer and do that really well and pretty seamlessly, remotely. And it also integrated the voice chat so that we wouldn't use the second program or anything related to that. And then team accessibility. So now your pair or maybe the pair working remotely is not in the office and they have a question for the runtime team. They have a question for the services API team. How are they supposed to get in touch with them? How are they supposed to just walk over like we normally would and ask them a question? The way we solve that right now is Slack. Slack is a great tool that allows all teams throughout the entire company, everything like that, to hit each other up either on a direct level or at a team level with channels. Right? So it's good because it allows for that cross communication and the text editing is sane, parses mark down. You can read what they actually send you and not cry a little. So thanks Derek. We're coming to the end of our talk. We've covered quite a number of topics. So we talk about the process the CF teams are using. We pair during the code and the Cloud Foundry is written in TDD. It's a very hard program technique to learn for newcomers. But luckily in Cloud Foundry we have this program dojo for you to leverage. It really helps. It's pretty awesome from personal experience. And also there are people doubting that whether this agile process will work or not when not all the contributors are centrally located together. But I can tell you that with the help of tooling it works actually very smoothly. So I don't really feel the person next to me or the third person I'm pairing, they're not next to me. I can hear their voice real time and see them interacting. The only thing I don't see is if I turn my head over, they're not there. Okay. So this is the end of the talk. I hope the talk helped you to understand some of the processes the CF teams are using and also helped you understand what the dojo can offer you and can do for you. So right now we wanted to open it up to any questions you guys might have for us. Any question? Yes. I think there's somebody coming to you. How much does it cost? So to better answer the question we have our own foundation CEO here today and there's no better person to answer this question. Yeah. I think she'll hand you that one. She's chasing it down. Sorry, Simon asked me to show up. He said I'm going to get some questions about the dojo at the end and I'm not sure I can answer them all. So I said I promise I'll come. So the dojo is free. So today by mandate every company that offers a dojo access will be free and we are guiding all of our dojo companies including EMC GE is announcing a dojo today IBM announced a dojo yesterday the Cloud Foundry Foundation dojo is being established starting June 1st in San Francisco at 535 mission not too far from pivotal but also not too close and we'll be hosting Huawei and IBM contributors there it is not a revenue center and it is a gift to the community it also has to be open to random community members who want to come in not just members of the foundation. Hi, you mentioned that the process takes somewhere between 6 to 12 weeks what kind of things do you look for in terms of abilities with TDD in the participants at that end? I mean how do you determine whether it's going to be a 12 week or a 6 week? So how do we determine the amount of time that you would be in the program itself? No, not so much the time what kind of level of mastery of TDD are you looking for by the end of that period because I presume that's what really determines how long it takes rather than whether it's 6 or 12. I don't know that we've had an experience yet to where we've had to say alright at the end of this it's been more of a guideline 6 to 8 weeks it's when people have felt comfortable we haven't hit a point in which it's like 6, 10 weeks in it's like alright doesn't look like you're getting it yet a huge part of it is we do an interview before you come through the Dojo program to make sure that it kind of aligns with you know our process and the process of the person coming in that they're open to it because it is something that everyone really wants to do right it's not something everyone really feels empowered to do so it's honestly I can't tell you of a failure case we've had based off of they've been in the Dojo program and now we're like well actually you know this isn't going to work out so I can't give you an exact guideline on that we're not looking for anything specific at the end so without a Dojo program can someone become a committer is there a way that might be a better question what is the podium like oh is it possible to turn this my on on the podium yes alright can you hear me I can just belt no it's on now that I've gone through all this I've forgotten the question can you start again it's very rare so the only example that we can think of is Michael Frenkel who is kind of going to be other nuns such as in the community of course but to give you an idea of how Michael became a contributor he took it upon himself to rewrite the DEA he said this is in Ruby, this is kind of slow let me rewrite it idiom for idiom in go did the whole thing, tested it, ran and he showed up with this pretty significant code contribution that's probably not PAFE so in general in order to become a committer you need to go through Dojo as a contributor you can certainly contribute through all sorts of different gifts requirements bug reports and PRs in general if you're going to submit a PR be in conversation with the team the lists are very very open you can see what's up you can find out if it's in a story that's being run by the project lead and then you can contribute it's a very opinionated open source project we're working on things in a very distinct way we're building a distributed system software they contribute to communicate with this team not through random PRs but signal let us know that you're coming and we'll help you, we'll help guide you in thank you I thought I saw a question where's the mic mic you're really close to asking you just tell us your question a skill set yeah I'll go ahead and answer this so skill set when you enter Dojo this will be the last question so skill set when you enter Dojo generally we look for someone with an openness to pair we have a pretty defined process for how to find out whether a person is open to that skill set is not based in any particular language or number of years programming or a degree in a particular way it's really we interview you, we decide through some set of metrics whether or not pairing is really going to work and that's both ways whether or not you're going to really like pairing and whether we think you're really going to be a good pair because that's super important to us so there's not an immediate metric that you need to have it's really are you open are you able to learn quickly and learn a new process I'll make one comment what I like so much about the engineers on this project is that the RPI the test that he's referring to is structured it does end up with a score but one of the most interesting things is it explicitly tests for empathy so for empathy with the other person and other people in the team that you're going to be working with as well as empathy for the user so hopefully that has made its way into the code and becomes evident in the community so I think we're coming to the end of the time we're out of time I will be in the CLI open house at 1130 which is at the hobby launch at 1130 so if you have any more questions I'll be there we'll hand it around a little bit right now for 10 minutes and thanks for coming and thanks Sam for being here answering all the questions thank you