Introduction & Background

Sarah Taraporewalla: Welcome to GOTO Book Club. My name is Sarah Taraporewalla, and I’ll be the host for today’s book review. I’m the CTO for ThoughtWorks APAC, but today I’m joined here by Dave Thomas, otherwise known as Prag Dave Thomas and the co-founder, co-author of The Pragmatic Programmer, and now the author of a new book titled Simplicity.

Dave Thomas, thanks for being here.

Dave Thomas: Hey, my pleasure. It’s nice to chat. So, I have to say, it’s pragmatic, pragmatic, pragmatic.

Sarah Taraporewalla: Well, Dave Thomas, for our listeners, you’re a British-born programmer, publisher, educator. You wrote the classic Pragmatic Programmer, founded the Pragmatic Bookshelf with many books in print. You signed the original Agile Manifesto, and along the way coined ideas that we use today, like DRY - don’t repeat yourself - and code kata. You helped popularize languages like Ruby and Elixir. Today, for most people, the name Dave Thomas already means procedure. Some of us learned the craft of programming through your books and through your work. Others have heard of you from the principles that you’ve developed in the manifesto and some of the other concepts like DRY and code kata.

But for those meeting you for the first time today, how do you introduce yourself these days?

Dave Thomas: Pretty much the same way I’ve always done. First of all, that was a very sweet introduction. I’m not sure I recognize myself from it. My fundamental introduction is Dave Thomas Thomas, I’m a programmer. And to me, that kind of sums it up. But to be a programmer, you have to do a lot of other things as well.

When I say that, it’s kind of a shorthand for who I am really - I’ve been programming for 50 years, and I still code pretty much every day. And I still learn new things every day. That’s why I love it. I love just being in an industry, a profession where it is constantly a challenge to understand what’s going on and actually make it do something. For me, I start each day wondering, “How can I do something today? What can I do?” And that’s just fantastic.

Along the way, I’ve been lucky enough to get involved with some projects where I can share some of the stuff I’ve learned. Most of the stuff I’ve learned has been questions, but share some of that stuff. And that’s one of those positive feedback things. Because once you start doing that, then people start asking you even more questions and you get deeper and deeper. And I love that. Absolutely love it.

Why is 2025 the Year for Simplicity?

Sarah Taraporewalla: That brings you to your latest book that you’re putting out with the title of Simplicity. That title itself just feels timeless. So why is 2025 the moment to write this book?

Dave Thomas: Actually, 2020 was the moment to write this book for me. Since about 2015, I have been really upset with the state of what people call agile. I was very proud of the manifesto that we created, particularly because the real essence of the manifesto was just the four values on that first page. All the rest of it was just filler, really. And those four values, I think, are still as valid today as they were back then.

But a value is simply a filter. It’s a mechanism by which you can say, “I need to make a decision - which would be better, which would work for me better.” And that’s what a value does. What’s happened is that that’s uncomfortable because it means you’ve got to be constantly thinking. So people have taken various practices and bundled them up into this thing called agile. We are kind of getting back to the situation that we were in in the 1990s, where companies have big processes and developers are basically cogs in a machine.

And that’s exactly what we were fighting against when we sat down in Snowbird to craft a manifesto. In 2015, I gave a talk called “Agile is Dead,” which is actually probably my most watched talk. I have the distinction of having Jeff Sutherland walk out on it. But it really encapsulated the way I was feeling at the time and still do - that we’ve taken something which was never meant to be a prescription. It was always meant to be a way of thinking about coding and developing value. And we’ve taken that and we’ve converted it into something you buy off the shelf. You spend your $2 million, you implement SAFe and there you are - “We’re agile.” Tick that box. But of course, we’re not. And that’s just not working.

So I’ve always wanted to come and try and work out what post-agile means. I’ve been working on that on and off for years. I came to the conclusion there is no such thing, because the failure of agile was kind of built into it from the start. It really doesn’t work unless the entire environment goes along with it. It’s very hard to be a team using agile practices if your organization is doing reports every month. That impedance mismatch has caused pretty much all of the problems I see with agility.

