My career mission is to help geeks feel safe in the world. My business proposition is to help your engineering/product/design organization grow from 100+ people to 1000+ people.Programming brings me joy. The only thing better is teaching programming and watching the faces of students when they "get it". Therefore, I arrange my work to maximize the amount of time I spend programming and teaching programming.I always have a portfolio of research projects going. Currently I am studying:* 3X: Explore/Expand/Extract. As a product matures, the tradeoffs affecting its development change dramatically. What are these changes and how can we respond to them?* Power law distributions. Power laws appear despite our best efforts. How should we adapt our tools and techniques to the inexorable laws of nature.* Programs as nature. I study the structure and evolution of programs using the same tools used to study the structure and evolution of the natural world.* Quantitative studies of software engineering. For example, I have data that implies that programming language does not affect the size of diffs but deployment frequency does.* Coaching. How to deliver it, scale it, teach it, and measure it.* Tree-based tools. Source text is dead, it's just taking a while to quit twitching. Some day the whole toolchain, from editors on, will work with syntax trees.* Smalltalk. What does Smalltalk still have to teach the programmers of today? Lots, it turns out.View the profile
About the talk
Kent helps geeks feel safe in the world. In Kent's career he has constantly challenged software engineering dogma, promoting ideas like patterns, test-driven development, and Extreme Programming. Currently Fellow at Gusto, he is the author of a half dozen books.
Oh my gosh, good morrow, friends. Here we are. It is. Oh my gosh. It's already 11 Central. We are into the last day. They were in the closing. Third of this Marathon known as the Ruby comp. Okay, here we are. Well, it is my pleasure to welcome you. In today, 3, as you were all very well aware the community on slack has been super, super vibrant and I hope you had the opportunity to really participate in as much as possible. I have heard rumors mostly seen pictures that folks
did do the karaoke last night upon nine Zoom, which must have been so smooth. I would have matched it or not, but regardless, I have seen so much fun, fun fun stuff that's going on. So massive applies to all of you for keeping this community alive and vibrant. I really appreciate it personally, and I know that all of us there first-timers here, appreciate it too. So thank you all. Alright, so let's keep this day off. I want to bring to the stage. Marty one of the organisers here, Ruby Central, one of the directors of the introduce our keynote for the day.
How you Marty? Hello. Real Denver, because you're all right. Normally, I'd be able to hear you all got back from the audience but or virtual sex not going to happen. I do do sorely missing on person. I am a director by the way, it would be Central and you'll often see me onstage before. But so far with this conference, I've been behind the scenes doing this stuff in Cub cast. But this morning, I get introduced our next keynote speaker. Now, for some of you, he needs no introduction, you're familiar with his work but I suspect, there are a good number in our audience who
might have came back though, I suspect you have encountered some of the ideas, he championed over the years. Personally Kent's Works, have had a major impact on how I approach in. I write software, I remember distinctly back in 2004, when I joined a small, 14, that was practice. XPR extreme programming that, I then had to reduce these books and it changed everything. I'm so the Sundays ideas, you're probably familiar with developments unit, testing refactoring, thinking and patterns pair programming. Another
Advil practice, which is Wilder think that back? Then we, it was fairly rare that this was done on teams. And I remember having to Advocate that we would use and he's practicing on to my soccer teams, but now it's fairly commonplace. So Kent is no stranger to our conference. Has he spoken here before the last time was in 2015 in Atlanta at 4 rails, but he's come back to share his insights with us today. So without further Ado, please welcome him back to our virtual stage.
The one of the lessons of covid in isolation, and lots and lots. And lots of video is it every meeting is better if it starts with banjo. So there you go. That's the that's my talk. Thank you all so much for coming. So I told this story just now in the green room and I'll tell it again. I've always had a lot of imposter syndrome around music. I've been playing for fifty years and I've always liked of. I only I was better so I figured if I just forced myself to practice, I would
get better and then I'd be good enough. And so, I would force myself to practice for a while and I get better, but I was never good enough. and, Then I get discouraged and the cycle continues. And when isolation started, I just made a habit of starting every Zoom meeting 2 minutes early. Can I see zoom on on Chromecast? Am I going to be anyway? We'll see what happens if I cut off immediately, you'll know. So I would start every Zoom meeting with a couple minutes of Music, banjo guitar.
NFL, I show up early and then I noticed the people's other people started showing up early just to catch the music and they loved it. And they gave me so much positive feedback that I wanted to practice cuz I want to be better cuz I wanted more of that stuff. So, your second lesson is, it's not about the Ironclad, willpower, it's about human connection. I hate when that happens but there you go. Okay, so I do have other messages than that. That would probably be plenty, but I do have a message. And what it is, is the general
Principle reversibility as applied to software development and I'll make another medic comment if you haven't seen me talk. And by the way, this is my first railsconf Ruby Conte talk ever. So on that first-timer, that, that a dimension. Unwind made a comment. Is that if you want to come up with ideas, come up with combinations of ideas. It's really hard to think up a new idea idea from scratch. But relative to that it's easy to take two ideas and nobody just nobody ever put together before. Put them together and something interesting comes out of that. So lots of
stuff I write you'll see that as a as a theme and here it is, reversibility is General Principle as applied to team software development? So we're going to take those two things together and see what comes out to eat the other side have had some questions about my presentation software. So this is the canson XL 160 Grand, Prairie View pinheads out there. I have a lot of pins and a lot of paper. This is beautiful paper height, highly recommend, and then and then the East Windsor and brush markers again.
Highly recommended. So that's the software that I'll be using today. Presentation. Maybe we'll have a giveaway, if any of these lights turn out, cool. That would be fun. Okay, so, First ideas, River, stability, and what are we talking about here recently? Debuted a workshop with the Jesse Tron. Jessica Kerr called invitation to systems thinking, and as the wheel turns, as it always does, we we went from a very reductionist Approach to software development to a very holistic one. And now we're back to
kind of reductionist like oh, what are the numbers? And we're going to make the numbers. Go up and then everything will be better. And whenever the wheel turns that direction, the antidote is systems thinking. So this is the idea that Jessica's motto is relationality over. Rationality is the idea that in any complicated system, you don't have control, but you're not helpless. It's, there's a bunch of pieces in your system and it's their relationships that really make it challenging. I mean, it's both the power of the system is that you
get more than the sum of the parts. And that's also what prevents you from having control over what the system does. You can go look at systems thinking. Dev for information. If you're interested in this Workshop, it's a lot of fun. We just did the first one a couple weeks ago or going to do another one in January and of Commercial Club. in two thousand and 1 to maybe an early, early extreme programming conference. We had a presentation by professors
Anna Noto, who was the dean of the school of Economics at the University of trento, And he said, this extreme programming something. I remember, this is the point at which extreme programming was wild and crazy in this could never possibly work and he said, from it, economist's perspective, extreme programming makes perfect sense. And here's how it makes sense, and he gave this fantastic presentation, some of the clearest thinking that I've ever heard. And it still took me about 15 years to figure out what he was talking about. So,
here in a nutshell, is it you guys will pick up on this quicker than I did. Thank goodness for that. What makes if you have some big complicated system? There's no clear relationship. Between inputs and outputs. You change the inputs and then what happens next? Who knows. Do you have a giant Factory and one little thing? Seemingly little things can go wrong in the whole Factory shuts down or you can take away an element in the factory and all of a sudden everything works more smoothly. So what is it in the
/? Rationality Parts. You can't figure out by looking at all the pieces in the system was going. And what the professor said was, there's a reason for that and it's because large complicated systems. Have. First, they just have many, many states. So I'm going to be sad that I wrote that large, but there you go. Lots and lots of state so you might think o the system is in this state. So if I do this thing, the same things going to happen, the last time, it was in that state woke, there are two too many states to be able to say the system is in this state. I remember the
first time I ever pushed Coda at Facebook. The message that came back was your code, was successfully pushed to 6300 out of 6400 servers and I panicked, I do know what's on those other servers people said hi, who knows? Not causing problems. Don't worry about it. Each one of those servers was in some kind of state and it wasn't even possible to understand what the states were much. Less understand, what would happen if I change the inputs. How are the airports going to change? so, another
problem here is the interconnections and this is the idea that the, the pieces in the system don't stand alone, any peace could alter any other piece. So, for example, at Augusto, my my employer or we do small business, payroll and benefits If you look at Augusta with self as a system, and how we deliver service to people, you can say, well, this many customers call in with this kind of problem in this many customers calling, with this kind of problem in it, it takes a person this many
hours to resolve it. So, Retroactive address changes cost us $14 per customer per year or something like that. We can take all the cost of serving our customers and we can we can break it down and we they will here's the benefits ones. And here's the payroll ones and of the payroll ones than this and then it up up up, up and down. Here we got, we have $0.14 per customer per year, whatever it is and and that accounts for all the cost of all the historical cost, but Those aren't leaves in a tree. All of those seemingly leaves are
potentially connected to all of the other ones. So I can reduce over here, I can reduce this $0.10 to Zero by making some change and accidentally caused this other one to increase from $0.40 to $2. And if I'm not looking very carefully at what I'm doing, those interconnections are going to make it impossible for me to go in control. This, this system, I tried eliminate $0.14 here, and $0.14 gets eliminated from the top nap. Sometimes eliminate 14 cents here and $2 goes away from the top and sometimes $2 increase in the top. So that's the sense of
interconnection, we're not dealing with leaves in a tree. We're dealing with items that are all potentially connected to each other and in software development, we talked about coupling as a measure of that that interconnection between the elements in a software tonight. A third source of difficulty is a variation. You're the reason we can't control this system. Is because things change the external world will change. Even, internal world will change something like
we're in a mechanical system. Will cause small differences and sometimes small differences. Make no difference in the end, sometimes small differences, don't make very large differences in the end and we can't account for all of this variation. and the last element that makes systems impossible to control is reverse is irreversibility Which is once we make a decision, we can't unmake it. And irreversibility is all around us. I recently decided to downsize my stuff and so I thought well, I've got all these boxes of books
that I collected, four decades index. Eight decades has like 50 boxes of books and their stored away. But I'd like to just get rid of them but I feel kind of funny about getting rid of them because I have a lot of attachment to these books. If I just discarded the books that would be an irreversible decision, I couldn't get them back. Couldn't even remember what they all work. Is a thousand literally thousands of books. So I thought what I'm going to do is I'm going to scan all of my books. It's a good read. If
I want to read them again, if I want to remember what I've read. And if I want to read them again, Kindle is there. I can go get a copy, get an electronic copy and I can reread anything that I've ever read in the last. Years. So that's a, that's an example of an irreversible decision. Turning into a reversible decision, and another part of my downsizing is my journals. So one of my practices, every morning is, I'll just free associate for two pages worth. I'll just write, write whatever comes into my head, and sometimes it's
trivial stuff. And sometimes, it's my plans for the day and sometimes it's thoughts and so on. But I have a Shelf full of these journals. I thought, well maybe I should get rid of those too cuz it feels good. Like 50 boxes is just gone. That's like, 3/4 of my physical stuff is gone and that's all good. Maybe I should get rid of my journals to, but getting rid of the journals is in irreversible decision. I was able to make the, the, getting rid of the books, a reversible decision because of the magic condolence on getting rid of the journals. This irreversible. Now,
I didn't make it into a reversible decision by carefully. Scanning each paid blah blah blah, but that is definitely more trouble than I want to go to. So there we have these decisions which can be reversible are irreversible. If you're in a complicated system and you make an irreversible decision, you can't take it back if you if you if you accidentally Send your the details of your customer list, out onto the internet. You can't, you can't take it back and distinguishing between reversible and irreversible
decisions is really important. So back to professors, I'm not so he said, it's these four factors that make operating complicated systems. So difficult and extreme programming makes perfect sense. As a way of addressing this kind of complication in software development, because it takes many many decisions that previously were irreversible and makes them reversible. So if you plan every day, plan every day, then something changes you realized yesterday's plan was bad. She only lost a day. We organized the priorities in a way you go. Compare that
to the old timey waterfall e, which no one would ever ever do. If this is another one where the wheel is turned in some, how people are talking about waterfall? Like it works, and it doesn't work for all the reasons. It never worked and there are alternatives. Okay, thought I'd explained that Dragon. Nah but you know a big waterfall till we got this is the scope and we're going to deliver in six months and that's that that's an irreversible decision. If you decide if you realize oh that's the wrong thing to do. It's really hard
to change that because you made commitments about what's going to be delivered when, but in the XP planning style and it are they planning Style Okay last week but we thought we needed this and we don't really need it. Now, it's now we don't have anymore and away, we go, you replaying and and and off you go work. The design is wrong. The architecture is wrong. You discover that later because you always discover things cuz you alternative to discovering things being dead, and nobody likes that Can you change it, there
aren't you. Reversible decisions in extreme programming? Of of that sort. Now, as I try to apply the geek, I tried to apply these principles to my life and it turns out there's plenty of irreversible decisions in your life. You can't just take back a statement that you made to someone, you're in a relationship with its there's no revert. 4/4 dumb things that you say, enough said, plenty of them things, so that's not always possible. But there are certainly cases where you
have irreversible decisions which can be turned into reversible decisions. And that's part of the power of this style of thinking about complicated systems at what we've noticed. Just today. I used, I used the phrase oh that ship has sailed That's that means that the decision was irreversible and it's already made. So, even baked into our language is, we have the disease metaphors for describing reversibility. So that's that's part number one, that's you got
complicated systems. You can't control them because they have too many states there. Too many interconnections between the elements, there's too much variation. You can't possibly see in the decisions that you make are irreversible. So Henry Ford, for example, in the big ma tea plant, he chose to reduce the number of states as a way of controlling the system. So the reason that all the you can have a car, any color you want, as long as his black is not to Henry Ford. Thought the black was the greatest color Henry. Ford realize that? Yes, I have
paint. No, I don't have paint is much simpler to manage than, do I have the right amounts of these various colors? So he deliberately simplified the product to reduce the number of states so that he can operate that big, Located Factory in a way that nobody really had before. Okay, so that's reversibility. Now, I'm going to talk about some of my more recent Research, which is on software design, been designing software for a long time. So, confident about, but the boundaries of what I can design and can't design, but I started to dig into it and I
realize how I don't really understand this very well at all. And I started working on a book called tidy first, which this is this diagram is taken from, I'm still working on the book, hopefully, we'll get it done. I will see what happens. Anyway, so here's the basic Loop in software development, go with the different color because you have an idea. So we'd like the software to do xynz, okay. And from that idea, you need to change the behavior of the system.
So what we need a button to test XYZ. Okay so we had the button now. The behavior is different and now we can evaluate okay. Was that a really a good idea to people using the people like it or there any problems with it? And from a certain perspective, this is what software development is, if you're not a programmer, this is what software development looks like you. There's a team, you say, I want some later time a button that does X appears as programmers, we know that this isn't
the whole picture, That changing the behavior of the system can be easier or harder, depending on its design. The whole reason we design software is so we, so we can change it. If we never needed to change it, then all variables could be Global. All we would need subroutine we just have a routine and if you do income, the inputs and probable outcome the outputs. The reason that we break our software systems in department so that we can change them. And
that. That cheese that we those changes that we make rely on the structure of the system. And this is the part that kind of underwater. If you're not a developer, you say, well I could add this button but I have to go change here and here and here and here and if we rearrange the design then I don't have to change one place. That is change the structure of the system that leads to a change in the behavior. So there's a flow that you need. Sometimes you can go
straight from an idea to the change in the behavior and where you going? It's not hard sometimes though. You do you take an idea and you thinking this is harder than it needs to be? So I'm going to, this is the Tidy first flow from the title of the book. I'm going to tidy first, I'm going to change the structure in a way that makes it easy for me to change the behavior later. So I change the structure now. Changing the behavior is easy. and anyway, I go That's not the whole story from the,
this brings up. It's a whole books worth of stuff and I'm giving you a half of the talk is about it. So how can I possibly get everything and I can't, In through the nose out through the mouth, another that would be worth the whole talk right there. I promise. Okay, I got this. So sometimes you change the baby here and you said you had had to do it in a messy way cuz sometimes you sometimes there's not a clean way. You can't think of a clean way so you just
go from your idea to change the behavior and then you say you're sitting sitting there. This offense happens to me in the middle of the night. I wake up and I only this system structure like this. Then those Behavior changes we wanted to make would be easy. So there's another flow that goes from, I change the behavior. Do I change then I changed the structure. This is not, this is Thai tea after. This is okay. I made a mess stuff up to get this finished and now I now I invest in the structure so that future changes
like that will be cheaper easier safer. Simpler easier to teach other people to do and so on, all the good things about a structure that's adapted to the kind of behavior changes that we want to make. Part of the magic of software as a business, is that. Sometimes the structure itself will suggest ideas, and this is where is rigid separation between product and Engineering is suboptimal, because the programmers know what's cheap and easy. It's difficult to have that kind of intuition from outside without having an appreciation for the structure of the system. So an
example at Gaston, we had a tax calculator. We actually had to text Jackie later, we had one that works. Let me see, I'll make something up the sounds plausible and then I'll check later one that works when you were signing people up in one that works when you're actually running payroll. And it made at the big berry beginning that made sense. Different teams were working on these two things and they wasn't until they've grown big and complicated. Cuz it tax calculator, all my goodness. If you want interesting domains
Working on payroll and benefits is actually super interesting cuz it's got so many Corner cases. We had two full-fledged tax calculated before we noticed that we really had to. And that every time we changed one, we had to change the other, which is the definition of coupling. So one of the senior engineers said, hey this isn't right, couple of senior, people went off and merge the two calculators into into one was soon as we had this this one tax calculator with a very
simple interface. It was all Primitives coming into instead of being wired into the rails, this and database that we had one calculator, simple input simple output. We said, oh, someone for marketing said, oh, I wish we could just have a tax calculator on our own page. So now there is Does a programmer overheard. This conversation is it? Oh well that's easy. Now, it would have been really hard before investing in the structure but after that, the structure, it's quite simple. So you go, they got so. Cam, I don't remember what you can say.
What would my paycheck look like if I'm in Maryland and Ava, Baba, Baba, and you put in the all that stuff and how come the numbers? And those are exactly the same numbers that would occur. Were you this sign up for the service? So sometimes the structure itself. Creates ideas. Okay, so Here we have. This is. This is development. And It's a, it's a this is a complicated system. There a bunch of people involved. There are bunch of Technologies involved. And it has all those the development of a software
system has all those features that we just went through as many, many, many states, there's interconnections between stuff that nobody has a clue about, there's all kinds of variation. Covid hits and all of a sudden all of your road maps, which aren't Road. Road map, is a lousy metaphor anyway, should be like a compass directions. That would make more sense. We think we're going this direction. Well, Kobe comes along, and you're not going that direction anymore. All the sudden you have to deal with the payroll Protection Program and off you go and
everything has changed. So that's variation happens, all the time, people coming and going on and on and on and on these lots of variation and you're making It. If you're working in large blocks of time, you're making irreversible decisions. And if you're making you reversible decisions, that whole structure of software development is going to be impossible to control. Even if you break it down into smaller reverse and more easily, reversible decisions you can't control
it. But neither is it is it completely out of your control? So that's where this is where. okay, so I'm about to get to reversibility Here's the, here's the thing to know, if you have the behavior changes that you make to the system are irreversible if, if if I change a line of Kodak. So, and we now submit the wrong reports. The IRS you can't just say, woo back seized when I know it has by change the behavior of the system. It has real irreversible consequences in the world. So, I want to treat these decisions irreversible decisions, very
carefully. I want a vet them. I want to validate them. I want to be really, really cautious with them, but this is a point that, like, at escaped me for so, so long structured decisions about the structure or system of the system are reversible easily, reversible, I extract out some helper method and then somebody comes along and says, I don't like that, like, okay, inline? It It's as if I hadn't extracted that at all, when you get to larger scales, it can be hard harder to reverse
decision. So for example, if I extract a service, Don't get me started on microservices. All right but anyway, it's going to be more work than that. There isn't in my IDE, there is no race track microservice in line microservice. Doesn't exist. Just yet. I wouldn't put it past you guys to go and figure that one out and I hope you do. But most decisions about structure are easily reversible. The wishing tree behavioral decisions completely differently than we treat. Structural decision. I have an experiment for you if
you wanted to try to apply this. First be very careful. I'm going to assume that you do this supposed to request blocking asynchronous review stuff, which is again, don't get me started. But assuming that you work in that style, Each pull request contains either Behavior changes or structure changes but never both. That's the first one. then the the second part of this, as you clearly labeled, which of those you're operating under And then pay attention to the results of review of structure, changes and behavior changes.
And I would go so far as to say once you're once you're comfortable, with making this strong division between structure changes in Behavior changes, the structure changes can be fast-tracked as long as they pass all the tests, And the way it goes, you don't really need more review than that because if somebody doesn't like it, oh, that violates our lairs blah blah, blah, okay, go fix it or I'll go fix it either way is fine. So make the strong distinction between Behavior
behavioral PR's and structural piers and then see how you can apply. Your review process differently, depending on which of those you're dealing with, sometimes you'll need to just go and get them program and behavior changes in structure changes. Everything is all of them together, then if you're performing this experiment you need to go back to you. Take that big bunch of changes and you reverse engineer, you say okay, well I can make change this about the structure in this about the
structure. And then I change that about the behavior. And then I change this about the pop up up, up, up, up, up, and away, you go. And in the end you have a sequence of really small, their Each of which does a prepares to either prepares for for changing big or actually change his behavior. so, one of my most Popular. My most widely viewed tweets I guess I don't popular. You like more of value judgement by measurement. Said don't make hard changes first, make the change easy warning, this may be hard, then make the
easy change. So this being Ruby land. Turn that into a almost pronounceable acronym. Make it matte. Nick at Matt, make the change easy to make easy change. So this is a, this is a style of development that choice for how you approach development. That says, when I'm faced with a change, that's going to be hard. Rather than just so I'm going to do this. What could you do? That would make that change easier. How could you invest in the structure so that the change would actually be able to
once we baba baba, baba, baba, baba baba then this is a one-liner. Okay. Sometimes what you want to do before you make that baby change is which would be hardest to make it easy. So, make it Mac says, rather than doing hard things, make a hard things. Easy, something about this seems to Great on a certain class of programmers. Now I grew up as a programmer. My dad was a programmer grew up in Silicon Valley the whole thing so I know I've known programmers, literally my whole life. And some of them seem to have a masochistic streak
to them. A streak that says, you know, yet I'm going to go in and I'm in a through the power of my magical brain. I'm going to change 5012 things in all at once and then the first time I run, it is all going to run and fantastic. And and there seems to be a kind of a power Rush that comes of making that kind of a magical, huge change and a huge psychic payoff. The one time in your career when it actually works, maybe like every 10 years, you get one of those
that actually works. And there also seems to be some kind of psychic blinders about the many many, many, many, many, many times when you try that trick and it doesn't work. And it's a gigantic mess and it turns out that it's 10 times harder than you thought it was, or it would have been easier. But because of the way you did it, it turned out to be much much harder. And Dad just doesn't phase this class of programmers, and I don't understand that. I think it helps that I was never a big
complexity person. I could never take a huge problem and put it all into my brain and and fix it also from very early on in, in my programming career, I had to make things simpler, not out of some. I mean, it's just, it's just A survival mechanism. For me, I just couldn't make behavioral changes if I didn't make the structural changes first, it's just wasn't an option for me and my good friend. Kevin Ryan, he's still out there programming and doing wonderful work on on games. He was it exact
opposite, he could just take enormous amounts of complexity, put it into his head and somehow managed to manage that whole thing and get stuff that would work. So, incredible machine is one of his. His, you could do that, I couldn't do that. So, I was forced into this tiny first and then, once once you're in the world of making, structural changes, refactoring comes is very natural consequence cuz you don't want to break things and you want to work in small pieces and you want to be able to abandon structural changes halfway
through, if you learn something, your priorities changed without having lost all of the Investments, That you make. No, this does presumed. I was hoping I'd have a chance to talk about this. A little bit of a finger wag. So prepare yourself this presumes that making a single changes, quick and cheap And another one of these wheels that's turned is when I started out in programming, you submitted Deca Punch Cards and then hours or days later you get a stack of Greece, right paper. That's the output of it. Many, many, very smart. Very wise people work
extremely hard so that you could just change something and see it. So this is the certainly, the small taquitos. It's been the Ruby ethos from very early and we would always thumb our noses at the C plus plus people with their 48-hour bills like yeah. Yeah, yeah. You guys, you know, if a change takes 48 hours to validate, you have to make big changes. You have to make big changes and we had gotten onto this new style of programming where we could just make change. I could make changes in
a minute and it's just fine. I can get feedback from each of those changes. Test-driven development cook that substrate that you can make changes and get feedback quickly and and Amplified it by giving you better feedback on more of the system in in those short periods of time. Somehow we have lost the plot in software tools. I'm now seeing Bill times that take 10 minutes or an hour or multiple hours and no shorter path to any decent feedback, then running the entire Bill and its I don't understand it. It's
like we're back to punched cards. And again, this is maybe a little masochism, or a little gatekeeping. Like, so if you're not smart enough to program like this, then you're not smart enough to program. And I think it's, I think it's horrible. And I did the measure that I wished that we could adopt for a programming tools is latency instead of throughput. How quickly can I get feedback? And if somebody comes along and says, oh, a tool chain, this and blah blah, blah that. And here's this thing, and only adds 12 minutes to the tool chain, which is always already an hour and a
half long old, who cares? No, I think that's not okay. I think that I would much rather have less feedback in a second. So that my love thought wasn't interrupted and I could get back to work. If you're working on software tools and every programmer should, at least, think about working on software tools cuz they affect you all the time. Think about the latency of the feedback that's provided so the end of end of finger wag, but yeah. So let's take this idea and crank it up to 11. I don't have very many tricks, you know. So let's crank this style
of development up to 11 and see what happens. Again, I'm short of time to tell you about all of this but I've another experiment for you which is easy to do and it's an alternative to test-driven development. Always said I wasn't going to do pool but I would love to do a poll and find out how many people use test-driven development on a daily basis. Speaking to the meeting God's. If that happened I would be happy. Thank you. So Tdd encourages you to work in small cycle, but could it be better? I'm giving a code camp in
Norway at 8 or 8 and I told my the, the participants about this workflow, that I had where I would run my tests. And if they passed, I would make a little get commit. And that meant that any time I got into that state where you like it's broken and I didn't change anything. You always change something, you always change something. How can I get back to Nam? Good State, there was always a commit for that. You could always go back to it and I'd munched on one of the, the participant said, well by symmetry,
which is another one of my tricks and I didn't think of it this time so I'm like a little bit messed but you go by symmetry. If you commit, when the test pass, shouldn't you revert, when the test fail, So here's how that works. You program program program, you say save automatically the tester run if they fail the last commit which was the last time, the tests all past / definition just gets gets pulled in. So I write 10 lines of code that I'm sure works and I pressed save and it pooped just disappears. And I might but
I can't because I know that works. So I'm going to type it in again. So I typed it in again, it disappears again. And now I'm thinking. So now I better think about what's actually going wrong. So is there a way for me to type two lines of code? That will be consistent with the current test. And then that'll make a commit and then at least those two lines aren't going to get pooped on me. Okay. So, and that's the, that's the magic moment. When you think here's this single chunk of code that I can't make it this year, reducible smaller, and I make it even smaller than
that. As soon as I started using tcrn kind of bored with tdd, it's like, I know the moves. Yes, you can apply it and different domains, but the workflow itself was like old hat TCR, let me back up again. Like, oh, this is impossible. These five lines don't work. And it's impossible to figure out how to introduce them one at a time, maybe not. And so TCR is is an incentive system that incentivizes you to make changes smaller and smaller. And this is easy easy
to to experiment with. I have a A YouTube video of like an hour of me or hour and a half of me doing TC are on a day to structure, the Rope data structure and there's a video in there about setting up your system so that the DS code in particular so that teach car happens to you automatically. This is another one of these. This is easily reversible. You can try this out, it won't ruin your life. It's not like I don't know. Some drug that you take that
eliminates your ability to have joy. You try, this doesn't work, it's fine. But if it does work for you, the the there's, For me, part of the payoff of tdd is a reduction and anxiety is like, oh, does this work? Well, I just run the test. I'm going to go, run the test three, four times before I feel relaxed enough to move forward TCR, is that squared because every single little change that you made has been validated. And I have a blast with it. I recommend that you try
it. and that's What I have prepared for you, I will be on slack. If you have questions about what we talked about the Royal we have talked about, you have questions about what I talked about how to apply it or how does it come in to Ruby, please let me know. Be glad to discuss it and one more banjo tune. Alright, let me say this is been one of the most fun I've ever experienced in my life. I'm mostly because it started in that bed with a banjo. So massive appreciation and thank you. You huge huge thanks. Like he said, head over to the slack Channel, follow up with them there. If you have
any questions otherwise have a wonderful and fantastic dive into day three. Everybody make sure to find your tribe in any of the slack channels that speaking resonate to you. And of course, if you have any questions, will see you on slack. Thank you again. Can't much appreciated. My friend, my pleasure.
Buy this talk
Buy this video
With ConferenceCast.tv, you get access to our library of the world's best conference talks.