 So, we will get used to the noise. Nice meditative device, very annoying after I do it about six times. There's a purpose to this session. You do not need to be a programmer for this session. I need about one-third of the development environments. This is targeted equally at the product owner-slash-business analyst role and at the programmer role. Both roles need to know how to slice product requests finer and finer and finer and finer. And so what I want is for you guys who are programmers at the end to be able to slice any request you get into really razor thin slices of functionality that you implement, preferably in 15 to 30 minute increments when you can check it in your code. And if you're a business analyst product owner that you can, if your programmers say that, it will take me two months to implement that you can make your request smaller. So, let's just try a couple of things out and we'll have to rearrange the seating in the room so to get the balance of programming and non-programming people in here. How many people of you, I want to go for the business analyst product manager, product owner category, so not many. In other words, we oversold this to the programmer crowd, but a few, so that's very good. Now how many of you are programmers? I expect to see most of you, okay? And so some of you got enough to bring your laptops and some of course, as I predicted, had no idea that laptops would be useful here. All right, so let's first do the receiving. So what I have learned is we're going to have one person programming. I don't want any solo people, even if you have another programmer sitting next to you, that's fine. I want to put in groups of two or three. If you have one person programming and three people watching, it is really, really boring beyond boring, so that's too many. If you have one person programming and two people watching that works, you will watch programmers program, and so it's very boring. Okay, but there's stuff to learn anyway. So can you please reseat yourselves in whatever fashion? So you've got one programmer and one or more assistants. Here you go, let's go. How do you set it up? All right, at this point, please close the laptops. Do not work on the problem in your code until I give the code signal. Close the little... Close. Even if you're quittering. Close. So I can just all be present here for the session. You can leave anytime, doesn't disturb me at all, but you're going to be here. It's my request for you. Okay, so here's the problem statement. The person who's got in mind a particular project has in mind some sort of an animal between a horse, a giraffe, and an elephant. And I'm thinking of an animal, and it's bright. And the programmers, being good agile people, are going to do incremental development. And they're going to ship running tested software every one, two, or three months, typically that kind of pace. Which means they need to get requests about what part to scribe a section of this animal for us in some detail, right? That's what... Ah, the animal's got stipple tied in a long tail. Okay, and you build it and then you ship it. Now that's incremental development. And I'll call that kind of... I'll call that flank steaks. Flank steaks are about one month's worth of work. They're all on flank steaks. So, assume people are supposed to know how to do that. Oddly enough, I get told periodically customers, the product managers go to the programmers and say, we need to do this. Oh, that's two months of deep, deep, deep value of work. Yeah, but we need, you know, flank steak size. Can we have delivery? Oh, this is deep, deep complex. Two months. Can I come out of my room and see light for two months? So I need the product manager person to learn how to make smaller flank steaks. Now that's a month. Now let's say you're doing, you know, XP or Scrum or something, and you've got two week iterations and you've got your stories down to the size of about two work weeks. Or even one work week. Let's take a work week. And someone says to me, I never need a story cut smaller than one work week. Never, ever, ever, ever. I'll call that sashimi, right? So we've got sashimi, which is actually a pretty thick little slab of tuna, but it takes $10 to that. But when I visit around the world, the best, best, best programmers, they universally, they're working in 15 to 30 minute slices, 15 to 30 minute slices with a change in the behavior of the system that you could watch every 15 or 30 minutes. And I did this with Nate Jones who did our new website. I came in and said, giving a blank system? Absolutely blank. He said, fine. And I said, here's my first request. We had something up in about 15, 20 minutes. I said, here's my next request. We did the whole website in 15 to 30 minute slices, bar none. Nothing ever took as long as ever. Okay. Well, I go to the round table and we've got about 18 people who've been going to the round table for five to 10 years. And one day I said, how many of you people know how to do that? And three hands went up out of 18. Wow. If at the round table, people don't know how to do that. I mean, it's around the world, people don't know how to do that. And I've been looking for about two or three years for a problem that was small enough. My first problems were too small. Everybody said, this is stupid. You don't need to scoop that up, even if you can. So I finally found a problem that seems to be just small enough and just big enough that it admits of some insight. There's no deep skill to learn here. When you see it, you'll go, oh, yeah, I can do that. I see. Now, I learned this in 99 when I was learning JavaScript and using Notepad to develop. I didn't know JavaScript. I downloaded a program that had JavaScript and I converted it to the program. I needed a JavaScript. And Notepad has one level of undo, control Z. So if I typed in two lines of code and it screwed up, I didn't remember what was there before. So I was lost. So I learned to do one line of JavaScript with an end effect that changed so I could control Z until I got that right. In that exercise, I learned how to do Carpaccio-based programming. So I understand most Americans do not know what Carpaccio is. Prosciutto? How we do it on prosciutto? Prosciutto Carpaccio is similar. Carpaccio is really beef-sliced raw beef, of course. Sliced so thinly, it's translucent. You can hold it up and it's got holes in it. You know, all play to this stuff with olive oil and capers and Parmesan cheese. It was really good. A lot of sort of thing. But it's incredibly thin. And now, here's the point. We have this elephant giraffe horse hybrid thing. And we're going to describe it in Carpaccio. And the people are going to program it. And the hard part is we want the actual whole horse elephant giraffe thing to come out the other end. So that's the problem facing the product owner. And there's a lot of work I won't go into. But how do you kind of big animal into flank sticks and flank sticks and just have sashimi and sashimi into Carpaccio? Today's Carpaccio. Today's Carpaccio day. So I'm going to give you a small problem. And I'll have time. We are going to have 50 minutes of programming time. 5, 10 minute sprints. At the end of every sprint, you are going to demo to your neighbor what you've got. And it has to be running tested code. No, not tested. You don't have to test it. It has to be running code that works. That's different than the last time you showed it. So every 10 minutes you have to show visible change of promise. Every 10 minutes. So the first part, I'll give you like 10 minutes to predict, to create your slices that you think will work. We will analyze them a bit before I let you start. Then I'll give the start mark and it will run uninterrupted. So I will come up every 10 minutes. I'll leave Jonathan's session. I'll come back into here. I'll take my little noise makers and I will say above the screaming hubble. End of sprint demo time. Show what you've got to your neighbor. Now I will encourage you to save every version as you go because you will be mid something when the beam goes off. And that won't be the piece that's working. So you'll want to show the woman you saved to your neighbors. Otherwise it will be oops. Some people spend the entire first 10 minutes sprint just watching the development environment crash. Time after time after time. That has been known to happen. But what I wanted you to get this. Now the problem I'm going to give you is pretty simple. It will have some tables in it which you can fake in various ways. But I never want to hear anybody say in this next slice of carpaccio we are going to type in the tables. That's probably what I'm saying. Deep, deep, not visible algorithmic database design work. Not acceptable. Every single slice has to produce running code with a visible behavioral difference to the previous running code. Now as I watch people you can do this problem in 5 to 10 slices. 5 is the minimum number. 10 is probably as many. So if you did 10 you could implement 2 per 10 minutes. I mean that would be carpaccio up to carpaccio right? If you do working in 5 minutes slices that would be really got the lesson really great. Are you ok? That's what's coming now. So for the next 10 minutes I will have you at your tables in your little groups. Tell me what are you going to be 5 to 10. Minimum 5, 8 is a good number. Of slices of progressive implementation of the problem. Problem statement is the following. You're going to take in 3 inputs. The first will be a quantity of items that are going to be purchased by 5. The second will be a price for item like $80. The third will be a state indicator. U-T-C-A-T-X whatever the state abbreviation is. You will multiply the first 2 numbers together. We'll come up into a discount table. You will calculate a discount. A quantity discount based upon the purchase, the product of the 2 first. You will look that up into a state tax table and add the state tax and output the number. That's the whole problem. There's nothing fancy. I don't care to UI. Command line works fine. If you like input fields it works fine. Now I'll talk about business rules for a moment just so you know this. What I've learned after doing this is out of the 2 things that you're going to implement. The one is the discount table. The other is the tax table. The tax table is more important because you can ship it with taxes but no discount. You cannot ship it with discount and no taxes. So if you're going to run out of time, run out of time on the discount table. Don't run out of time with a tax table. Next, I'm a hardcore business owner. If I catch you gold plating this thing, I will whack your fingers with a ruler. Not that I have a ruler, not that I'll really whack your fingers, but I'll do my best anyway. You get the point. Do not embellish. I find people doing all kinds of really crazy, wonderful, stupid things wasting my money. We only have 50 minutes for this whole exercise. You don't have to get fancy with the UI. If I find you building super fancy UI stuff in the first 2 iterations, I'll get mad. You're wasting my money. Validation. Input validation is nice, but later on. If you get the function working and you get the validation working and you get the UI working, if any of you are super duper, duper fast people and you get it all working, then I want instead of a product price, I'll ask for product code in another table where you look up the product code into the price table and come out with the price so I'll have one more table. So we can add on to this, but your sequence is somehow going to have to be based on those visuals. Are there any questions to the actual assignment? Yes, please. I didn't get the discount business requirement. Right. All of your tables do have at least 3 entries, just to kind of like make it a legit table. There's two ways to do discounts. One is off the number of items purchased. That's not interesting. We're doing it off the total price. So 10 items at $100 each equals $1,000. Oh, $1,000. Why did you know you get a 5% discount with orders of $1,000 or more? So you can set them anywhere you want. I don't care. $100,000, $500,000, $10,000, $100,000, those aren't important issues, but at least 3. At least 3 states with different tax rates. More questions about the assignment. All right. So what's going to happen next? I'll give you 10 minutes to work out your story. And then we'll go around and I'll take some samples and I'll know what the first three stories are. So we all get in sync with what's allowable and what's not allowable, right? And I never want to hear anything about. And in the third slice, we're going to get into what the tax table. Right? Ixon, Ixo on that stuff. Running code that has some visible difference from the previous running code. All right? Go ahead for 10 minutes. I'll check in with you. I'm going to spend five minutes discussing this. Anybody who's got a programming laptop closed that way do not start programming at this point. If you're on email, just take a five minute break from email and close the lid so I can see all what's in it. So they didn't do any cheat goes in my class. I have a different exercise where I encourage cheating. This is not that exercise. Let's just go around and get some samples. If you guys, what are the first three? Use your stories of the language or slices. It doesn't matter what your language is. What are the first three slices that you propose? Given the state of abbreviation return tax rate. That would work. Second? Given a state, an item, and quantity calculated subtotal. Okay? Given the subtotal calculated discount. I'm looking at your paper. I only see four stories. You have to have a minimum of five. What's your fifth story? The UI stuff. Okay, presenting. That'll work. That'll work. Did you see how we got that, right? Five slices each could be implemented in 10 minutes or less. Yeah? What do you guys have for your first three stories? Okay, I don't think we... What do you have for your first three stories? Okay, so we said deliver a user interface that allows you to have the three inputs. Second story was... Wait, so what I want to know is what do I see? You will see, I will type numbers and they will vanish. And they will, right? Okay. Yeah. Yes, now, why is this okay? Because they get to see something. What are we testing here? The development environment works, it compiles, I got something running, right? This is the whole world, and this is one valid whole world. I got something up, I could take it in input, right? And I've seen groups and it takes two splits to get that, because you're something wrong with your environment, right? That works. What's next? Then we said calculate tax on the total, then we said calculate discount. So you'll calculate the total and you'll calculate the tax. You did two things in that slice. Did you hear that? So you can have this thing sliced thinner and thinner and thinner and thinner. Now, if you're a business person and you have developers who are going dark, and you got a big hairy algorithm, you don't have to ask for all the algorithm, right? You can do that. All I want this month is the product of input, right? You don't have to do any tax stuff. Yeah, but while we're in there, I don't want to see that, in fact. Give me a demo of your stuff, though, right? You get the gist, I'm going to go back. You guys had an interesting twist back there at that table. You three. One of you has to be brave and speak up, please. What was, they had an interesting twist I've seen once before. All right, yeah, we just thought that as far as calculating the state income tax, but initially, having them input the state or state abbreviation, we just initially test them inputting any tax rate. So now, instead of having to do the implement the table, they'll have the person input just the tax rate, and they'll have the table later. This would pass. Anybody else? Let's just go, what's your first story? Being able to select items and total them. Excuse me, I didn't say I was going to say where to select them. From a user point of view, they're going to have to select what they want at some point. Oh, I never said selecting a problem. I hear gold plating. What is this? What is my number? What is select? What am I going to select from? Select is your input of the item you want to purchase. I don't have that. That's in the sixth iteration. There is no select item. Do not implement select item. Don't care about select item. Not part of the problem of select item. Do not use select item. I'm making myself clear. Thank you. You guys, Paolo, give me another first story. What's your first story? Accept three inputs and I'll put them. What's your first story back there? You guys are visiting. What's your first, you guys visiting? Are you visiting or are you programming? Programming. Sorry. Just calculated the whole thing. So you'll take in two numbers and three numbers. Two numbers. You multiply them and output it. So it's a nice whole world that's got some little simple functionality. What's your guys' date? What's your guys' first? Let's move down over there. Compute level price. Anybody with anything different, either weird or questionable? Yes, please. It's just different. It's not weird. It's just a mountain state. You'll take two inputs and a mount, like a quantity. No price. You'll take a state and you'll output the state. So you want my data... Hello world and the state tax table in the first slice. Yeah. Basic point. You may want to consider that as two slices. Right? Now what I want you non-programmers doing, you've got a hypothesis of what will get programmed. Not in all cases, but in many cases, what I want you to observe is what the person really programs is differently than what you predicted. So you're going to take notes on what really gets done. So may I just ask your name, please? Heber. Heber. So Heber said we'll take in two numbers and output a state tax rate. He might observe, what's your name? John. He might observe that John had in fact as a programmer on his own discretion had split that into two parts and had done two inputs. First, state tax table. Second, and then you would in your notes note that. You may find after one of the thing that you need a quick change of plan. That's all okay. So you people who are not the programmers, if you haven't ever seen people program, it's interesting how much work it takes to do this absolutely dead simple problem. And people who are business analysts or CEOs or execs or whatever sometimes are brave and sit and watch the whole thing to take away afterwards, I never had any idea how many lines of code it takes to do such a simple sample problem. So that's interesting. But I really want you to be in the group discussing about the slices. Okay. We're all set. It's 407. This thing really takes 50 minutes. Bang. Actually, can I shorten it to nine minutes? I would like to do that. Just a little bit of time to debrief afterwards. It's not going to make a big difference. I've done eight minutes. I mean, John is the answer. He's kind of a scandal by 10%. And you know what? And you know what's funny is a lot of times people will still do quantity discount, the discount off of the quantity, not the product. And I know, because I get the same problem to everybody, and I come around on the fifth iteration and they'll say, you changed the requirements on us. It doesn't matter. That was the rules. Program it up. But it is, the discount is based on the total amount. The total product time, quantity, price. Okay. When I say go, it'll be just 50 minutes and I'll go bang every 10 minutes. Okay, go. All right. It's time. First print. It's nine minutes. 926. Nine and a half minutes. It has to be true. Demo. Come on. I suggest you accept the non-programmers visit the other stations to get demos. Come on. The time has not stopped. It's still running. Get your demo. Wait, whoa. Time is running. It's already two minutes into your second sprint. It's supposed to be 30 minutes. I don't care. Time's running. Total prize. Oh, that's the same. Yeah, they got some on the end of the bar. That's all. Because we don't do 11. 11. There it is. Last one coming up. Okay, make sure you get the hardest thing to lose. My biggest thing. My biggest thing. My biggest thing. My biggest thing. My biggest thing. After a minute. After a minute. 20 seconds. 15 seconds. 15 seconds. 10 seconds. 5 seconds. 4, 3, 2, 2, 1. Zero. Yay. Okay, so, the box, how many people got the base functionality that I requested? Please raise your hands. Ooh, fast-moving room over there. Base functionality, I need the product, look up on the discount table, look up on the tax table. How many got input validation working? So this is what we got. How many people got a product lookup table? How many people got a UI with some any kind of interesting gloss to it? Very good. All right, let's just discuss for a couple of minutes, it's like five minutes to five, we don't need more than that. So, any tankers, any comments on what that was like for you? Anybody, yeah. We were way overconfident in the original level. Way overconfident, okay, very interesting. All right, any other tankers? Yes, please. We succeeded in implementing the business logic program completely crash on the UI. Okay, but it gave me like a sensation, like what was the like for you? I didn't say what did you encounter, what was the like for you? Yeah, you were sitting watching. Yeah, I'm a manager and a matter of program and what I'm getting from this is, yes, it does take a significant amount of coding. My first question is, can you just copy a similar code and paste it? You can copy it from most cases. Well, not sometimes. The thing is, I can also see how character programming would make a big impact. Very nice, very nice. Because you can watch what he was doing and correct things on the fly. And you can see why actually if you had a business person sitting next to a programmer, you can really direct fine grain and catch errors of communication early. Chris, were you going to say something? Okay, fine. What are you going to say, please? Oh, I was just going to say, obviously, this wasn't an open-ended problem, but it seems like it really helps to make it, I mean, that all of our little slices, there were no radars of the code. And so, as a developer, I never felt like, oh, how would we do this? Because it's really, the slices are so stiff, it's unbelievable. Yeah, there's a comment about that. How many of you, let's try this question I haven't asked before. How many of you did in fact use a debugger any time during the session? How many of you, should be the rest of the hand raised with a double check, never needed to open a debugger because if anything went wrong, it was like so few lines of code was pretty obvious what was happening. So one of the reasons people like to do this when they do this is that they never go into a debugger. I mean, when you make a mistake, what, you had two lines of code, you stare at the two lines of code, you fix it. Yes, please, comment. One thing I know was how, I guess I should say that, maybe there's better ways to say this, but the pressure of knowing that someone is going to come over in a few minutes and look for some functionality, that got me really used to understanding what a slice of functionality really is. What is the smallest thing we can deliver and show each time? Each time, yeah. Could be their price with a blue shirt, yeah. Yeah, I noticed once we defined our iterations, the developers knew what needed to be accomplished. I kind of sat back, just watched them work, and once we had this defined, they knew how to accomplish it, they knew what needed to happen, and so they accomplished the end goal when we needed it. They really required me to step in and all the time, step in and all the time. Are you a project manager? There it goes. Are you a project manager or are you a business analyst? Right, a project manager. That's nice to know. What were you going to say? I think slicing up like that lends itself to T&D. Yeah, now you guys did a do T&D. Did you do T&D? Did you do T&D also? Yeah, we started. By the way, it was interesting to me, delivered zero on the first iteration, but you had everything by the last one, including input validation, right? So what was it like for you guys to do T&D? We gave up on it after the first iteration because there wasn't enough time. Yeah. So what was that feeling like? Jeff, I know you. So what would that feel like for you? Well, yeah, for nine minutes, that's what affected me the most. We ended up with 10 more minutes, so it was a tough one. How did you feel about it as my question? And you're like, what's the sensation in you for having to give up T&D? You can give those up. That's unusual for me. It felt kind of like I was losing something, but I was okay with that. Well, you could see in your stages it was coming up though, right? Yeah. But your level of confidence, I mean, aside from the fact that you're used to it, what was missing, level of confidence in the code was, that's a tiny problem. Chris? I was going to say, as a coder, the thrill was pretty exciting. As you can see in the media response within the mind of a friend, as a teacher, there was a lot of anxiety because the code is produced and the code is not maintainable. We'll have to be serious when we get back. Let's go after that one. Absolutely. Absolutely. How many of you, you look at your code and go, pardon the language, this is crap code. So, and remember I said this morning, the hazard of agile is overly tactical work. And in particular this exercise, my purpose in the exercise is to show you that you can slice. And I put this artificial nine minute boundary on you. And what it does is it actually drives you to write bad code. I've looked at that code. It's nasty stuff, right? So in real agile development, you need to stretch out your estimates so you do get the tests, the clarity, the architecture. So I've driven you into a bad spot for coding habit. And I want to highlight that, right? So this is one of the problems with agile that I was talking about, that constant pressure to deliver of people who haven't got time to clean up test, refactor, you know, rename variables, all of that sort of stuff. That is a pressure that comes with agile and you actually have to fight it. You have to fight it very, very deliberately. So you brought it up from the teacher's perspective or the architect's perspective, but even the programmers know this is bad stuff. Are you telling me I should do that? With having an existing development standard in your team help. With having what? With having a coding standard. Yeah, a coding standard. Yeah, all of that helps, but there's more to a crummy code besides just coding standards, you know. You don't get proper internal reuse, refactoring, inheritance, all those things, all the way by the wayside, you usually follow the coding standards. Can I comment over here, please? I also have to consider that we could have wasted a long time making it perfect and pretty and never made use of that. Do you think that would be the only definite known use case before you fold it so far? Well, and let's talk about catching miscommunications. You know, the quantity is count, but I harass these poor people over here, but every class, every class, and so how long until you discover miscommunication and the business requirement, you don't need validation and fancy UI to discover a mistake in the business communication, right? The business request. So we're looking for feedback. It's a validation in a sense of the purpose of the system, the nature of the system. And we could stage now, we could stage input validation, glossy UI, right? We can build it up from there, right? Any other comments, thoughts, please? As you predicted, we did have some fighting in our development environment. Isn't that interesting? Now these guys are like kick butt programmers. I can't believe it. I delivered a zip here, but we only have nine minutes. We have to stop fighting this now and go back and do this other thing. Otherwise we won't have anything new to show you in the duration. So those pluses and minuses, what I care about personally is that when you go home, and if you're business analysts or product managers or product programmers, we will say it's a formula. There's no way to slice it. We just did a formula and you sliced it from the business perspective. And if you're a programmer and you just want to learn like one of the best programmers in the world working, they'll do TDD and they'll do this fine-grained stuff and they'll have something new functioning every half hour. About half hour. I don't know if you guys know that. I've seen that. Anyway, 15 minutes, 30 minutes, it could go up to 45, but people get really itchy if they're not running, tested with improved virtual functionality. So those pluses who are working on a very large business or have to spend several hours just understanding them? Well, I'm not a specialist on legacy and I understand what you're saying. It can take a long time just to locate the place and then you might want to build a test wall around the place. You've got to go into changes and so on. I'm after the line of thinking. I never want to hear anybody say I have to go, I can't cut that out. It takes two months to implement that story or one month or two weeks. I just don't want to hear that word. We're doing a compiler that can't be done in slices. We're doing a database conversion that can't be done in slices. We're doing, I don't care what it is people say and it can't be done in slices. I just don't want that argument to exist. Now, if you know how to do carpaccio at the 15 minute level and you choose to work at the two-day level, sashimi level, fine, that's your choice, what I don't want to hear is I can't do it. So I just want that aha. That's how you do it. Yes, I could do it. And now I'll choose. And I'll choose if I want the half hour or the two-day, the one week, whatever you want. Yes, we have one here and one here. I just had a question. When doing something like this, so one thing that we did is we were always programming. How do you work in my time to learn the better way of doing it? We just hacked at this and we got it done. There was a better way of doing it and there were some questions that I had. Is there a formal way to work that into a workflow so that your employees are getting smarter over time rather than... A big question that hasn't been well-handled in the agile world is how to do, I don't say incremental development, which is what we do incremental. The other thing is would you go back and rework and revise and improve what you've got, the UI and the refactoring of the coding or whatever. In the agile world, we have not built a good language discipline or anything for the talking about that. Some of us feel this is a real rock. Now what I do is I say users' bill of rights, the user should have two viewing opportunities before it's shipped. You can't even possibly declare you understood it. You've shown them and picked up two re-changes revisions. That's on the user side. There's no language for that. What you bring up is on the technical side, when do you get time to say, I know a better way to do that, give me some time to clean it up. We don't have language around that, but I know it very well. So we follow pattern at our office, which is basically red-green refactoring. So build a failing test respect, get it to pass. But what are you saying? Let's say I just thought of a nuts refactoring. I thought of a different algorithm. Yeah, read from it. We have a comment here. Just the way this progressed, the code, and the slices I can imagine as the PO walking in, just taking a quick look whenever he ran in. The way he wrote the print line, the total for this is this, without finishing anything of value to me, I just walk in and see, just walk over to another person to see. Totally. Without any communication, without having to untrust his word for it, I could just see it run right there. Or if he kept up, let's say on an hourly or half daily basis, a version, the latest version that runs, and you could just go onto a workstation and just go try the latest thing and see the changes. The product owner should be interacting with the team at least on a daily basis. I just walk by, I could catch and always the light. What do you mean quarterly, discounts based on quarterly? No, I meant that thing, right? I can even imagine, I've been with distributed teams, if they have this environment you're talking about, where I can log in and check this stuff out, I could just chat and I'll get this. Absolutely. How do you align that with an existing, let's say for example, you're working for an organization with an existing IT governance process? With an IT governance process, they're below the level of what the governance process is. They don't care. They don't care what people do on an hour-by-hour basis or paid-by-day basis. They've got gates and milestones, typically are like, do whatever you do and show up in weeks or months and pass this to you, right? So what we're doing, which is on an hourly basis, governance process in the competition is sort of whatever you like. It's time. Now, shortly, like in the next 5 or 10 minutes we're going to start with a question. Michael Spade is doing some weird thing called a constellation and I don't know what it is, but it's a very bolder kind of a thing that he wants to do with that ground development. So if you want to participate in that, he needs a seed, so I'm going to need a seed in his constellation. That's going to start in 5 or 10 minutes. That might be interesting to take a look at. You may ask for volunteers, some kind of participatory thing. For the rest, thank you very much for your time. I'm glad.