I came to the conclusion that there was nothing I could say to developers that was going to help them overcome the problems with the way agile has been implemented. So I started looking around for, “What can I do for developers? What can developers do on their own that doesn’t require management buy-in, doesn’t require a budget?”

I started writing a book about that. It went through three iterations. It was a tough thing to do. The first ones were not called Simplicity. They were to do with agility. The first one was actually called “lowercase a agility.” Gradually it occurred to me that we’re not really talking about agility. Agility is part of it, but the real essence of it is trying to get back to a more understandable, scoped way of doing things.

Because we as developers, we have this really nasty habit of enjoying all the bright, sparkly things and trying to drag them into our projects whenever we do something. As a result, our projects get more and more complicated over time. At the same time, our customers come to expect all the bright, shiny widget things that we can put into our user interfaces. So we built this burden that we’re going to be carrying around with us. It never gets less. We get more and more. As it does, work becomes more and more sluggish, less and less agile. I thought we could do something about that. That is something that we as individual developers can control. And so that’s what I’m trying to explore.

Understanding True Simplicity

Sarah Taraporewalla: I really like breaking it down. I’ve been obsessing over the fact that simple isn’t easy. Simple is actually quite difficult to do. Then we’ve got the work from Dave Snowden around the Cynefin framework where we talk about complex and complicated work and simple. How does simple and this idea of simplicity fit in with what does complicated mean and complex? How do we know something is simple without being simplistic?

Dave Thomas: That’s a really good question. And it was the one I struggled with. I think that the first thing is when you say simplicity is not easy - true simplicity requires mastery of something. Because if you look at the stuff done by beginners in absolutely any topic, any subject, and what you’ll see is things where they have bolted stuff together. They know about this, they know about that, they know about something else, and they throw it all into a bag and push hard. You’ve got something that’s been created.

Whereas somebody who has control of that discipline can approach it in a very different way. They will say, “This is what this final result is going to look like. I’m going to craft just that.” And what they end up with is something which is relatively minimal, which works, which looks good at a UI level, but at like a design or implementation or whatever level. And it just feels right.

So you cannot just say, “I want to write something with simplicity.” It’s a question of acquiring simplicity. For me, that was the big realization - that you can’t tell people how to create simplicity. All you can do is show them how to teach themselves to have simplicity.

It’s a bit like looking at great painters. Some of them, particularly the older ones, did awfully detailed stuff, but with many it’s big, bold brushstrokes and lines that anyone can draw, but only they can actually create. And it’s that mastery is what we’re looking for.

The Orient-Step-Learn Framework

Sarah Taraporewalla: In the book, you’ve got a really nice framework that you use to talk about - the Orient, Step, and Learn sort of process that we can follow or guidance that we can use every day to help us achieve that mastery. Can you, for our audience, explain that? What does it mean and how might one use it just on any ordinary Tuesday?

Dave Thomas: Sure. There’s two aspects to it. First of all, what does it actually mean to do it, and then the second is why do it. What it means to do it is to simply say, don’t just launch off and do something. Fundamentally, before you start something, you need to know where you are now, where you want to be when you’ve finished, and how to know that you’ve finished. Once you’ve finished, then you’ve got to look back and say, “How did that go? What did I learn?”

This is nothing new. This is the essence of agility. Fundamentally, it’s planning for and using feedback as you go forward. As with things going back to XP, the trick is to make each of those steps as small as you possibly can, because you want to anticipate that you’ll make mistakes and you want those mistakes to be cheap. If you squander five minutes on some wild idea, who cares? If you squander five days, maybe you do.

So we’re going to have this kind of Orient-Step-Learn process going on recursively. So it takes place at the very smallest level, but also at the biggest level - the project level or bigger than that. And the trick is going to be remembering to do it. That’s one of the habits that we have to teach people.

