This episode of Code Newbie is supported by Compiler, an original podcast from Red Hat discussing tech topics big, small, and strange. Check out their brand new series, Legacies, and listen to Compiler in your favorite podcast player. We'll also include a link in the show notes. Our thanks to Compiler for their support. Is your company looking to reach developers? Maybe you're hiring, hosting an event, or launching a new product?
Dev has new pro tools to help companies understand and reach our developer community, with no creepy tracking scripts. Dev is open source, so you can check on that. Visit dev.to slash pro to learn more. Send this message to your DevRel or marketing team. Welcome to the Code Newbie podcast, where we talk to people on their coding journey in hopes of helping you on yours. I'm your host, Saran, and before we kick off the show, I want to tell you about our incredible sponsors.
Today, we are continuing our conversation with programmer Dave Thomas. Last week on episode 50, we talked about his own coding journey and his work as founder and publisher of the pragmatic bookshelf. And today, we are getting back into the code side of things. So let's get to it. So there are two concepts that I'd bet most of our listeners have heard of that I believe you came up with, so the concept of a codecada and the concept of don't repeat yourself. So let's talk about codecadas first.
Where did that come from? I'm not necessarily going to claim to be the first on that, but I certainly thought I was the first. My son was very much into karate, my oldest son. And so he would go a number of times a week, and I would sit and watch what was going on. And a lot of the time would be spent doing kata and a kata is basically a series of moves. When you're first starting off, when you're like a white belt, obviously they're very simple moves and you just mechanically do them.
You know, you move your arm here, you move your leg there. But as you get more advanced, you start realizing that what you're actually doing is a series of defenses and attacks against imaginary opponents. And you actually are encouraged, as you're doing the kata, to imagine what those opponents are doing against you. And by the time you get to be black belt, you have to be able to both describe that, but also create your own kata.
It's judged on how realistic in a kind of a very, what's the word I'm looking for, ritual ritualized way, but how realistic they are in terms of actual fights. So when you stop and think about that, that is really no different to that process that we're talking about earlier on of how you get to be an expert by basically practicing and doing it over and over again until it becomes internalized in your head. All right, until you can do without thinking about it.
And that's what he was doing with the kata. So by the time, you know, when you got like a white belt doing a kata, look at their faces, their faces are scrunched up in concentration. And because they're concentrating, then their muscles will tense them because their muscles are tense, their movements are really pretty jerky. When you look at a black belt doing a kata, their face will be absolutely serene and their movements will be almost like ballet. That's really spectacular to watch.
And yeah, every time they'll shout in the, you know, put on an angry face, but that's just like part of the kata. So they will, you know, so they're internalizing it. So it occurred to me that, well, okay, then how would we do the same thing? How could we in software start to internalize the way we think about stuff? And obviously you do that every day on the job. I mean, you're learning stuff all the time and it's all becoming, you know, embedded in your brain somehow.
But I wanted to make it more explicit. And I also want to make it focused because on the job, it's all kind of mushed up together. So you don't really learn just one thing. Whereas if you look at say a martial arts kata, then they each one focuses on, you know, different skill sets. And I wanted to see if we could do the same kind of thing. So I created a set of, I think it's 21, maybe 22 exercises. And I tried really hard to tell people that there are no right answers.
Instead it's the way that you just repetitively try to look at these puzzles in different ways. And typically a kata will be a relatively simple question, you know, write, I don't know, write some software that helps calculate the league table for a baseball team or a football team or something. And then it will add on, you know, and now think about this and now think about that. But the idea is not to write a bit of code and say, hey, look, I've written a great program on how to go programmer.
The idea is to write that piece of code and then maybe forget about it and then a month later come back and write it again and then do the same thing. And if for example, you have switched languages, then go back and do the kata in your new language. And by doing that, you start to internalize some of the thinking. But by forcing yourself to do it differently each time, you also isolate the essence of the problem from the implementation of the problem.
And so you really get to understand the difference between the two. So I don't know, I mean, I know people enjoy doing the kata and I still, you know, when I catch people doing it, I'll make sure they're actually doing it in the right spirit, not as a competition, but as a training thing. And I still do it. So when I'm learning a new language, I will actually run through probably about 10 of them just to get myself, you know, comfortable in that language before I start doing the real work.
And I have a, I have like an ultimate kata, which is a seriously non-trivial piece of code. If there's a language that I like enough that I'm going to spend the next year, you know, doing stuff with it, then before I launch into that, I will try and write a mock down browser in that language. So mock down is that plain text language you're used to, you know, typically web pages now are using that one. They want to let you form that text.
And it is the ugliest syntax you could ever possibly imagine. It's not regular. It's not uniform. It's almost impossible to pause. And as a result, it's actually really hard to program in any kind of decent way. And so forcing yourself to go through and work at how to code it is a way of making sure you understand how to express things in your language of choice. So these kadas are not language specific.
It sounds like they're kind of generic problems that you can do in several different languages. And some of them are not even programming. Some of them are think about design. Oh, I like that one. So yeah, I mean, and to be honest with you, the ones I published are not quite, are not the Carter. They are examples because what I want people to do is to say, okay, this concept, the idea of practice is really important to me. And I'll come up with my own Carter that I will use to practice.
And you can, you know, welcome to use some or all of mine. But I think as you get more experienced, you'll probably say, you know what, this, this is all very well. So, you know, what I really want to practice on is, you know, data structures or maybe JavaScript event handling or whatever it might be. So I'll come up with Carter to tell me to do that. It's the repetition and the reflection that really make them important, not the actual problem itself.
So when we are creating our own kadas, what are some things we should keep in mind? What are the makings of a good Carter? For a typical Carter, the makings are that the problem doesn't get in the way of the exercise. You don't want to just have a, well, you don't want to have a Carter where before you start it, you have to basically, you know, sit back in a chair, close your eyes and think for two days on how you're possibly going to solve this, right?
It has to be something where there is at least a naive path through to the end. And my recommendation always is that when you're first starting to do the Carter, you don't worry about efficiency or nice design or anything like that, right? It doesn't matter. What you want to do is start at the beginning and code your way through to the end, right? And make sure that, you know, ultimately that it works, but you're not necessarily going for any of the aesthetics that you'd normally go for.
And then because it's a Carter, you repeat it. And again, I recommend that you don't think too much about design or performance or anything else. You just try it again. And then compare the two and then do it again and compare the two. And I'm interested, I guarantee an interesting thing will happen. I guarantee that as you just repeated without thinking too much about it, your brain is automatically going to start pattern matching what you're doing against all the other stuff that you know.
Now, the first time through, you're just focusing on the problem. So your brain, your subconscious doesn't have a chance to get out and talk to the rest of your brain because the rest of your brain is busy saying, well, how do I organize this and what kind of, you know, all that kind of thinking that you do in your code? But once you kind of like push that back, then your subconscious has room to talk to you. And it's going to be guiding you without you realizing it.
And what you'll find is as you keep coding this thing, it will evolve. And at some point you look at it and go, wow, that's actually pretty cool code. You know, how did I get there? Have you ever heard of inner tennis? No, I don't think so. What is that? Okay. So again, showing my age back in the 70s, you know, when, you know, gurus were kind of like cool. There was a guy who came up with a concept of inner sport. And one of his things was inner tennis.
And so he would teach people how to play tennis. And one of the exercises he did is he would get a big laundry basket full of tennis balls. And he would tell the person to hit a particular spot on the other side of the, of the cool. Right? And so he put like a little ball out there and he'd say, okay, hit that ball out. And their beginners, then they're going to get close to it. All right. And so he'd let them do that for like four or five balls. And he said, okay, now stop. Right.
And then he would get something like a chair and stick it where the ball out was. And said, okay, okay. So I don't want you to hit the chair because that's a chair. You don't go around hitting chairs. What I want you to do instead is to just hit the ball anyhow you want. Right? But tell me whether it lands to the left or the right in front of or behind the chair. All right. And you do that for an entire laundry basket full of tennis balls.
And then when you're down to the last couple of balls, the guy goes over there and takes the chair away and says, okay, now hit the ball. And everybody does with all of their remaining balls bang, bang, bang, bang, because by looking by doing it right by repeating it, I don't know how many balls are on a laundry basket, probably hundreds of them by doing that over and over and over again. And then most importantly, by giving yourself the feedback through a different channel.
So in this case, you're giving the feedback by speaking out loud and listening to what you just said. And you give yourself the feedback to say that was to the left, that was to the right, whatever else. Or basically that was wrong because you give yourself that feedback. Your brain is learning without you realizing it is building something called tacit knowledge.
And because you've got that, then without knowing how, which is kind of like the definition of tacit, without knowing how you do it, you can now hit that, you know, hit that cone with the tennis ball. And that's the basis of Carter that you're going to repeat it. And you're not going to be thinking about what you're doing. You're going to be trying to hit some particular goals and target, but you are going to be looking at what you've done afterwards and critiquing it to yourself.
I mean, ideally, to be honest with you, ideally out loud. And they're going to repeat it. And like I say, after time, your brain will learn from your own criticism and you'll be getting better and better and better. Yeah. Oh, I like that. I like that a lot. So let's talk about the next, I guess, phrase that you've coined. Don't repeat yourself. Where did that come from? So this came from the pragmatic programmer. So the pragmatic programmer is a book, which is organized around tips.
And each tip is from maybe one page to 10 pages long. And they cover all sorts of things. One of the ideas that I think actually was me, I wanted to get across, was the idea that coding, well, good coding is all about minimizing the impact of change. So what do I mean by that? Oh, I like that. So when you're writing code, right, what you're really doing is two things. You're solving an immediate problem, but you're also creating a future problem.
Because the code that you write is going to have to run a year from now or two years from now or whatever else. And in the real world, so much changes in a year or two years, that your code is going to have to change just to do the same stuff that it does now. You're going to have to maintain it. Basically, you're going to have to update it. People are going to come to you, if particularly if it's successful and say, hey, I need this feature and that feature and the other feature.
And what people found very early on in software is that the cost of that maintenance, the cost of making all those changes, totally and absolutely dwarfed the original development cost. It was orders of magnitude more expensive to maintain the code for its lifetime than it was the development. And as a result, a whole bunch of people came up with sets of rules on how to minimize that problem. And they came up with design methodologies and all these kind of two-dollar words.
But what they really mean when they talk about good design and good architecture, I think comes down to just one sentence. And that is, code that is well designed is easier to change than code that's not well designed. So design equals change is the fundamental rule. So now come back to your program. Let's imagine that you had written a web application and you had, you were displaying all sorts of like invoices and shopping carts and price lists and all this kind of stuff, right?
And you'd written it all and you know that your money format is going to be a dollar sign and then the digits and then a decimal point and then the two sent two digits for the sense, right? And so every single time you write out this money, you actually write, you know, say you're using Ruby, maybe you're using Sprint F to say, okay, here's the format I want and then here's the value and it will automatically put the thing into that value.
But you're doing that in a hundred places in your program. And then the person comes along, the customer comes along and says, hey, guess what? We've sold this thing to Italy and you know, we need you just to make that small change to change it. There's no more sense anymore. But all the values are, you know, large, you know, a thousand liter is about, you know, I don't know, same as ten cents or something. So suddenly you've got to change it.
Because you have repeated that formatting of numbers in a hundred places in your program, you're going to have to go through and find them all and change them all. Yeah. And so it doesn't sound like fun. It doesn't sound like fun, but it's worse than that because it's one of those things where you go home and not sleep at night because you may have only changed 99. Right.
And then at some point in future, you know, you may sell somebody a car and because you divide the number by 100 to format it, you know, you may sell them, you know, a $50,000 car for, was it $500? Yeah, because your code was displaying the number wrongly. The customer would be happy though. The customer would be happy until they have to give the car back. But yeah, I mean, it's, so one day of happiness. Yeah, one day of happiness. And then a lifetime of regret. Which I guess is reasonable.
So how do you get around that? What you do is you say, okay, so the concept of displaying an amount of money, right? That is really a business level thing. The customer is going to tell me how they want to display. For example, they may say, hey, I need this rounder to the nearest door or I need negative numbers to be in red or with parentheses around them or whatever it might be.
So clearly the concept of displaying money is something the customer is going to give you at some point, either implicitly or explicitly. So the implementation of that concept should be in just one place. And so you need to have a method somewhere called format money, right? I mean, rails, if you're using rails, rails as a help with it does that number of currency.
So you need to make sure that you are taking that concept and encapsulating it in one place and then using that encapsulation whenever you have to do the thing, whenever you actually have to convert something into a money amount. So what we're saying in, don't repeat yourself is that every concept has to map into one thing in the program.
And if you do that and you're religious about it, then it means when the customer comes along and says, hey, I want all my money to be like, you know, routed to the nearest five cents, then that's one change you're making the code. So by not repeating yourself, you are making it a lot easier to make changes to code. And so that's the fundamental principle behind dry. Interestingly after we wrote the books on email, just said, hey, you know what?
There's another acronym which is wet, which is right, everything twice. So take your choice. But yeah, I think dry, I mean, dry is something that we, we live by in the publishing, in our publishing business. So a lot of publishers will take information like catalog information and, you know, in spreadsheets, obviously, and then cut and paste it into, you know, 17 different backend systems and all the rest.
And you've probably seen this if you look at Amazon and you'll notice that things change and that kind of like some area now, then things are a little bit random. You know, so you'll see the same title and may have different information or different pricing or something like that. And that's because largely it's can cut and pasted and manually entered, not by Amazon, but by the publishers that feed them.
So by automating and removing that duplication, you know, we've made our business a lot easier to manage because of there's only one place that we have to change, to change anything. So the idea behind dry is always think, what is the authoritative source of this information or this process or this data, whatever it might be? And then don't duplicate it.
So I always wonder when I hear about principles like this in terms of teaching it, in terms of introducing these principles to a code newbie, at what point do they come in? You know, when I was first starting, I remember I heard about drives or the first things I heard about, but I didn't know what problem it was solving. You know, like I didn't have the experience to say, oh, yeah, that makes, I was just, okay, I guess I won't repeat myself. Right. So let's think.
So I learned to drive a car in England, which meant I learned to drive on a manual, not an automatic transmission. And when you're first learning to drive, that's like an entire new thing that you have to be thinking about. You have to be kind of like listening to the engine and, you know, changing gears at the right time and all this kind of stuff. Now I tried it once it did not work out. Oh, it's actually, I'll tell you what, once you've learned it, it's way more fun.
That's what I heard, yeah. Yeah. Well, particularly in England where the roads tend to be narrow and windy. So you can have a whole bunch of fun pretending to be a rally driver, which you can't do in an automatic.
But anyway, coming, actually thinking about rally driving, okay, so there are all sorts of, when you first learn to drive, right, all these expert drivers, which are basically kids that are a year and a half older than you, we're going out and saying, oh, you know, you have to learn to double the clutch because that's the only way to change down and not lose revs.
And, oh, you know, you have to learn to change down as you're going into a corner, just so you'll have the right gear when you're coming out of it, all these little rules that you make. And the truth, I mean, if you really want to drive effectively and efficiently, you know, that's the kind of stuff you'll do. But when you're first learning to drive, that is poison.
That's the kind of stuff that causes you to kill yourself because you're not thinking about, you know, the basics, like not hitting lamp posts. And instead you're thinking about double the clutching. What was the order again? I can't remember. Yeah. So don't, don't even go there. All right, when you're first learning, don't think about rules, right? Rules do not apply to you. You get a pass, right? You can just do what you want. You can just code it in any way you want.
And then what's going to happen is if you do that and if you do it enough and again, it comes down to practice, if you do it enough, you're going to start noticing problems. You're going to start noticing that, for example, you know, every time you have to change something, you have to change it in three places. And one day you're going to forget to do the third place and you're going to get some really strange results.
And it's going to spend, you know, you're going to spend a good two days working out why. And then you'll say to yourself, hey, I'm not going to do that again. And you'll say to yourself, well, how can I avoid doing that? I know. I should put all of that logic into one method. And then there would only be one copy and I wouldn't have to duplicate it. All right. And then you may say to yourself, oh, okay. So that's a really interesting rule, right?
Rather than cutting and pasting a whole chunk of code, it's probably better if I stick it into a method. And what you've just done is worked out for yourself through trial and error that this is a good principle. And then you may just do that for the rest of your life and not even think about it or you may be doing that. And then two years later, someone says, dry to you and you go, what in the earth are you talking about? And they say, don't repeat yourself. And they explain a bit about it.
And you know, let that mollier quote about, you know, I've been speaking prosal my life, you know, it's the same kind of thing. You know, I'll be writing code and I've been following this principle that I didn't even know I was following. And that's perfect. That's exactly what you're supposed to do.
Because then you've already, you already know the technique, you know the principle and you now have a word so that when you need to describe it to somebody else, we're on the time to go through a paragraph of discussion, you have a jargon word, you just say, oh, yeah, that's dry or that's not dry. And they'll get what you mean. It's the same with all of these rules.
They have to be motivated by problems that you see in order for you to actually honestly believe in your heart that they're worthwhile. Otherwise, it's just some experts standing up there, pontificating, you know, and maybe you'll try it. Maybe you won't, but your soul won't be in it. You know, you have to make the mistakes and then you have to fix them.
And that's why I keep saying that when you practice, and practice could just mean working on the job as well, you always have to be monitoring what you're doing and looking for opportunities to criticize it because it's only by doing that that you get better. So how does that relate to learning, not just principles like dry, but also patterns, right? Because patterns are also tools and in short, not as bad patterns are not tools. Patterns are the work of the devil. And not tools.
Wasn't expecting that okay. Okay, so let's step back. Okay, so what is a design pattern? A design pattern arose because in the 1990s, Ward Cunningham created a wiki, a wiki wiki where, and it was like the first one and it was seriously cool. And a whole bunch of clever people that met at conferences got onto this thing. And started working out that they could collaboratively create documents.
And one of the groups that got onto it was concerned with principles of design and principles of object orientation. And they started trying to find ways of expressing what they felt those principles were. And they, in the past, people had used like really high level, you know, hand waving. They wanted to be more specific. They wanted to say, if you are in a situation like this and you are faced with this problem, then here is a template for solving the problem.
And they actually came up again, came up with this strategy for describing a solution because there's an architect called Alexander who actually wrote a book of architectural patterns. You know, and his patterns are like every room has to have a window and things like that, you know. So they tried doing the same thing and they came up with these patterns. And if you look on the wiki, it's just still there. C2, or is it C2.com, I believe is where it is.
You'll still find it there and it's still active and people are still contributing to it, bless them. They came up with these patterns and then as is the way for them got together and decided to write a book. And so they wrote the famous book, Design Patterns. It has, I think it's 21 patterns in it and they are all written in that same style. You know, if you're in this context and you have this problem, then think about this solution. And it's a great book. It's a fantastic book.
Except most people who read it don't understand what it's for. Because most people will look at that book and say, hey, this is a cookbook. This is giving me little modules that I can put together to solve my problem. So if I have three decorators and a singleton and whatever else, then I can put these together and I can make some code that does something. But the reality is that the Design Patterns book is not that. The Design Patterns book is a way of naming things, nothing more than that.
So it's really saying you will have written code that has these kind of things in them. This is what you call them. And in particular, the Design Patterns book was written for a language called C++. And C++ is a remarkably ungainly language in which to write object oriented code is getting better. But back then it was horrible and still vaguely horrible. So the patterns in there were solving problems as much with the language as with the design. You know, C++ made it hard to do certain things.
And so their patterns were ways of basically overcoming those obstacles in C++ to achieve what's perfectly reasonable but a design. If you were to take the Design Patterns book and then rewrite literally those patterns in Ruby, so you take the same patterns in your Raging Ruby, I think more than half of them just evaporate. Right? There is no problem. I mean, Ruby doesn't even, Ruby looks at that and says, you know, that's just align a code that you write.
You know, why do you need a book about this? So, patterns are very, very misunderstood. They're not recipes. Instead, just like we talked about with dry, right? You come across it, you use the principle and then someone says, hey, what you've just done is dry and you go, oh, that's cool. I've got a word for it. It's the same thing. You write code and you refactor, you change it into the right shape. The shape that you think is good.
And the chances are pretty good that you will have along the way used one or more of these different patterns, not necessarily from that book, but from the whole catalog of patterns. And if you know the name of that, then it would make it easier to describe to another developer at what you just did. Right? So you can treat patterns as being nothing more than shared jargon, you know, just like airline pilots and ballet dancers have their own jargon for things. Then programmers too too.
And patterns form part of that jargon. So it sounds like it's not so much that the patterns themselves are bad. It's just that they're misused. They are misused in a really major way. Yeah. I mean, quite often when we're doing consultancy, we'd wander into a project team and we discover that all of the classes in that code were named after patterns, you know, really? Oh, yeah. And it would be, wouldn't necessarily just be the pure pattern name.
It would be like, you know, account observer and, you know, this kind of stuff. And once you saw that, you knew that the only thing you could do is take that code out in the car park and shoot it because it was never ever going to work. That's funny. Not a few of the code, it's not. Okay. So there's one more topic I really want to get to and that is Agile. Ooh. Can you excited about that or are you talking about that? I'm thrilled about that.
Yeah. Okay. So the Agile software manifesto is kind of where it all began. Okay. Okay. Stop. Stop. Yes. It is not the Agile software manifesto. Ooh. What was it? Agile software manifesto for Agile software development. And that is a major, major, major difference. Tell me the difference. Okay. And Agile manifesto is a manifesto that gets up on the table and dances. Mm-hmm. A manifesto for Agile software development describes a way of developing software with agility. Mm-hmm. Now, why do, okay.
So why am I being like, you know, a jerk about it? The reason is that if you use, if you say Agile manifesto, what you really mean is that Agile is the thing being described in the manifesto. All right. So that means that you're using Agile as a noun. Mm-hmm. Right. So you actually have this thing called Agile. Now, in the English language, Agile is not a noun. All right. It's, well, it's a way you do things.
It's, and as a result, if you fall into the habit of using Agile as a noun, you stop thinking of it as a modifier on things you do. And instead, you think of it as a thing you buy in or you practice whatever else, right? It becomes less of a set of values and more set of rules. Right. And that one mistake that people make using Agile as a noun has basically, to my mind, destroyed the value of the concept of the manifesto. Now, having said that, I still think the manifesto is good. I really do.
I don't think I wouldn't change much if I was changing anything. I mean, I'd get rid of some of the practice stuff, but the first page, you know, the, we value this over that. I still think that is a fantastic way of expressing what's important. So let's get a bit more context on what that manifesto is about. So tell us about the goal of it. What was the goal that your tiny accomplish? So it was written in 1999, I guess. I can't remember. Right about them.
And back then, we were leading up to that software. As I said before, there was a bit of a crisis. People were discovering that software was hard and writing it was, you know, not cheap. And so everyone was looking around for, you know, the magic cure. And so they would listen to all these gurus who came up with schemes and these schemes would sound like they should work. And so we had all sorts of methodologies and processes and diagramming techniques.
So we had things called the rational unified process, which is a wonderful name because it implies that somewhere there's an irrational unified process. We had things like, um, you know, unified modeling language, which we still kind of use today for drawing down class diagrams and things like that. And companies would be formed in order to sell consultancy and training on all of these various methodologies. And major amounts of money were spent by companies bringing all this on board.
And it kind of helped a little bit, but the reason it helped was not necessarily that these methodologies themselves were better. It was that by forcing companies to think about what they did, they got better, you know. They just focus on, you know, so any methodology is better than non-basically. So at the same time, a group of us were kind of rebelling a little bit against that because we didn't think that was addressing the right problem.
The fundamental problem that we felt was that software is all about change. It's because the previous methods were typically go out to the customer, write down the requirements and then get them to sign off on those requirements, then go back into your office and write the code according to those requirements, which if you're a manager is great because it means you put in a bit of work up front.
And then, you know, a year later, this team comes back with their delivered, you know, magic gift wrap box for the software. Yeah. But the reality is that two things, first of all, nobody actually understands up front what their requirements are. All right. Nobody does. You know, if you're not just software, you know, if you go into a store to buy a pair of shoes, right, you don't just walk up to the pair that you wanted and buy it, you know, you've got to look around and whatever else.
And what do you do? You try them on and you get feedback, right? The same with customers. They don't know what they want. They're going to go in there and they need feedback. They need to play with software. So that's one issue. The other issue is that even if through some miracle, they did know exactly what they want. There's been all sorts of studies that say that requirements change over a period of time at an alarming rate, something like 25% of requirements become outdated per year.
Oh, wow. Yeah. Which when you think about it, if you're on a two year software project, half of the stuff you're doing is wrong. Yeah. If what you do is you get the requirements up front. So we were everybody in this group was like, and it wasn't just the agile people.
There were hundreds of people, maybe thousands of people who were thinking about ways of writing a software in smaller cycles with a lot more feedback and a lot less ceremony, a lot less signing off on the big requirements document. And we tended to get together at different conferences. So we'd meet at like UPSLO as a big conference, the object oriented programming languages and systems conference.
And we'd all get together and have a beer and talk about how bad the world was and how we should fix it. And one day a group of us got together in a ski resort in Utah and basically said, okay, what did we got in common? Yeah. There were 17 of us in the room and we all had different ideas about how you actually go about writing software. But the question really was, what were the underlying values that we all shared? Because if we could extract those, then maybe we'd be getting on something.
And we very quickly came up with the full values in the manifesto as the things that we felt that were important when writing software. And I think those things are still central to the process. I don't think there's any discussion about that. However, what happened is just the same way with the tools in the 1990s, a whole bunch of people came along and basically recognized it as a chance to get in there and sell new consulting to the same people.
Remember all that stuff we taught you in the 90s? Well, actually it's all different now and we're going to teach it to you again. And so a lot of people jumped on that bag and walked in and offered training and they offered consultancy and they wrote books. And they did that by turning the word agile into a noun, right? Because you can sell a noun. And so you'll find all these people are out there selling agile. And as a result, it's become diluted all the way down.
And the reason that what they're doing is wrong is actually built into the manifesto itself. And that is there is no one way of doing it. There is no correct way to write software because it depends on you and your team and the problem you're solving and the organization you're solving it in. And the year and all sorts of factors play into the correct way to do it. And you don't know the correct way when you start out. And what do you do when you don't know the correct way?
Will you take a small step and you see if you're closer to where you want to be? And you keep doing that. You take these small steps and you're constantly monitoring to say, is this small step moving people forward? And every now and then you'll miss step and you'll have to go back and go ahead. But it's only one step. So nobody cares if you have to go back. It's not like you've done the entire journey and ended up in the wrong place.
So by taking these little small steps, you're going to get closer and closer and closer to your goal. And so that's how that's how software should be written. You can't do that if someone comes in and says, here is the 74 step so that you have to follow to get from A to B. It's not going to work. So that's why I'm very disappointed. Oh, I just wanted to say the wrong word. Disgusted maybe with the current state of the quote agile movement.
I mean, any movement where you can spend $1,500 for a two day training course and at the end of it, get called a master. Yeah. Yeah. But you put it like that. It sounds so ridiculous. Well, I mean, yeah, I mean, I could do three days and become a surgeon. Well, that's pretty good. So anyway, so that's my rant about agility. Do I believe in agility 100% I do? I mean, I think that that's the way not just software is written. I think that's the way life has lived. Right.
And that is work out where you want to be, work out where you are now, take a small step towards it and then reevaluate where you are. Right. And if you do that at all levels, it's kind of one of these fractal things where you have to do on the small decisions and the big decisions. Right. Try not to do anything that's irreversible because that way you can make mistakes and it doesn't matter. There's no need to be paralyzed by this fear that all I'm going to make a mistake.
Who cares if you can just hit the undo button and go back? And you know, that's why a lot of the practices talk about these small iterations, version controls. You can go back, but in life, the same thing. Right. How can I make decisions where if I get it wrong, it's not going to be an absolute disaster. You know, and there's lots of different ways of doing that.
So those are the kind of, you know, those are the kind of agile principles that I think people should be learning and should be applying. And all the rest of it, you know, basically if it involves a diagram, then forget it. No diagrams and no diagrams. I understand in principle that having a 72 step agile process kind of defeats the whole purpose of it being agile.
But when you Dave Thomas are building a product, do you have more specific processes, names, tools, whatever you want to call it that is a little bit more tangible than the principles in the manifesto? Like I understand there isn't a way of doing it, but do you, do you have your way of doing it? Yes. And then I have like a substrate that I always want to have. And the substrate will be, I mean, assuming the project, okay, let's step back a bit.
One of the interesting things is as you get deeper into software development and if you particularly are spending time solving problems for clients, whether it's internal clients or external as a consultant, you'll find that quite often they call you into solve a problem because they think software will fix it. And as you get more experienced in the business side of things, quite often you'll work out that actually no, this isn't a software problem.
It's an organizational problem or it's a procedural problem. You don't need software for this. You just need to like move these two offices around so these two people can talk to each other, you know, whatever it might be. So there's always that step which is kind of like a validation of, yeah, I think this is actually something where I really need to write software to fix it.
And so that's my first step whenever I go into a customer or wherever you think about doing it internally too for our own systems. I always stop and think is this really a problem that needs software because software is expensive, it's difficult and the more software you've got, you're carrying this load on your back, you know, for the next 10 years, you really don't want to have a lot of software. So that's the first question.
Once I've decided it is a software problem, then typically the kind of environment that it runs in is going to fall out simply because you're doing it in a particular context. So there may be a Java shop or there may be a Ruby shop or whatever it might be. And so you know the kind of environment you're going to be working in. So at that point what I'll do is I'll set up a project to contain all the stuff I'll be doing.
And I'll set it up with version control, I'll set it up with testing and I'll set it up with deployment. So day one, I mean literally day one, I'll be able to deploy an empty, non-working project. And the reason I do that is because I know that my customer doesn't know what they want. And if they did, I still wouldn't understand it 100% accurately. So what I want to do is I want to show my customer as we go through.
And so they'll basically sit there and they'll say, okay, so what I really want is like a shopping cart blah, blah, blah. And I'll hack something together using just like really rough and ready, whatever I can find, I'm cutting paste and make something horrible and deploy it up to some staging server somewhere. And I'll typically either walk into their office and show them or I'll send them a URL.
Increasingly is just kind of like, I'll have like some kind of wiki or something that will show them where they can go. Look at it. And they'll look at that and say, oh no, no, no, that kind of shopping cart. I want a shopping cart with this and that and the other, you know. And we will slowly iterate. And because I'm in a position to run this thing as a little mini project, I can be deploying a dozen times a day.
I actually, I mean, our online store, when it's live, what it's live, I will quite often deploy, you know, a dozen times in a day to that store. Wow. Because, oh, two, I mean, sometimes because I just screwed something up and I have to fix it. But as much as nothing else, it's because if I have a small enough feature that itself contained, then there is no need to bundle that up into a whole set of features. Let's get it out there.
And quite often I'll get it out there and a couple of hours later, some customer will you know, start using it and say, hey, you know what? I tried to use your storage now. And it's something has changed and I couldn't get this to work whatever. And you know, we'll discover errors in the workflow or just ugly workflows because people use it. And it's the same thing when you're talking to a customer.
So the toolbox is really nothing more than an environment that lets you write code and delete code really, really efficiently. And then that allows you to show it to your customer as you go along and get the feedback. And it also means that, okay, at some point you may want to bring somebody else into the project. Well, you've already got version controls that up. You've already got a build machine set up. You've already got deployment set up. So this person can hit the ground running, right?
They just check out your repository and they've got everything they need. All right, there's no need to sit there and say, okay, now you're going to go and, you know, install, you know, visual, whatever and source. You don't have to do any of that stuff. It's all done for you in the project. And that's like a major step forward too. It means that everybody's consistent, everyone's working on the same page.
So I mean, that's not really a direct answer because I suspect you want to diagram with 72 steps and I don't have one. But largely, it's that largely, it's just, you know, you need to find an environment that lets you run a role and get feedback at the same time. And if you can do that, then you're stepping neatly towards Nevada. So it's not so much that you are against tools like Trello or Pivotal Tracker, any of those. It's that the emphasis shouldn't be on those products.
The emphasis is on the process and how you code, not what you use to code. Absolutely. Absolutely. I mean, I don't know. Have you ever been on a team where the manager comes in and says, hey guys, we're all going to use, you know, name a tool, Trello or whatever else, right? How successful is that? Everybody uses it for the first two days. At the end of that time, maybe half the people are using it.
And gradually it dies down to the manager and the suck up employee of the two people using it, right? And everybody else is just ignoring it. A tool has to solve a problem. Otherwise, there's no point in using it. So you have to, what you have to do is rather than start off with a whole bunch of tools, you start off with as little as you need and you wait to have problems.
And typically I will wait for a little bit longer than I should simply because quite often what feels like an enormous problem at the time with a little bit of hindsight was just like, you know, you were being stupid. So you need to kind of wait to make sure it genuinely is a problem. But once you've discovered something's a problem, then go out and try and find a tool that solves that problem.
And in the ideal world, you'll want to find tools that can work together and interface with each other. Yeah. So like, there's nothing nicer than if I have an error in our online store and it raises an exception, then that goes from gets picked up by an external service called airbreak. And then airbreak automatically adds it as a bug report on GitHub.
And so I just have to go to GitHub and have a look at the issues and there I can see all the errors that have been reported along with links to the source code and everything else. It's fantastic. That's solving a problem for me. Yeah. And it's solving it with a bunch of tools that each do a specific job, but work together. Yeah. And I think that's the way you need to approach tooling. Right. Otherwise you sit there and you become one of those people that drool over the actual tool catalogs.
Yeah. Yeah. If you do woodworking, the one of the things that's really interesting about woodworking is that the catalogs are pure pornography. I mean, they are just, you know, these incredibly well lit pictures of curved blades of carving tools or the, you know, the saw and the handle with inlay blah, blah, blah, blah, blah, blah. It is designed simply for people that like looking at pictures of naked tools.
Yeah. You know, and if you get a real craftsman, someone who actually does work in wood, the chances are pretty good. They're using their father's chisel, you know, and it's probably got a different handle to the one it came out with and it looks like it's worth about three cents. And using it, they can create, you know, the most exquisite whatever. Whereas you with your fancy $3,000 Japanese chisel with the inlayed pearl, you know, you sit there and cut your fingers off. Not you, not you.
I mean, you the non craftsman. So yeah, I'm into tools, but only after I actually find a need for them. So I understand the disgust with the productization of agile and it being a noun, but despite the agile movement being a movement, do you think that there has been more good done by that movement than it has hurt the software community? Up to now 100%. I think that's a great question. Yeah, I think it has and I think largely for two reasons.
I think firstly because it has helped people to focus on the need for, you know, certain qualities in their software teams like communication, like feedback, like short iterations, the kind of things that, you know, really people knew they should be doing all along, but either they didn't have a vocabulary for it or they didn't have the the motivation to do it. So I think it's very much helped in that way.
And I think it's also helped because the, I think it's allowed developers to take back control development to some extent prior to it.
Software development was very much a command control kind of system where, you know, some pointy hair boss way up the chain says we need this and then, you know, some VP gets tasked with doing it, which means some director gets tasked with doing it, which means that some manager gets tasked with doing it, which means some project manager gets tasked with doing it.
And then eventually the programmer ends up being told, yeah, well, actually know what happens is, you know, an architect goes away design and creates the architecture and then design it goes away and creates the design. And at the end of the day, some poor programmer is given this design and is blamed when it doesn't work, which is, you know, 90% of the time.
So what agile has said is that doesn't work, which everybody knew, the way to make it work is to make the loop involve the customer and the developer. And you just kind of like let the two of those iterate towards whatever they need to do. And you'll be a little better off. And I think that because that has been seen to be successful, more and more companies are doing things that way. And that is fantastic. I think that's made developers lives a lot more interesting and a lot more fun.
You know, they're no longer sitting in the cubicle, having food thrown over the wall at them, you know, like in a zoo. Instead, they're actually getting out there and talking to customers and getting feedback from them. And that's fantastic. I absolutely love that. So you said up until now, has anything changed recently? Well, yes, because, okay. So one of the things about agility is that it's really easy to do as one person. It's relatively easy to do as 10 people.
But no one's 100% sure how to do it as a thousand people. Now, up in the early days of the movement, you know, when people come along and say, how would I scale this to a thousand people? The stock glibons, who was, you don't, because you don't want to have a thousand people. You know, no sulfur project shut up with a thousand people down here. And largely that was actually correct. But there are projects that do require a thousand people.
And that are probably cannot be broken down in the way that, you know, we naively thought they should be able to be broken down. And so even if they could, the companies aren't prepared to do that because fundamentally there's a political benefit to being the manager of a thousand people compared to being the manager of 10 people, right? So, you know, it's not going to change. There will always be these large teams. And so in the last couple of years, the concept of enterprise agile, right?
If you ever want two words that, like, you know, leave that kind of slightly tangy bitter taste in your mouth, it's enterprise agile. And that's a whole bunch of quote methodologies have grown up aiming to solve that problem. And from the point of view, and this is going to sound very cynical, the part of the motivation for that obviously is that the bigger companies will spend more money on consultancy for this than there's more companies will.
So if I can create quote agile for the, you know, fortune 500, then I'm going to make more money than if I sell it to, you know, the mumble pop shop down the street. So you see all of these things coming out that, you know, say that we are agile, but they're agile except, you know, obviously you can't do this practice because you need reporting back up to the management.
And obviously you can't do this practice because, you know, you can't trust developers to actually develop on time and, you know, and then we had to add these 17 other, and you end up with these things that are actually worse than the things that we were doing in 1995. In many ways, they've regressed way, way back to the beginning of software development. Because they basically haven't, they don't actually know the spirit that, you know, they should be following.
So I think that there's going to be a reaction against those in the same way that there was a reaction against things like the rational unified process. So I'm very much hoping that a group of 17 enthusiasts will come up with something that basically gets us back on track. So yeah, that's why I say until now, I think we've basically peaked in terms of the benefit we're going to get out of it and we need to move on.
I'm not saying throw it away, I think I still think very passionately that the values in the Agile Manifesto are things that you should live by. But I think the bigger picture of the, you know, do I have the Agile stamp in my passport? I don't think that's going to be as valuable anymore. Well, if you're listening and you are one of the 17 enthusiasts, you have some work to do. Absolutely. Absolutely. You've done it. So then I can start a consultancy and sell it to people. There you go.
So next let's do some rapid fire. Fill in the blank. Are you ready? I think so. All right. Number one, worst advice I've ever received is, okay, I need to do a politician and pivot this one. Can I give you the best advice I've ever given? Please, please. You could do one of each. How about that? All right. Okay. Okay. I should be sneaky. Worst advice I've ever been given was my mother saying always be polite.
And the best advice that I've ever been given is, remember I was talking about that guy who employed me out of college in that kind of startup sweatshop and he taught me about how to work in the business, right? So we went to a meeting with a company that produced a world leading product, big company, well known throughout the entire industry. And we met with like the chairman and the CEO, something else, right?
We sat around this table and I was like 23 years old and they were in their suits and in there, everything else. And I was worrying my kind of like open mixture in the Laeros and they were telling us all how it had to be in everything else. And they got it wrong. I mean, they just didn't understand some stuff about what we were doing and what we were doing is we were reporting their product into a different platform and they were telling us how to do it and they were wrong.
So at one point, I just basically said, okay, guys, look, this is, you know, this is stupid. And I said, you know, that's not what you want to do. You have to do it this way, this way, this way, because of this, this, this, and this, right? And everything went quiet and it was kind of like awkward. And then my boss who was Irish and therefore could talk his way out of everything, you know, basically started the whole thing going. So afterwards, you know, I said, oh, I'm really, really sorry.
You know, I put my foot in it there. I shouldn't have like spoken out. He said, no, right? You did exactly the right thing. You are, you were perfect to do that, right? The only mistake was using the word stupid. He said, he said, whenever you know something and the client doesn't, your job, your responsibility, is to tell them because that's why they're paying you money. If they knew it all, they wouldn't need you, you know? And that to me has been kind of like a principle for life.
I really enjoyed that. I was kind of like, yeah, okay, I get that. So that's why my mother was wrong when she said, always be polite. I mean, yeah, maybe you should always be polite. We don't always agree with people who was about to have about that. Yeah, don't be afraid to disagree. Yes. Number two, my first app was about... So not quite my first, because my first app was probably what is your name, or hello Dave. But my first substantial app was actually written in that environment.
We were writing a basic and we were running our programs. We were writing our paper tape and we were feeding the paper tape into a paper tape reader that would go up through 110 board modem, which is 110 bits per second, up to the local mainframe for the county council where it would run. And then the results would come back to us on a telltide. And every student was allowed to have five programs stored up on the mainframe.
So you'd be able to take your paper tape, load it up to the mainframe, and it would be one of five programs that you could have and then you could edit it on the mainframe without having to load the paper tape. Well, I of course needed way, way more than five. So the first serious program I wrote was a self-modifying basic program that acted as a file system. So I could import files into this program and then export them out into the working space to edit them and then stick them back in again.
So they were kind of shocked to discover they had something like a 25,000 line basic program. Well, actually it wasn't for me for that. It was 200 lines. And all the rest of it was like a thousand programs that I'd stored inside it. So that was my first. Oh smart. Did you share that tool with your? Oh, yeah. Everybody on the course ended up using it.
Yeah. Nice. Number three, one thing I wish I knew when I first started to code is I think probably the thing that I wish I'd appreciated earlier is that coding is largely a communication exercise and not a technical exercise. And I think I now think of programming as being a little bit like those simultaneous translators that work at the U.N. and stuff who can basically on the fly translate from one thing to another thing.
Because I think what we're doing is in the end of the day, we are translating from the real world, which is sloppy and messy and gets things done into this incredibly tight controlled world, which is the computer and all the attendant crap. So I think that if I had realized a bit earlier on that I was a translator, then I would have early on worked on skills to help me work with people and extract what they needed better.
Sorry, those are really ugly sentence, but just doesn't get the point across. Right? Yes. Okay. Yes. Like it's the way across. So next let's do some shout outs. Do you have a couple of words? Okay. So yeah, I'm thinking about I'm a code newbie. Okay, first of all, let me say I am a code newbie because I think every developer has to be everybody has to throw themselves into the deep end of something new on a regular basis otherwise they're basically just dying.
So I'm trying to think what would be cool for me in the kind of newbie role? And let me just recommend a book and a programming language. So the book is a classic that is actually in a way a little bit old fashioned because it talks about some stuff that you know, mainframes and things that don't really exist anymore in that kind of context.
However, however, go and find yourself a copy of Fred books, The Mythical Man Month and read it and read it because he talks about organizing a project team that was writing an operating system, massive massive bits of software, I mean really, really phenomenally large amounts of software. And how do you put together a team that does that? Now, the key thing about the book, I think, is not that you are trying to learn from him how to develop a team.
Instead, I think you're learning from him the process that you go through when you're making mistakes building a team. And that's the really valuable bit. The thing that makes him different is he's thinking about what he's doing as he's doing it and he's adjusting the process. And it's got some really valuable advice in it.
Things like, you know, it's okay to believe that some people are different to other people and you know, some people do one job better than another job and it's kind of stuff. Also the introduction to the book do not skip. I don't know if it's the preface of the introduction, but he talks about programming because a lot of his audience at that time were not technical people, other than were managers. And he talks about the spirit of programming. And he has this sentence, what's it go?
Programmers like poets build through exertion of the imagination, creating castles out of the air. And to me that has really captured the spirit of what I love about programming. You start off with an empty editor buffer and you can basically create anything. And that is mystical. So it's a good book. I'd recommend that book. Why is it called the Mythical Man Monks? Ah, good question.
Because back then it's the old, okay, so if it takes one woman, nine months to have a baby, how long does it take nine women? You know, you can't throw bodies at some problems and expect those bodies just as like, you know, even out the divide down the time it takes. So if you were digging a ditch, right, if you have one person digging the ditch, it may take ten days. If you have two people digging the ditch, it may take five days. Three, maybe it'll go down to four days, right?
If you have eight thousand people digging the ditch, it may not ever get done at all. It's just like a, and so the idea is you cannot think back before that, we were planned projects by working out this task will take three man months and this task will take five man months and this task. So therefore, but a hundred people on team will get done in three and a half minutes, you know? And he's saying, no, that's not how it works. Ah, thank you for that.
I've heard of that book many, many times and I never knew why it was called that. That explains a lot. Thank you for that. Well, you should read it and then you'd know why it was called that. That's true. That's another way of solving that problem. Or you could just do the cliff notes. Yes. Yes. And then in my second, my second shout out is slightly self-interested, but not really and is to do with programming languages. I am a firm believer that developers need to learn programming languages.
It's the fundamental tool that we use and the more you have, and it's like, you know, if you call it a compaderny, a ride and only has a hammer, you're going to be kind of like a little bit disappointed. I would be disappointed. Yeah. So I mean, you need to be able to use a few tools and programming languages are one of those tools, but it's more than that. And programming languages obviously have different strengths and weaknesses. So Ruby is a polyglot language.
It has many, many things you can do. You can write straight forward, top to bottom linear code. You can write object oriented code. You know, there's lots of different styles that you can use to write Ruby code. And I love Ruby and I still do and it's still a language I use many, you know, probably most days. But there are some things that Ruby is not good at. One of those things is concurrency, the ability to run multiple parts of your program at the same time or apparently at the same time.
And another thing that Ruby is not good at is managing the data that you work on in terms of making sure that it doesn't get corrupted by too many people trying to do too much to it at the same time. And those problems are only going to get worse, I mean, as computers continue to develop, what you're going to find is not that you get faster and faster computers. I don't know if you noticed this, but you know, the speed of the CPUs has not been increasing.
In fact, in some cases, generation to generation has actually been decreasing. But instead what happens is you end up with processors that have, you know, two calls, four calls, eight calls. You know, next year, it'll probably be 64 calls or whatever else. But each core is effectively its own little processor. And so if you have a two-call processor, in theory, it can do twice as much work as a long-call processor. But you can only do that if you keep both calls going at the same time.
And a language like Ruby and frameworks like Rails are really not good at doing that. Just because they weren't designed for that kind of environment, it's increasingly obvious to me that in the future, functional languages will get more and more prominent as we face those problems because functional languages actually kind of neatly sidestep those issues. They sidestep them by, well, it depends on the language.
But the one I'm thinking about, Elixir, it sidesteps the data issue by saying that data can never be modified. Once you create some data, you cannot change it. All you can do is create a copy of it. It's been modified. So the original data is still there, but then there's a new version of the data that has a modification. And that turns out to get around almost all of the problems of corrupting data due to two people trying to access it at the same time. So that's really powerful.
The second thing is that it is designed to be concurrent. So in an Elixir program, you can have hundreds and thousands of independent processes all interacting and interacting in a very controlled and easy to understand and maintain way. And because of that, I think that it is going to be possible to write larger programs that basically stay working longer in that kind of technology.
So my second shout out is that I think, I mean, please get familiar with a language like Ruby to start with because that's a bread and butter language and you'll be doing good work with it and you'll enjoy it. But don't forget to have a look at functional languages as well. Because I think by the time your career is five years old, they will be on the ascendancy. And the early you can catch that wave, the less effort you're going to have to be putting into learning them.
So I would suggest that maybe, if you're just studying off with Ruby now, wait until you get to that, aha moment, that comfort moment. And then at some point, round about there, start playing with a functional language. And the two that I would recommend you look at, either look at Elm, which is a language that runs in the browser, which is a functional language or elixir, which currently runs on the service side and is a functional language.
And both of them will repay you many times in terms of new ideas, new ways of doing things. And just basically some fun. So that's my two shout outs. So functional programming isn't a new thing. Why is it, is it making a comeback? Do you think in five years or what's going to be different now that's going to make it be an ascending thing in terms of languages to learn? Well, I think, I mean, object orientation is not a new thing, either object orientation started in 65.
So does that make it that's 50 years old, isn't it? I can't do the math. But I think what's happened is that the world has changed. In the past, we could always rely on Moore's law to give us faster and faster processes. Now we are reaching limits where quantum physics and the speed of light mean that we cannot necessarily increase the clock speed that much more. And so we can still get more and more gates onto a chip, but we can't do it and get them running faster.
In the old days, a program would be effectively a single thread that would start at the top and get to the bottom and do its business. And so it would run on a processor and it would take that whole processor or as much as it needed and run. But now you're going to have to write a program that splits itself into 16 independent parts and cooperates with those parts to solve the problem because you have a 16 cool processor.
And if you just run top to bottom one thread, you're only using one 16th of the power of your computer. And so those changes combined with the fact that now everything is networked and everything has to sort to it, to other things. Those things are driving you to a distributed concurrent functional language. So I think the reason they're on the ascendant, yeah, they've been around forever.
And ML was like 1970, something too or something, but they've been around forever, but they've been tagged as being kind of like academic languages because they were used for research purposes. And only now are people getting to realize that those languages actually suddenly solve a problem that's been creeping up on us. That maybe we didn't realize until things like Ruby became more popular? Yeah, I think so. Ruby actually paved the way in many ways.
Ruby had something that was, nothing in Ruby is new, but the combination of things in Ruby is. And Ruby was kind of like the Greece, the permission for developers to use an interpreted language that had dynamic typing. Up until then, they were using C++ and Java, both of which had very incomplete but apparently rigid type systems. So people said, you know, the only way to write reliable production code is if you have static typing and blah, blah, blah, blah, blah.
And the biggest hurdle to introducing Ruby was convincing people that they didn't need that, that it was okay and it was safe to use a dynamically typed language. And I mean, I know that because I used to go to Java conferences and do the Ruby talks and those were always the issues that came up. Now what we're discovering is that the entire idea of orientation where you have an object that contains mutable state and then a class that defines the methods that can act on that object.
We're finding that that is too cumbersome because it represents a coupling between the data and the code. And whenever you hear that coupling word in the context of software, then you're talking about things that are hard to change because you change one, you have to change the other, right? And so functional programming is in the ascendancy because you don't have to do that anymore. So it's not because of Ruby. I think Ruby actually was a step that we had to take.
I think without Ruby, people would be looking at dynamically typed languages saying, you know, if you have to make two steps from a statically typed language to a dynamically typed and also throw away your object orientation and go back to a functional style, right? People would not take that leap. So we had to do it in steps and I think Ruby is a step. And I don't, I mean, it was interesting at the Ruby conference.
I've just started off this keynote, the final keynote with something on the lines of Ruby is dead. And I don't agree with that. I think Ruby has possibly peaked, but I think that peak is going to last for a good number of years because it still delivers value. And I think it's still a fantastic language. And honestly, it has an infrastructure around it, which is kind of second to none. So I mean, it's, it's really fantastic in that way. No one is going to displace that in the short term.
However, I think he's right in that the rate of change has gone down a lot. And in software, you know, whenever the rate of change drops down to zero, then fundamentally it's, you know, you're dead, you just don't know it yet. And I think that's the state that we're not in yet, but we will be in fairly soon with Ruby. I think it's still got a decent life ahead of it. But I think other things are going to be rising up from underneath it and eventually taking it over.
How much longer do you think we have? Oh, I don't know. Between two years and 10 years. No, I think. No, good range. Yeah, I know. I mean, I think, okay, so here's the thing. You can never predict because if you look at Ruby, Ruby has been around since 94. We wrote the first pickaxe book in 2000 or 1999, 2000, something like that. And we could actually sort of track the growth of the Ruby community by looking at our book sales. And it was interesting. It accelerated slowly.
And so it was going up this very nice little ramp until like 2005 and Rails Kimball. And then suddenly the curve went through this kind of like straight up. It's like watching one of those fighter jets take off. It runs along three feet over the runway and then suddenly the guy pulls back on the stick and is at 10,000 feet. And that happened to Ruby when Rails came along. And who knows what is going to be the next magic thing, the next Rails that kicks this thing off.
And I don't know when that will be. But I do know that most people in 2004 would never ever imagine that it'd be writing enterprise level web systems in Ruby. In 2006, it was kind of like, that's what the cool kids were doing. So who knows? I mean, honestly, who knows? But unless you have the mind that's open to see these things and unless you put some groundwork in place, then the transition is going to be a hard one to spot and an even hard one to do.
So that's why I'm saying I think you owe it to yourself to keep an eye on these things and to just get familiar with them and get comfortable with them. Because at some point, some guy is going to put an ad up to say, hey, I'm looking for a functional programmer in New York City and you'll go, hey, I'm a functional programmer and you'll find yourself in a whole new world and it'd be really cool. Mm-hmm. And very valuable, too. Yeah, yeah.
We've got a few personal shout outs, too, since we're talking about codecadas and ways to practice. There's a website called Code Wars that I've done a little bit of a long time ago and I liked it and I know a lot of people really enjoy it. And it's a place that basically does codecadas and you can do them on your own, you can do them a few times, you can look and see how other people are doing. And it's, you know, they gamified a little bit.
There's a leadership board or a leader board, but it's a good way to get started with codecadas if you're looking for a good tool for that. Another one that I believe is much, much older is called Project Oiler and it has hundreds, maybe thousands, a little projects that you can do in really any language. And it's really nice, it's really good practice. A lot of it is more Matthew, but still really good way to practice learning a programming language.
And the third thing is the blog post that we didn't really get to, but we touched on a lot, which is by you, Dave, Agile is dead. So if you want to hear more thoughts on Agile and where it's going and where it's been and a lot of the points that Dave made, please read the blog post, it's really good and it's very thoughtful. If you want to support CodeNubi and what we're doing here, you can check out our Patreon page at patreon.com slash CodeNubi.
You could also join the conversation on CodeNubi Discourse or online forum for people excited about code or you can chat with us every week on the CodeNubi Twitter chat. Just search for a hashtag CodeNubi and tweet with us every Wednesday evening at 9 PM Eastern time. You can learn more about that as well as show notes on this episode at codenubi.org slash podcast. There's a topic you want to hear about or a guest you want to hear from send us an email helloitcodenubi.org.
Thank you Dave so much for joining us. You want to say goodbye? No, I would like to say oh wow, I'm going to do this again. I thoroughly enjoyed it. We would love to have you back. Yeah, I really appreciate the work that you personally are doing and I also really, really appreciate the courage of all the people around the country that are looking at a transition into coding with your encouragement.
I want to wish them all the best because I think it's a fantastic career to be in and you know, because it's a brave thing to do, but I think it will be well worth it. So congratulations to all of you. Yes, definitely. Thank you for listening. See you next week.