00:00:07.520
Oh my gosh, good morrow friends! Here we are, and it is already 11 Central. We are into the last day, the closing third of this marathon known as RubyConf. It is my pleasure to welcome you to Day 3. As you all are very well aware, the community on Slack has been super vibrant, and I hope you've had the opportunity to participate in as much of that as possible. I have heard rumors, mostly seen pictures, that folks did karaoke last night on Zoom, which must have been quite an experience. Regardless, I am seeing so many fun activities happening, so a massive applause to all of you for keeping this community alive and vibrant! I truly appreciate it personally, and I know that all of us first-timers appreciate it too.
00:01:09.840
So, let's kick this day off! I want to bring to the stage Marty, one of the organizers here at Ruby Central, to introduce our keynote for the day. Howdy, Marty!
00:01:31.520
Hello, good morning! How are you all doing? RubyConf is doing alright! Normally, I'd be able to hear you shout back from the audience, but we’re virtual, so that's not going to happen. I sorely miss seeing everyone in person! I am a director at Ruby Central, and you've often seen me on stage before. However, so far at this conference, I’ve been behind the scenes doing stuff in Crowdcast, but this morning I get to introduce our next keynote speaker. Now for some of you, he needs no introduction—you are likely familiar with his work. But I suspect there are a good number of people in our audience who are not familiar with Kent Beck. I suspect that you have encountered some of the ideas he’s championed over the years.
00:02:11.760
Personally, Kent’s work has had a major impact on how I approach and write software. I remember distinctly back in 2004 when I joined a small software team that was going to practice extreme programming (XP). I then had to introduce his books, and it changed everything. Some of these ideas you’re probably familiar with are test-driven development, unit testing, refactoring, thinking in patterns, pair programming, and other agile practices. It's wild to think that back then, it was fairly rare for these practices to be done on teams. I remember having to advocate for implementing some of these practices, but now they are fairly commonplace.
00:03:13.120
Kent is no stranger to our conferences; he’s spoken here before, the last time being in 2015 at RailsConf in Atlanta. He has come back to share his insights with us today. So, without further ado, please welcome Kent Beck to our virtual stage!
00:04:22.639
So, I would start every Zoom meeting with a couple of minutes of music, playing the banjo or guitar. I’d show up early, and then I noticed that other people started showing up early just to catch some music. They loved it and gave me so much positive feedback that I wanted to practice more because I wanted to get better. Thus, your second lesson is: It’s not about ironclad willpower; it’s about human connection.
00:05:09.360
Now, I do have other messages besides that, which would probably be plenty. I have a message and it is a general principle: reversibility, as applied to software development. I’ll make another meta comment: If you haven’t seen me talk before... and, by the way, this is my first RubyConf talk, so I’m that first-timer that Adam mentioned. If you want to come up with ideas—come up with combinations of ideas. It’s really hard to think up a new idea from scratch, but it’s easier to take two ideas that nobody has ever put together before and combine them to produce something interesting.
00:06:17.759
I’ll use the example of reversibility as a general principle, specifically applied to team software development. So we’re going to take those two things together and see what comes out the other side.
00:06:30.560
I’ve had some questions about my presentation software. I have a Canson XL 160 gram sketchbook for any of you penheads out there; it’s beautiful paper, and I highly recommend it. I also have Winsor Newton brush markers, which are again highly recommended. That’s the software I’ll be using today—maybe we’ll have a giveaway if any of these slides turn out cool; that would be fun!
00:07:31.520
Now, the first idea is reversibility, and what are we talking about here? I recently debuted a workshop with Jessica Kerr called "Invitation to Systems Thinking." As the wheel turns, we’ve moved from a very reductionist approach to software development to a very holistic one, and now we’re back to a reductionist approach: what are the numbers? We’re going to make the numbers go up, and then everything will be better. Whenever the wheel turns in that direction, the antidote is systems thinking. Jessica's motto is: "Relationality over rationality." In any complicated system, you don’t have control, but you’re not helpless.
00:08:17.280
There are many pieces in your system, and it’s their relationships that really make it challenging. 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 to systemsthinking.dev for information if you’re interested in this workshop; it’s a lot of fun. We just did the first one a couple of weeks ago, and we’re going to do another one in January.
00:09:03.680
In 2001, at an early extreme programming conference, we had a presentation by Professor Zaninoto, who was the Dean of the School of Economics at the University of Trento. He said this extreme programming stuff... now keep in mind this was a time when extreme programming was wild and crazy and seemed like it could never possibly work. He said from an economist's perspective, extreme programming makes perfect sense, and here’s how it makes sense. He gave a fantastic presentation with some of the clearest thinking that I’ve ever heard. It still took me about 15 years to figure out what he was talking about, but let me summarize for you, as you’ll pick up on this quicker than I did.
00:10:05.440
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? You might have a giant factory, and one seemingly little thing can go wrong and the whole factory shuts down, or you take away an element in the factory and suddenly everything works more smoothly. This is the over-rationality part; you can’t simply figure out by looking at all the pieces in the system what's going on. The professor said there’s a reason for that: large complicated systems have many, many states.
00:11:02.879
You might think, "Oh, the system is in this state, so if I do this thing, the same thing’s going to happen as last time it was in that state." But there are too many states to be able to say that with certainty. I remember the first time I pushed code at Facebook, the message that came back was: "Your code was successfully pushed to 6300 out of 6400 servers." I panicked—"Oh no, what’s on those other servers?" People said, "Who knows? It’s 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 changed the inputs.
00:12:00.800
Another problem here is interconnection: the pieces in the system don’t stand alone. Any piece could alter any other piece. For example, at Gusto, where I work doing small business payroll and benefits, if you look at Gusto itself as a system and how we deliver service, you could say that this many customers call in with this kind of problem, and it takes a person this many hours to resolve it. So retroactive address changes might cost us 14 cents per customer per year.
00:13:06.560
We can break down the costs of serving our customers and determine the benefits associated with payroll. However, those aren’t leaves on a tree; all of these seemingly detached components are potentially connected to each other. For example, I can reduce costs in one area by 10 cents, but that could accidentally cause another cost to increase from 40 cents to two dollars. If I’m not carefully monitoring what I’m doing, those interconnections will make it impossible for me to control this system.
00:14:07.840
This sense of interconnection means we aren’t merely dealing with independent fragments. We are working with interconnected systems. In software development, we talk about coupling as a measure of that interconnection between elements in a software design. A third source of difficulty is variation. The reason we can’t control this system is because things change—both the external world and the internal world will change. Sometimes wear in a mechanical system will cause small differences, which indeed can lead to significant consequences.
00:15:06.479
The last element that makes systems difficult to control is irreversibility. Once we make a decision, we can’t unmake it, and irreversibility is all around us. I recently decided to downsize my possessions, and I have all these boxes of books I’ve collected over decades—about 50 boxes! They are stored away, but I hesitate to get rid of them due to my attachment. If I simply discard the boxes, that would be an irreversible decision; I wouldn’t be able to get them back or even recall what they were.
00:15:51.760
I thought, I’ll scan all of my books into Goodreads, and if I want to read them again, I could always get electronic copies through Kindle. That’s an example of turning an irreversible decision into a reversible one. I also thought about my journals. Every morning, I write two pages of free association—it could be trivial stuff, plans for the day, or deep thoughts. I have a shelf full of these journals and thought maybe I should get rid of them too, as it felt good to reduce my possessions.
00:16:53.760
But I realized that getting rid of my journals is an irreversible decision. While I could make the book decision reversible using Goodreads and Kindle, the journal decision would not be as simple. This illustrates the principle of distinguishing between reversible and irreversible decisions; it’s crucial in complicated systems. If a corporate decision goes awry, you cannot simply retract it. This notion is central to our understanding of reversibility in complex systems.
00:17:37.760
Back to Professor Zaninoto: He pointed out these four factors that make operating complicated systems so difficult, and he concluded that extreme programming makes perfect sense as a way of addressing this kind of complication in software development. It takes many decisions that previously were irreversible and makes them reversible.
00:18:15.440
For example, if you plan every day, and something changes—that means that yesterday's plan was not optimal—you only lost a day and can reorganize priorities. Compare that to the traditional waterfall model, which was criticized because people would set rigid timelines and scopes. If one aspect were discovered to be incorrect, it was challenging to change because commitments were made about deliverables.
00:19:03.440
In the XP planning style, we can adapt our plans week to week. The identification of mistakes can happen naturally because discovering mistakes is imperative. This malleability is the hallmark of extreme programming. It allows teams to adapt to the continuously shifting requirements inherent in development projects.
00:19:55.440
Now, as I attempt to apply these principles in my life, it becomes evident that irreversible decisions exist beyond the scope of software development. For example, you can’t take back something dumb that you said in a relationship. I’ve had my share of dumb moments, but it’s not always possible to revert those decisions. There are, however, situations in which irreversible decisions can transition into reversible ones, which forms the power of this style of thinking about complicated systems.
00:20:39.839
I’d even noticed the idiom "that ship has sailed" to describe an irreversible decision, indicating that our language has these metaphors for expressing the concept of reversibility. So, that’s the first principle: in complicated systems, we can’t control them due to their vast states, interconnections, variation, and irreversible decisions.
00:21:29.760
Henry Ford, for example, in his Model T plant, chose to reduce the number of variables as a means of controlling the system. He famously said that you could have a car in any color you wanted, as long as it was black. This was not due to a preference for black but because simplifying the manufacturing process allowed for a more efficient workflow. By minimizing complexity, he was able to manage a big complicated factory in a manner that had previously never been done.
00:22:17.839
Now, having discussed the principle of reversibility, I want to touch on some of my more recent research on software design. I’ve been designing software for a long time and feel confident in my capabilities. However, I've started to delve into the boundaries of software design and have realized that there’s a lot still to learn.
00:22:43.280
I began working on a book called "Tidy First," and there’s a basic loop in software development. You start with an idea; ideally, the software should perform specific functions, x, y, and z. This starts a chain reaction where the behavior of the system must be adjusted.
00:23:12.000
From that idea, you identify a need for a button that serves the purpose of executing x, y, and z. Once you implement this button, the behavior is changed, which leads to an evaluation of whether the change was effective; do people like it? During this process, the understanding often differs between programmers and non-programmers. Programmers comprehend that behavior adjustments can be less or more complex, depending on the design of the software being modified.
00:24:23.720
The primary intent behind designing software is to make change easier. If we never needed to change the software, then variables could simply be global, and we wouldn’t require subroutines. The reason we break down software systems into components is to facilitate change. This change relies fundamentally on the overall structure of the system, and external changes can occasionally prompt a redesign.
00:25:18.760
Sometimes, a change of behavior must be made in a less clean way due to unexpected complexities, prompting the need for a redux of the structure, ultimately making future modifications simpler. For instance, I might end up modifying five lines of code that are impossible to understand in totality and have to consider introducing the elements piece by piece until a functioning change emerges.
00:26:38.560
As I started working with TCR, it added unexpected excitement to the workflow. The realization that I could commit smaller adjustments made it easier to maintain control over changes and improvements. I'd pass through various configurations as I fine-tuned the aspects working from both the behavioral and structural perspectives.
00:27:48.400
Once I started utilizing this approach, I found it easier to navigate the complexities of software development by breaking actions down and paying closer attention to the sequences of changes I had made. Each time I worked to shift the system or its behavior, I could rely on well-defined commitments made all at once.
00:28:35.600
I recommend exploring TCR, which typically involves committing when tests pass, and if tests fail, reverting back to the last commit. This practice serves as an impetus toward simplifying changes while enhancing performance. When errors occur, reverting pins down the point of success, dramatically stabilizing one’s flow—and that’s immensely helpful.
00:29:42.240
The quickest and easiest manner of implementing change rests upon structured designs; each individual change should be reconsidered based on interdependence while also maintaining catalogue-like traceability of events. While I explore these concepts, I have discovered value in shedding light on the symmetries present in software development.
00:30:35.040
Now, in the roles we take in software, we often encounter real-life applications that highlight how skills come into play through shared learning. Sometimes it takes just small transitions in practice to ignite authenticity and consumer-driven demand. Software development is a convoluted and interwoven tapestry of efforts, but when segmented, significant insights can emerge.
00:31:25.760
I’d like to recommend that if you engage with these principles and considerations, utilize them to showcase where software limitations can be addressed. Each software path often intertwines, but the real development and optimization come when we take a little bit of time and attention into resetting our assurances, shaping them together as kinds of memorials to collective efforts and brotherhood in this craft. And competing against this industry’s norms, we become more versatile in realizing what approaches we need to take.
00:32:22.640
Once again, I appreciate everyone for being a part of this conversation. It’s always rewarding to witness varying perspectives pursuing their archetypes; this is just one way of innovating in a beautiful industry. Moreover, I’ll be on Slack if you’d like to follow up with questions regarding all of this.
00:33:16.080
I want to integrate a song to conclude with; fundamentally, music aligns with the power of collaboration we’ve been discussing today. The harmonies we create emerge from the immense avenues we forge in communities, and I could not be more grateful for this wonderful crowd of RubyCon enthusiasts.