But there’s a second reason to do it. It was really interesting when I came to this realization. What I’m trying to do here is to help people develop intuition or that sense of “this is right, that’s wrong.” It’s like you can look at something and say, “That’s elegant,” but you don’t necessarily know why it’s elegant or you wouldn’t necessarily know how to do it for yourself. But you can look at what someone else has done and go, “Oh wow, that’s really beautiful. That’s really well done.”

Well, the person who did that didn’t just do it from scratch. They have been doing that for years and years and years and learning as they go along what they’ve been doing right. They’ve been giving themselves feedback. And all intuition is, is the accumulated experience that you’ve forgotten you have. It’s all of those little patterns that have gone into your subconscious that trigger in certain events.

In the same way that if you were out in the plains of Africa and you see movement in the grass, you don’t actually have to be conscious of it to go, “Stop, run away.” It’s the same thing. What you’re doing here is you’re building that kind of code sense. I’m sure every developer has it to some extent. Everybody can finish running some code and they get this kind of “something’s not right” feeling.

One of the favorite things I do in talks is I’ll say to the audience, “How many of you have been working on a problem, and all day there’s been this bug?” I draw it out into a big, long, shaggy dog story. But basically, you spent an entire day chasing this bug, you go home, you’re miserable to be with because this bug is still bugging you. You finally get to sleep, and then the next morning you wake up and you know what the bug was. How many have that happened to? The entire audience always puts their hands up.

So I say, “You can’t tell me there is no intuition in programming, because your sleeping brain solved a problem that you spent all day trying to solve.” So what we’re trying to do is to build that intuition, build that sense of what’s nice, what’s not nice. And the only way to build intuition is to give yourself feedback.

The Orient-Step-Learn loop deliberately asks you to give yourself feedback on everything you do and not just in terms of looking at it and going “oh yeah, it’s okay,” but actually doing something like writing it down. Because the more modalities that you have to your feedback, the more channels you’ve got of information coming into your brain, and the bigger the pattern is that you’re matching.

I find that to be invaluable. If I’m on my own and I’m feeling safe, I actually do it out loud and speak to myself because that way I’m using even more channels. By doing that, you’ll find that you start to build an intuition.

So there was an experiment I did 4 or 5 years ago. I really do not like Sudoku, but I thought, “This will be an interesting challenge.” So I started playing it and I played it for maybe a week relatively intensely. Then I said, “Now I’m going to stop trying to be logical, and I’m just going to put numbers in.”

It blew me away. I wasn’t some kind of savant. I couldn’t do the whole thing. But when I got to the thing where I was 100% stuck, I would just take a guess and I was right more often than I was wrong. That’s what we’re trying to do. We’re trying to build that kind of intuition. And you can do it by giving yourself feedback.

Sarah Taraporewalla: What I think is interesting about that, as you said at the start, it’s the mastery of the skill of being simple. So I think as you master that as a skill, your first attempt at doing anything isn’t that simple. But you can stop, you can orient, you can think about it, maybe have another go. But as you master that, the scope of what you do the first time where it comes out simple, that scope starts to grow as well, to the point where other people just think it looks easy because you’ve actually got that intuition.

I had a great conversation with somebody many years ago who was teaching me TDD, and they said, “I feel like I can write good TDD-looking code without writing tests first, because I’ve got that intuition.” What does the code look like? They still did TDD because they got the value from that. I think that is a really fascinating thought where you can apply that Orient-Step-Learn on a very small scale, but also on that macro level and continue to do it as an individual, but also as a team.

Dave Thomas: The testing is actually a good example because the more you get into doing testing, the better your instincts are. I have this pretty strong belief that the major benefit of doing tests - I don’t like test-driven development, particularly, but I do like testing - and I think the benefit of testing is that you get to think about the design of your code, because if you don’t design it properly, it’s really hard to test.

Over the years, I’ve come to realize that by thinking about testing, I produce less coupled code, more modular code, etc. Then I thought, “It’s become kind of like a habit. It’s become a mantra that you do testing.” I do a lot of work in the Ruby community, and the Ruby community is kind of rabid about testing. I always get nervous whenever I’m in a state where I feel like I’m an acolyte of something. I have to do it because that’s what everybody does.

So I decided to stop testing for a while and see what happened. I think that is actually part of the Orient-Step-Learn. That’s actually one of the harder things to do. You don’t just want to get feedback on what you’ve done, but you want to get feedback on what happens when you don’t do it. You might believe that lining up all your code and making it look pretty is really good. And I personally do. But that’s only an opinion. And what you have to do is to test that opinion. The only way I know to test it is to stop doing it and see what happens.

In the same way that one of the trick questions I always ask agile teams is, “Are you doing the same stuff now that you were doing a year ago?” Because if they are, they’re not agile by definition. You’ve got to stop doing things. And that’s one of the key benefits that you get from aiming for simplicity - because to make things simpler you cut things away. And so you have to know: is what I’m cutting away doing me harm or good? And that’s where the feedback comes in.

Sarah Taraporewalla: I have learned that lesson many times over with testing. In my professional life, all the tests are there. It’s beautiful, wonderful code, and test-driven development. My home hobby projects which I come back to every so often, I have a very small smattering of tests. It’s only me, it doesn’t really matter. And every time I come back to it, I think, “Why haven’t I got any tests in here? I’m making it so much harder to get up and get moving.”

I love that thought about not only why we are doing it, but what happens when we don’t do it? Some of the book is written for developers and for insights that developers can take away. But how does simplicity continue or how does it diverge from the stuff that you’ve put down in Pragmatic Programmer 25 years ago? Is it a continuation of it?

Dave Thomas: Can I get away with saying it is consistent with it? I wouldn’t call it a continuation. But like the Pragmatic Programmer, it is largely things that individuals can do. This is not big, sweeping, grand organizational strategies. This is, in the same way Pragmatic Programmer is very much about how an individual can approach the act of programming.

This is the same kind of thing. It’s just more focused on one particular aspect of it. And that is this idea of trying to be elegant, trying to be minimal. So I would say it’s not a continuation, but it’s also not a contradiction. It doesn’t go against anything, I don’t think, in the Pragmatic Programming. It just focuses on - it’s almost like you took it and then rotated it 90 degrees and looked at things just a slightly different way.

Organizational Impact & Limitations

Sarah Taraporewalla: If the book talks to development teams, what about companies and organizations? How can the organization make sense of the lessons that we’ve got from simplicity?

Dave Thomas: Do you want the optimistic answer or the cynical answer? I think that the problems, as I said earlier, the problems with agility were that organizations in general are not that agile. Many are, but in general, not so much. There’s Jessica Kerr who gave a really great talk I went to a couple of years back where she described large organizations as being “self-healing bureaucracies.” Whenever you inject a change in, then the compensation structure and the hierarchies inside an organization fight that change, even though they may outwardly say, “Oh, that’s a really good idea.” Inwardly, it’s still, “How am I going to get my reward at the end of the year?”

I don’t know if you are going to get large companies or even smaller companies to make that kind of shift in their mindset. I haven’t seen very much evidence of it, because even if the company shifts, you’ve also got to get the customer to shift. So we’re talking about changing the entire world, which is a little bit ambitious.

So will a company change? I don’t know, I don’t think so. But that’s why I wanted to write Simplicity as a book for the individual, where you can still get the benefit and you can still improve your life, even if your company is still stuck in the stone age.

Now, will companies benefit? Of course they will, I think, because if what you produce is simpler and still meets the need, still delivers value, then you’re obviously ahead of the game. So I would love to see some kind of adoption at a higher level and maybe that will happen. The trouble is that developers typically don’t end up being CEOs or CTOs. So it would be really nice if developers who discovered simplicity would then move on up the organization and kind of spread the word. I don’t know what’s going to happen.

I think the manifesto was very optimistic and had a very blue sky and was very idealistic. And I think the last 20 years have shown us that that was naive. And I think we should - that’s why I’ve kind of limited my scope this time around.

Practical Steps to Get Started

Sarah Taraporewalla: If someone reads the book tonight and wants to start putting some things in practice tomorrow, what are the 1 or 2 things that will give them the biggest simplicity ROI, if you will, right away? What are a couple of things that you think they should start doing straight away?

Dave Thomas: First thing is to disabuse yourself of the notion that there is an immediate ROI. You’re not going to get that. What you’re going to get is a slowly growing sense of mastery.

So in terms of the actual mechanics of it, the first thing I would recommend anybody do - or not the very first thing - the very first thing is to decide they actually want to do it. This is not a question of “I am going to change this thing that I do because the book says to.” That won’t work. It has to be a decision that, “Yeah, I want to think about things differently, and I want to prioritize what I do a little bit differently.”

Once you’ve made that commitment, then what you’re really committing to is a process of gathering feedback on yourself and using that to change what you do. This is going to sound really prosaic, but I think the best way to do that is to go out and buy yourself an engineering daybook, which is simply - this is the one I’m maintaining now - it’s just blank pages, and I just write in it as I’m going along, and I then go back and have a look at what I’ve written to get feedback.

So I’ll say, “I’m going to go and...” - it could be anything. It could be I was on a call and someone mentioned something. I wrote that down. Or it could be I’m trying to chase something down. When I find it, I’ll write down where I found it. When I do that, I find that, first of all, the act of doing that actually helps cement it in my mind. But it also gives me a kind of external memory that I can go back to.

I don’t know how your subconscious works, but mine is really associative. So I go back in the daybook and I see something - typically that will then trigger 3 or 4 other things that I think about. So getting into the habit of using a daybook is actually a very easy way to start building that intuition.

Then I would say, look at the things that piss you off. What are you doing right now that you don’t want to be doing? Or what are the problems you’re having that you don’t think you should have? And ask yourself, “Why?” Typically the answer is “because that’s how we do it.” We’ve been using a particular set of practices because that’s the way the company does it.

So then you ask yourself, “What happens if I don’t or what happens when I modify it?” And if you’re smart about it, you can find stuff that you can just stop doing quietly and see what difference it makes. You can start looking initially at the things that kind of get in your way.

Do you find that if you leave a project and come back to it a month later, it’s really hard to pick it up because you’ve got 1001 dependencies there and you can’t remember quite what everything does? Well, maybe that’s the thing you should be addressing. How do I make that easier for myself? It could be something as simple as going back and looking in a daybook to find out how it works and what the build instructions are. Or it could be, “You know what? I’m not going to write projects with this many dependencies again.”

If you look at a brand new project - any project, pretty much - some kind of React project or a Ruby on Rails project, you end up with hundreds, if not thousands of dependencies without actually writing a line of code. You just install a basic project and you’ve got all of that. Well, every single one of those is a time bomb waiting to go off, waiting to sabotage your code. Every single one of them changes over time.

Just this morning I had code that worked eight months ago, and I tried to run it. It blew up because the latest version of some library that some other library that I was using used changed the way it handled something. Take a big enough project, you’ll never get it to run again. I don’t care if you’ve got all the best dependency management software in the world, it still won’t run.

So I think there are many things, as individuals, we can do just to cut through all of that kind of stuff, cut through the hype, cut through the idea that it’s good to use libraries. No it’s not. It’s good to do something in a minimal way - if that involves using a library, good. But the number of times I see code that drags in tens of thousands of lines of code so they can use a three-line function in the middle of it that they could have just written themselves.

That kind of thing needs to stop, and you have control of that. You as a developer can go, “That’s stupid. I’m not going to do that.” So the immediate hit depends on the person. What we’re doing is we are incrementally improving what we do and what counts as improvement is contextual. It’s always up to you.

Sarah Taraporewalla: And that dependency is something that you go into in the book, cutting down on the number of libraries and only pulling them in when needed. What’s one of the practices that you list in the book that sounds easy on paper, but actually has been, in your experience, one of the trickier ones to implement and start getting going?

Dave Thomas: Again, that’s contextual. For me, the chapter where I felt I was the most hypocritical was the chapter where I talked about the personal interactions and how to simplify the way you get on with people. And fundamentally it comes down to transparency and empathy. If you can master those - or not even master, if you can understand that they exist - then you will find things get a lot easier.

To be honest, my entire life I’ve been - I don’t know what the word is. My experience told me that I was right more often than I was wrong, and that gave me a kind of arrogance when I was talking to people. And it’s still lurking there. But I’m working on knocking that back down. And that’s to do with empathy. It’s to do with the fact that most disagreements are not zero sum.

It’s not a question of “I’m right or you’re right.” It’s a question of “We’re both probably half right, half wrong. Let’s find out which half and put them together and we’ll end up with a better solution.” So those are the areas that I personally found to be the trickiest to write about, because they were the trickiest for me to implement. And those are things I’m still working on.

Sarah Taraporewalla: I think we’re all working on some of them. I think it’s a lot easier to put in place some of the development techniques and practices than it is for those other core skills.

Dave Thomas: I think some reason people seem to think that work environments are different and they require a different set of interaction skills. To some extent I think that’s modeled by the organizational structure, where it’s typically fairly hierarchical and fairly top-down edits. But it’s not - it’s all pretty much the same. I think this idea of - fundamentally, again, it comes down to the golden rule, doesn’t it? Treat others the way you want to be treated and things get a lot easier.

There is a really good example of that where it’s imposed by structure - this idea of the meeting. There are some good meetings. A brainstorming session is a really great reason to have a meeting. Status reporting is the most stupid reason on the planet to have a meeting. You’ve got ten people who speak one at a time to a boss who’s only there because he feels he should have status reports, and it drives me insane.

The way that a daily scrum destroys productivity unnecessarily. All of these ideas of formalisms that structure how we talk to each other, they’re all adding impedance to what we do.

Sarah Taraporewalla: I will say that I learned much more about negotiating when I became a mum. Learning the art of letting go of the things that don’t matter. And when you need to actually lay the law down and how to negotiate with a two-year-old is a very important skill.

Dave Thomas: The nice thing about that, actually, is that your skill set has to evolve as they evolve. It has to evolve in the right way. You learn there comes a point when you’re no longer always right. And that’s a big lesson.

Sarah Taraporewalla: Well, I’m still on my journey. My kids are just about to hit teenage years, and I know that I’ll be very wrong in the next couple of years. I’ve got two boys.

Dave Thomas: I’ll be interested to see five years from now what your opinion of that is going to be like.

Sarah Taraporewalla: Well, for our listeners, one final question for you, Dave Thomas. What’s the one thing that you want the listeners or the readers to remember about simplicity?

Dave Thomas: I think the most important thing to take away is knowing that you have more control than you think you do. That you are in an unbelievably privileged position - that you can literally change the world. We have changed the world. The world today, better or worse, is unrecognizable if you suddenly came forward 20 years - and all of that is software. So we have an immense amount of potential and we have the capability of using that if we just get out of our own way.

So that’s I think that’s the most important lesson - you have agency.

Outro

Sarah Taraporewalla: I really like that. Well Dave Thomas, thank you for joining me on this Go To Book review. Simplicity is out now, isn’t it, on the shelf?

Dave Thomas: It’s in beta right now. It’ll be finished mid-summer sometime.

Sarah Taraporewalla: Excellent. Well, grab a copy and read through it. Thank you, everyone, for watching or for listening and dialing in and see you next time on the GOTO Club. Thank you, Dave Thomas.