GeePaw Hill was a special guest. He is a coach, a programmer, an expert in Agile/XP/TDD and a thinker.
His Twitter: @GeePawHill
Transcript
[0:00 Yegor] Michael. Should I say GeePaw or I should Michael?
[0:03 GeePaw] It really is GeePaw. Thatâs not a.. you know, a stage name, thatâs what people call me. Itâs short for âgrandfatherâ. Depending on the counting I have between zero and eleven grandchildren. And thatâs not unusual when youâre 58, which I am now, but at the time I became a grandfather I was just 31âŠ
[0:27 Yegor] Wow.
[0:28 GeePaw] âŠand it was very unusual and it seemed very funny to people, so they started calling me Grandpa and then eventually GeePaw. And thatâs why Iâm called GeePaw.
[0:36 Yegor] Okay, itâs GeePaw.
[0:37 GeePaw] Yeah.
[0:38 Yegor] Thanks. Thanks for joining us. I already started recording, so letâs just say this is the new episode of the podcast, itâs called Shift-M, everybody thanks for listening, and we have a special guest, who just already introduced himself. But can you say a few more words about yourself, your professional background?
[0:57 GeePaw] Sure. I am a software a development coach. What I do is I go around and I work with teams of programmers down on the floor and up maybe two-three levels off of the floor and what I do is I just help them get strong. Iâm very sticked in the Agile tradition, before Agile there was a thing called extreme programming, and Iâm one of that first generation of early adopters of extreme programming. So I really started coaching almost 20 years ago, full time. And thatâs what I do. I visit teams all over North America, Europe, China and I live with them for a while. And in a living with them, we learn from each other, and hopefully we day and night both become a way stronger.
[1:54 Yegor] Uh-huh. Thanks a lot. I have a lot of questions about testing today, about quality assurance plus testing. We decided to pick that topic, right?
[2:03 GeePaw] Yes.
[2:04 Yegor] Because it seems like you write about that a lot and thatâs why weâve thought about that. So basically my first thing which I wanted to say, as far as you mentioned, youâre in this market for many-many years and we didnât have this test-driven development like up until recently, right? So itâs something new. So we had just⊠all we made was testing I believe.
[2:27 GeePaw] Yeah. Right.
[2:28 Yegor] So it was just testing, testing and then now itâs test-driven development, TDD. And what do you think, this TDD actually works or not? Because there are two opposite opinions.
[2:38 GeePaw] Right. So you mentioned that I talk a lot about TDD. One of the reasons I do talk about all the aspects of the Agile, one of the reasons why I talk so much about TDD is precisely because Iâve seen it to be so amazingly successful, both for me and for the teams that I work with. I just get so much bang for the buck using these techniques. There are parts of the Agile world that I like a lot, but Iâm less confident about. But with TDD I have almost complete confidence that it is the best way we know today to shoot more value faster.
[3:19 Yegor] So you really saw the situations where people write some tests first and then they right code?
[3:25 GeePaw] Oh yes, very much so, very much so.
[3:28 Yegor] And it happens when? When the project just starts or when the project already is in the middle?
[3:33 GeePaw] No. So, it can start at any time. But procedurally, sequentially kinda what happens is you tell me that you want to change the code in a certain way. And that could be from scratch, or it could be something what we were doing and what we wanna do is slightly differently. And what I do is I write a test that proves that the code doesnât work that way.
[4:03 Yegor] Uh-huh.
[4:04 GeePaw] And I donât write just any tests, not everything that I write, you know, not everything what we do is a test, is useful to us. But I write a certain kind of test. And that test establishes to our satisfaction that the code doesnât do what I want it to do. Then â I change the code until that test passes. And if thatâs not enough to get there, right? Then I write another test and so Iâm canceling this sequence of test-code-test-code-test-code-test-code, where each test is quite small and each code change is quite small. And thatâs sort of a general way this scheme works. Now testing first vs testing after. Well youâll meet a lot of people who are very religious about their beliefs in this matter. My experience is that itâs almost impossible to not write a little more code than you have test for.
[5:11 Yegor] Exactly.
[5:12 GeePaw] What we should do is effectively putting or creating a sort of a hole in your test capability. But what the TDD does, even though we call it overcoding, right? Even though we still do overcoding just like everybody does, we immediately go back and write the test as quickly as we possibly can. This only works because the tests weâre writing are small, and fast, and easy to read, and write, and debug. If they werenât, then the expense of writing a test will just drag us down and kill us.
[5:50 Yegor] Uh-huh. It seems that weâre on the same page, because I am a programmer myself and every time I start some new project and there is nothing in there, so there is no code, technically I can not write a lot of test, write any test, so I have to create some code, you know, when a project is completely empty from scratch then it seems, it looks, it happens that I first create some architecture, some skeleton, and then on top of that I can start adding this test and then it goes into test-code-test-code and all as you just mentioned.
[6:21 GeePaw] Yes, very often at the beginning, you know, I just donât know enough, right? I donât know enough to even know what test will look like.
[6:32 Yegor] Exactly.
[6:33 GeePaw] But, we call it the steering promise, and what just steering promise is these tests and testability are, have to be first-class citizens from the very moment when you start to sketch your design. So I never think to myself: âHow am I ever gonna do thisâ without also thinking âHow am I gonna do this in such a fashion that I can reliably, rapidly, easily test that it works.â Those two questions go together because theyâre both first-class citizens.
[7:07 Yegor] So you start coding and you think upfront how you will test it later so you kind of code for tests?
[7:14 GeePaw] Right. Absolutely. Absolutely. The idea is that the test and testability actively steer our design. And we change our design. We change our code just so it will be easier to test.
[7:27 Yegor] And you think itâs right to think that way?
[7:30 GeePaw] Yes. Yes. When you first look at it, it feels like âOh my gosh, Iâm not gonna be coding twice as muchâ because you know you think âwell the tests are code tooâ, right? But it actually works because that extra little trunk of coding dramatically reduces the amount of time we spend on activities that weâre not coding. Like running the debugger, or waiting around for disturber to fire up, or waiting for the remote device to boot up â all those things are things that I donât do when Iâm doing TDD. Because I wrote the tests so that I wouldnât have to do that.
[8:15 Yegor] Uh-huh. You know what? I agree, but many people keep telling me that our customers donât pay us to write tests. We donât have the budget for that. Sounds like a good technology blah blah blah, weâve heard all these seminars, we read the books, but⊠Sorry.
[8:35 GeePaw] Dude, itâs just you, you just hit me with the most awesome softballs, let me blow this right out of the park. [laughing] TDD is the best⊠okay, this is the money promise. We moved on from the steering promise to the money promise. Weâre in this for the money. When we write software for living, when we make software, money comes from shipping more value faster. Now, more value could be more function, right, more features in the program. But it could also be a higher level of performance, it could also be greater degree of stability. TDD does not concern itself with defining values. That is somebody elseâs jobs, right? Thatâs the company. Thatâs the companyâs job to decide whatâs value. TDD says if getting to that value involves working with branchy logic in code, then TDD will actually get to that value faster. And again, I know that this is kind of intuitive, thatâs why TDD is often treated like itâs some kind of weird revolution. Itâs not. Itâs actually continuation of last 50 years of us getting better in writing codes. But it does feel like that because it is based on a couple of very non-intuitive results. And one of them is precisely that if you want more functions, then all you want in your life is more stuff on your screen, thatâs doing more stuff for your customer. TDD will get there faster.
[10:17 Yegor] Okay, you understand that, I understand that. Let me give you a practical example. I was working as a soft-reconsulter a few years ago in one company and I had a task of implementing something which was quite difficult to do without the thing you just mentioned, like bootstrapping some device or whatever. So it look like some extra effort to test my stuff. So I started to write a test. I started to write some⊠not a framer, but some you know, some sky folding around my code in order to simplify my coding. And then my manager asked me next morning because it took time like a few days, so he came to me next morning and said âWhat are you doing right nowâ and I said âlook, Iâm writing these tests sky folding, like test tools in order to simplify my workâ, and he said âno-no-no, you donât do that, we need the features, we donât need you to write the test. We need the features, so youâre kind of wasting time. Weâre not paying you to write test, weâre paying you to deliver the codeâ. And what would you do in that case? How to explainâŠ
[11:19 GeePaw] So, of course we see this all the time, right? Thatâs not a surprise that that happens. But hereâs a thing. You know, it depends on your manager of course, and it depends on your organization you work with, but generally speaking, you know, they donât actually know what we do and they donât know how to do it best. So I donât let managers tell me where to put semicolons, I donât let managers tell me what is the fastest possible way to type.
[11:55 Yegor] Uh-huh.
[11:57 GeePaw] I happen to know where to put semicolons already, in fact, Iâm paid to know where to put semicolons, Iâm paid to be a capable typist, I know how to do those things. I basically, if you ask me, if I was writing TDD-style test, even if I was investing, I had a time a little bit, although I donât wanna go overboard here, weâll come back to that. Even if Iâm investing a little bit in getting testing capability up and running for the first time, those thing are, you know, thatâs like asking me âWhat are you doing?â while Iâm changing my editor, âWe donât pay you to change your editorâ as in fact I do have to change my editor because until my editor changes, I canât shift your functions. And thatâs the true response. Itâs one of the great mists of this business, that developers have no power. But honestly, I travel all over the world, I go to a lot of shops, I donât know if youâve ever seen this, but ever I wander around the room and notice that no one is actually working, they are all surfing cat pictures, or working crossword puzzles or doing what appears to be writing code until you look closely and you realize that theyâre actually working on their personal bug. Iâve seen all of those things happen.
[13:25 Yegor] Yeah, what do you think?
[13:28 GeePaw] How do they get away with that? Well they get away with that because the guy two levels above you in the organization has no idea what you do for a living.
[13:38 Yegor] Yeah, true.
[13:39 GeePaw] They canât tell. They see you typing, you look busy â great. The come to you and say: âwhat are you doing right now?â And you say: âIâm adding this functionalityâ, I donât say: âIâm adding semicolons or changing the editor, or building a test frameworkâ, I say: âIâm adding this functionalityâ. And because TDD works, that is because it actually does let you ship more value faster. Theyâre never blanche, theyâre fine. Theyâre great. Theyâre happy to see you working. Just like if I change my editor to make my hot keys the way I like them, I go faster that way too.
[14:13 Yegor] Thatâs true, but you know in my case it wasnât exactly a manager, it was like a tech lead, so that guy was a programmer as well, so he knew exactly what I was typing and he knew exactly, you know, how code works. So his point was that âMaybe weâll move into another premise, like you said, from money to time premiseâ. So he said the more like âwe understand the value of unit testing, I know what unit testing is for, but look, we need to finish this project and we care about the time to market, so we need to deliver to the market. What you are doing right now â youâre building something for the far-far future, when, you know, of course unit testing will of course help us, but sometime in the future, we now need the features, so stop doing that or just implement it.â That was his plan.
[14:56 GeePaw] Right.
[14:59 Yegor] What do you think about that? How can I answer, that is my question. âŠHello?
[15:15 GeePaw] Hey, are you still there?
[15:17 Yegor] Yeah, Iâm here. Sorry. Yeah.
[15:18 GeePaw] Okay, we popped off for a second, sorry about that.
[15:22 Yegor] Uh-huh. Okay. Go ahead.
[15:24 GeePaw] So thatâs a great question. And it really strikes what I was getting up before about how much do I invest in the future. I do not normally write. So let me get you an example of this. If I had uhm⊠What kind of work do you mostly do? Is it remote device work, or is it a firmware, or is it webware?
[15:46 Yegor] Web. Web.
[15:48 GeePaw] Webware. So in a webware environment I could write a Selenium test. I try to drive the application by controlling the browser. Those tests are extremely expensive to write.
[16:05 Yegor] Yeah.
[16:06 GeePaw] And they give me very little value. And if my lead said to me âI donât want you writing those tests because they donât pay offâ I would say.. well itâs not that they donât pay off, let me put it in another way. They donât pay off fast enough.
[16:23 Yegor] Uh-huh.
[16:24 GeePaw] Right? Thatâs the real problem. The problem isnât a question of whether they pay the guy acknowledges that they can pay. He says: âI need to pay back faster than that technique can give me.â I happen to agree with him. I donât write that kinda test. The tests I write are called micro tests, theyâre very small, theyâre very fast, and theyâre very easy to write, and run, and debug. And that is why the pay back actually works. Now, ultimately, of course, in any shop, there are house rules. And we canât do anything about set of house rules except âchange the rules or change the shopâ. But⊠I mean you know, right, thatâs an old Martin Fowler line. He said âChange your organization or change your organization.â [laughing] It gives you two choices. Uhm. And thatâs a reality. And I accept that thatâs a real rule but the case for the kind of testing that I do is not about slowing me down.
[17:34 Yegor] Uh-huh.
[17:35 GeePaw] Weâve stumbled into yet another premise, which is the correlation premise. The correlation premise says âInternal quality and productivity are directly positively related.â When internal quality goes up, productivity goes up. When internal quality goes down, productivity goes down. So the first distinction there is you have to make that distinction between internal and external quality. Itâs pretty easy to understand. External quality is anything your user can tell. Anything that user could say about your program â thatâs external quality. They could say itâs fast, or itâs slow, itâs pretty, or itâs ugly, itâs always up and running or itâs spotty around 3 oâclock in the morning or whatever, right? Anything that they can observe â thatâs external quality. And internal quality is anything you canât tell without access to the source code. So giving the distinction between the IQ (internal quality) and EQ (external quality), you cannot trade internal quality for productivity. And thatâs confusing because you can change trade away external quality, right? If you donât care whether the screen is ugly, I can get there faster. If you donât care whether it runs in a fraction of a second or a couple of seconds, I can get there faster. I can trade away all the things that users value and can observe about our program in order to get to market faster. What I canât trade away is the internal quality and layout of the code. And TDD is based around shaping the code internally so that it has optimal internal quality. I mean we call it TDD, and we talk about it like itâs only testing, but really what it is is the modern synthesis. Itâs test driving, itâs merciless refactoring, itâs lots and lots of different things including continuous integration and things like that. It isnât just one technique, itâs a bunch of related techniques.
[19:58 Yegor] Uh-huh.
[19:59 GeePaw] And what theyâre about is this. If we wrote down this big complicated production function, that was going to describe what you do today on your job. Right? Think about the different terms that would be in that huge massive polynomial. The three biggest terms are: 1) how complex is the domain. Right? What kind of problem are you trying to solve; 2) how good are you. Realistically, how good are you; and 3) where did you start. That third term is the easiest of those terms to change. Right? Itâs really hard, I canât change the domain. If they have twisted bizarre business logic - then thereâs nothing we can do about that, thatâs what they have. Your individual skill or my individual skillâwell they do go up, but they go up and down slowly. But the starting point, the third most important term, why is that so important? Well, because all programming is changing code. You ever noticed that, you know, your first day of work on a new greenfield project - oi, zipzipzipzip [21:23] - youâre moving so fast. Why is that? Itâs cause youâre not chan~, youâre changing air. Cause thereâs no code there to change. You donât have to ever make changes against an existing code base. But thatâs the first day. On the second day thereâs already code there. And the changes that I make to my code on the second day, the speed with which I can make those changes depends on how good and strong internally the code was on the first day. And thatâs the correlation premise, it saysâyou canât trade productivity for internal quality. The less internal quality you have, the slower you go, not the fasterâthe slower you go.
[22:14 Yegor] I totally agree about that, but let me ask you the next question, so it seems that you are putting the equal sign between the existence of unit test or any test, and the quality of codes. But there are many people saying and in my experience just the presence of tests doesnât mean that the quality of code goes up, because itâs so easy to write bad tests. Itâs so easy to write tests which donât actually help anyhow, but they actually make the code even more messy, because they are wrong tests, there are so many people, we heard about that, like so many anti-patterns for unit tests which will give you a lot of false positive signals and all that kind of things. So what do you think about that? So is it an equal sign between an existence of test and the quality of code.
[23:06 GeePaw] So⊠so, and you can quote me on this. Oh good god yes. [laughing] Yes, of course. Uhm⊠One of the problems with this movement, and I am a very harsh critic of a very own movement. Youâll hear me out there raising hell all the time. But we tend to⊠we oversimplify, and we sloganize things that can not be successfully simplified, and successfully turned into little mottoes. So you know thereâs earlier that I said that all tests are not created equal. Some tests are better than others. TDD isnât start today writing a test before you change any code, kind of thing. I canât give you a sentence that says what the modern synthesis is. âCause the modern synthesis is a bunch of things. And you can, and I have seen it, you can do horrible damage to yourself by starting off with the naĂŻve interpretation of that language and by⊠like I donât know what can I tell you, itâs like⊠sometimes people watch too much internet. And you hear me, you can hear me, right, you can hear that Iâm really enthusiastic about this, I believe in this technique, I use it all the time, I use it for my own night coding, I use it in my daytime projects, I teach it to people, I share it everywhere I go. But it doesnât fit in a sentence like âYou always have to write testsâ. What we done is weâve hit⊠Gosh! Weâve covered three already, weâre hitting the fourth premise, the fourth premise is the judgment premise. In programming there are no algorithms for writing code. Right? There just is not an algorithm you can use to write code. You know, just a second, I have to relocate, Iâve got a sudden noise in my bathroom.
[25:25 Yegor] No, I donât hear it.
[25:26 GeePaw] Uh, okay, okay, good. Good to know. Alright. So, there is no prebuilt algorithm that tell you what to type. And thatâs a good thing because, you know, the day after they invent an algorithm telling us what to type weâll all be out of the job and a week after that we will be hiding in the rubble from the Skynet. Because that is not actually problem that we wish to solve, and seemingly by all standards of theory nowadays itâs not a problem that itâs just possible to solve, there will never be an algorithm for doing what we do. So what does that mean? That means that as a model for writing code TDD is permanently, unavoidably, irremediably, and happily dependent on individual humans using their individual judgment. There are many-many possible tests I never write.
[26:44 Yegor] Uh-huh.
[26:45 GeePaw] I donât write them because they donât pay me back. Or sometimes I donât write them because they pay me not quick enough. The tests I write have to be cheap to write, they have to be fast, they have to be easy to read, easy to write, easy to debug. If theyâre not â thereâs no payback. Well, how do I get there? judgment. I have to use my judgment. I never write a test that says âIf I have a method called getx() whose body is return x believe me, I donât ever write a test for getbacks, forget that.
[27:28 Yegor] Yeah.
[27:29 GeePaw] If I had a method So youâre in a web world, we have some sort of html, http transport mechanism. You know Oracle, right? Maybe youâre using Spring boot, maybe youâre not even in Java, youâre in some other app, and have this framework. You never test that framework. Using an automated test. You know, yeah, because you know what? It works. Oracle works. I donât write tests to see whether itâs equal actually..
[28:01 Yegor] ..is up to date.
[28:03 GeePaw] Occasionally, of course, in real life, occasionally I will write a query that is sophisticated and complex enough as to rattle me. Where isnât just select * from table. But generally speaking, I donât waste time on tests like that. Because the money premise, it doesnât help me ship value faster to write those tests, so I donât write them. A big thing that has to be said over and over and over again, again about this isâno oneâs asking you to leave your brain at the door.
[28:40 Yegor] Uh-huh.
[28:42 GeePaw] Iâm sorry that it sounds like that. And If you go out on the internet, youâll see there plenty of people who seem to be saying that, but theyâre simply not understanding it themselves. Thatâs the problem when something new and exciting happens, a lot of people jump in. Itâs very attractive to make statements and say âalwaysâ and âneverâ, and itâs very attractive to write simple little mottos that supposedly capture your whole world but thatâs not real programming. And it has never been real programming. Real programming for money is about shipping more value faster, and we will use any available technique that will let us ship more value faster. TDD is one of those techniques and thatâs why I use it.
[29:30 Yegor] Okay. I agree. Imagine youâre a manager of a group of programmers, and they donât write tests. So how would you motivate them or punish them, or what would you do to change the situation, to make sure that the code starts getting the tests? Because they donât write, I mean theyâve never done that, they donât want to do that, they donât share your values for example, but you have to somehow change this situation. What would you do?
[30:00 GeePaw] How do you get them to learn CSS?
[30:09 Yegor] Uhm⊠They just have to learn, otherwise their page doesnât look good.
[30:12 GeePaw] Huh! SoâŠ[laughing]
[30:16 Yegor] [laughing] I believe.
[30:18 GeePaw] How do we get them to learn where to put the semicolons? we got them to learn that because that is the job.
[30:25 Yegor] Yeah, itâs not gonna compile without the semicolon, but without unit test, they can perfectly implement the feature and return back the pull request to you, which will have the implementation of the feature, a number of classes, new classes they just wrote and zero unit tests. And they will say: âLook, my code works, and you are the manager, youâre the tech lead, youâre the architect, so now itâs your callâ. What do you do?
[30:44 GeePaw] I say âOkay, cool, letâs see the testsâ and they will say âWe donât have any tests. Mike, so youâre saying..â [laughing] â..It works.â
[30:57 Yegor] Uh-huh. Yeah, and he will say âOf course on my computer, come over Iâll show youâ
[31:00 GeePaw] [laughing] Exactly!
[31:01 Yegor] ââŠlet me run it for you, you will see, it works, lookâ
[31:05 GeePaw] Say âI donât have time for that, I work for living too, you know, I donât have time to follow you around and watch your screenâ. And furthermore, a far more important leaving that question is this question: âIt works on your screen, does it work on the production? It works right now, is it gonna work two months from now?â A lot of developers think of software as something that gets done. The softwareâs done. And now that itâs done, since it runs, we will never change it. Thatâs a joke. The day that we stop changing the code that we write is the day that we put software away. We pull the plug on this application and we no longer support it and run it. Thatâs the day we stop changing it. So weâre in continuous state, the job of being the developer is developing, is not âdoneingâ, itâs the daily changing of code. And as soon as I introduce change into that situation with any kinda complex logic, when I say complex I donât mean rocket science. I mean two nested IFs. That is when the microtests pay back. Now, am I gonna be able to convince everybody of this on the planet? No, because⊠and Iâll tell you what, because arguments are arguments, right? Listen, Iâm a professional talker, Iâm good at talk and I can make anything sound good. You want some fried okra - oh, itâs really good, yeah girl, youâre gonna love fried okra! [laughing] Okay? And the world is full of people who talk really well. As a coach, I do a little bit of talking, no question that, but really my big mission as a coach is actually to get it under your fingertips at the keyboard. It is to get you to actually have the experience. Because hereâs a thing: once you actually experience it - eh, all my words are nothing, pish-pish - youâll be like âHaha, thatâs really cool, I do this much-much faster. I found 13 bugs in this thing I thought I was done with. And I know that nobody will be able to change this file from here on out, and break our application without first breaking our microtests. And thatâs the real beauty of this system. Because we are in a perpetual state of change, thatâs all we do is change code for a living.
[33:51 Yegor] Uh-huh. You know what weâve done a few times in our projects is we had tools to control code coverage. You definitely know what it is. And we were telling new programmers who were coming the project, we were telling them that in our project the coverage threshold is 60%, so when you implement something, you have to return back your pull request with no matter what changes you do, but you technically cannot drop the coverage below 60%, because in that case our continuous integration, continuous delivery system will just reject your change, it will not be merged.
[34:28 GeePaw] Right, same as if it didnât compile.
[34:30 Yegor] For example, yeah, exactly. So what do you think about this approach?
[34:34 GeePaw] So, two questions. One is the question of number, what number should that number be.
[34:43 Yegor] Just arbitrary - fifty or sixty percent.
[34:44 GeePaw] Right, and another one is⊠another very serious one is the question of⊠how do I put it, well⊠if my code that I just am adding has branches in it, I know with certainty that I will develop that code faster if I use those tests. So I donât actually myself need a standard, right, I donât need a rule. And itâs just⊠thatâs what programming is, itâs going as fast as you can, and making changes to code. So I wouldnât need that rule. Going back to number, you know, I hear a lot of numbers, though I think you already understand this, and probably your team did too. You know, the number, eh, itâs just a number, and itâs an easily gained number, right?
[35:42 Yegor] Yeah. Uh-huh.
[35:43 GeePaw] I can easily generate coverage with tests that actually donât test much of anything. So and yet the spirit of all we are talking about which is to say the code that goes into our code base that has to be our best code. That spirit is the spirit I love and value greatly. I work in shops that have rules ranging from 60 to 90, Iâm actually⊠Iâve just come away from a shop, I worked there for about 6 weeks with a very large code base in Pearl and their standard number is 70, right? And we have this expression, I donât know if youâre familiar with this English expression, itâs âhonored in the breachâ.
[36:28 Yegor] No, Iâve never heard it.
[36:29 GeePaw] What it means is âwell thatâs a rule we never pay attention to our user following anywayâ.
[36:35 Yegor] Okay. [laughing]
[36:36 GeePaw] We only honor it by breaking it. Thatâs the only way we honor that rule, we break it all the time. And there was a situation in this shop. Programmers felt that the way that they were working was such that⊠It was virtually impossible to achieve that number. It was impossible. And they were right. They were right, in a way they were working they would never have hit that number in a million years. And what we had to do, we showed them⊠I simultaneously actually taught them how to get better coverage, that was actually the correct coverage, the coverage we needed. And at the same time I gave them permission to blow that number away, forget that number. And in order to do that of course there was a lot of practical hands-on in the code. If we change the code this way, youâll be able to right that test in 5 minutes and get perfect coverage of that complex piece of logic. If we leave the code the way it is, youâll never be able to test that in a million years at any kind of speed that would make you faster. You know, it would double, or triple, or quadruple the amount of time you spend adding a new function.
[37:57 Yegor] Uh-huh. So it seems that youâre saying that itâs more about the question of motivation instead of punishment, so instead of rejecting the code and saying that âYou just broke our rule, so go back do your homeworkâ, instead youâre just trusting people and letting them decide what is best for this particular case, right?
[38:14 GeePaw] Yeah, in our shop we have a culture, and the culture has certain expectations: you donât come to work just wearing your underwear, you⊠[laughing] Thatâs a very important rule, itâs not written down anywhere. Well then how come everybody doesnât just come and wear underwear all the time? The reason is thatâs not how we do things here. And the same thing is true of most of the TDD practices. I donât find that making the rules is particular, I mean it can be used for doing transition, but ultimately it isnât about the rules, itâs about us building the culture, in which this is how we live. There are rules or conventions, that are more common in terms of coding standard than the no-underwear rule. But like for instance⊠oh, whatâs an example⊠if I see somebody passing around more than 3 arguments to a method, Iâm gonna say to them: âHey, yo, what are you doing? You got 9 arguments here, this is a smell, this is a problemâ. And Iâm gonna say that not as a boss, or as a rule maker, Iâm gonna say that as a guy sitting next to you whoâs gonna have to work with that code tomorrow. And we build culture that way. Without any rules at all, we just build it cause weâre just humans, thatâs what humans do.
[39:49 Yegor] I think you believe in code ownership?
[39:53 GeePaw] I believe in⊠Well I believe in collective ownership.
[39:59 Yegor] So they have to feel like owners of code, right? So they want to see the code good, they want to just write something and walk away and never touch it again, right?
[40:07 GeePaw] Sure. Sure. And not because theyâre.. yes. But now with a moralistic overtone rather simply recognize the reality of the business. The reality of the business is that there is no walking away. You donât get to walk away unless youâre walking away from the organisation.
[40:23 Yegor] But you know what? The statistics tell us and thereâs recent research done by Stack Overflow, for example, they say that programmers change their jobs approximately every year, so it means that this code ownership will not last for longer, for too long, it will be just 1 year, so it means that next year I will join some company which already has a code base. And when I join it, I realize, perfectly realize that I will stay with this code base for approximately 12 months. So I donât really attach myself to the code base, Iâm kind of more like this cowboy mode, you know, I just write something, you kind of pay me for it, you appreciate my contribution, but eventually and quite soon, I will just walk away. So, you see the contradiction?
[41:07 GeePaw] Absolutely I do. Itâs a very perverse market, isnât it? You know Bob Martin, his back-of-the-envelope version of the development of software programming has made it pretty clear that, you know, the doubling rate for the number of programmers in the world for the last 35 years is just 5 years. Which means at any given time half of all the developers in the world have less than 5 years experience in the field. Iâm an old man, Iâve been a computer geek since I was 20, so Iâve been a computer geek for 38 years, which makes me something like 0,7%. Hey, I finally made it to the one-percenters! I wish I were in the one-percenters economically, Iâm not. But I am in the one-percenters geekfully. BecauseâŠ
[42:04 Yegor] According to my point, you can not judge everybody else by yourself because youâre an exception more like, youâre not like just a⊠you know, youâre not like everybody else.
[42:12 GeePaw] Insatiable demand for software has created a lot of very strange aspects, letâs mark it, and one of them is job jumping. Now, Iâm not a job jumper, because my job just doesnât work that way. I never, I never, not for the last 20 years have I stayed with the same organisation on a full-time basis longer that a couple months.
[42:41 Yegor] You see? [laughing]
[42:43 GeePaw] But thatâs because Iâm a coach, and Iâm not a programmer, right? I mean I am a programmer, obviously Iâm a geek, but my job requires me to move from place to place, from team to team, from code base to code base. So what if we ultimately come down, it is not my sense of responsibility to the company, it is my desire to add more value faster. Because when I add more value faster, I get more love from my colleagues, I get more money from my organisation. And I know thatâs a pretty mercenary way to think of it, but so is job jumping every year, and after all you know, thereâs a reason why people change jobs every year. They change jobs every year because they have no loyalty to their organisation because their organisation has no loyalty to them. And you know without that mutual loyalty, weâre stuck in that mercenary situation. As a mercenary, what I wanna do is to get in, get the job done as quickly as possible and get on to the next job. When I say job, really I mean task. Get in, get this task done as quickly as possible and move on the next task. So I wanna be really careful to say that thereâs zero for me, there are zero moral overtones here. I am not expecting that if your TDD or you must have some sense of responsibility thatâs higher than anybody elseâs. Personally I think that is crap. I have no higher responsibility, of course, no, Iâm a geek, I love to create code, if I didnât, I wouldnât be in this business. But thatâs between me and the code, that has nothing to do about the people I work for. The people I work for want all sorts of things I donât actually - by a long range - very often donât approve of. But if you want it to get done faster, then the way to make the code faster is to make that code in a certain way. And nobody hesitates or poses when weâre talk about the difference between using a line editor to write HTML versus using a tool that actually shows you wysiwyg, what you see is what you get, results as youâre typing in your HTML, in your CSS. Nobody argues about that because it is obviously faster. But there are other techniques that are also faster. Some of them are less obvious, some of them are more obvious. People get on these techniques not because of some moral value that they hold about responsibility for code ownership, they get on these techniques because it makes them faster.
[45:32 Yegor] Yeah, exactly, but very few people right now realize that it makes it faster. Thatâs my point. So, in this aggressive market when everybody⊠we know, this is reality. Of course, you donât like it, I donât like it as well, but people change jobs, theyâre job hoppers as you said. So, this is aggressive market. And we know that people will come and go, and can we really trust their internal desire to write tests in a right way, or we need some punishment flash control mechanisms, no matter how bad it sounds, but maybe we need to somehow force them to write tests to make sure they do that, instead of just relying on their, you know, good will.
[46:11 GeePaw] Well, so, so, again, I donât actually hold a moralistic view point about whether we punish or reward, right? For me thatâs not about morality, thatâs about effectiveness. The question is does it work. If it works, and you get new hires, do it. If it doesnât work, and you donât get new hires, donât do it. And the problem with most of these control schemes is that theyâre not very effective. And they actually slow down your more talented people, while not speeding up your less talented people. So, anyway, I certainly understand the contradiction, right? And how hard it is to make a judgment about what level of culture do I provide, what level of structure do I provide, what set of rules do I provide. Those are really complicated problems, and I donât pass judgment on anybody whoâs trying to come up with this scheme. Iâm just saying that we have a tendency to believe that only one scheme works, but there are lots of organisations, that write successful software, they donât have anything by way of rules, except what the team imposes on itself.
[47:31 Yegor] Uh-huh. Let me give you an example. A practical one, which happened to me as well a few years ago. We had a project which was a product actually, which was on the market for like 5 years or so, so it was a pretty big code base and absolutely zero tests. So it was⊠Itâs quite typical situation: itâs on the market, it works, people use it, thereâs a huge traffic, but zero tests. And we started to introduce this culture of tests. We started to say, I was the architect, and I was saying âHey, we need to write tests, letâs stop we were doing before, and everytime we change something in the code base, we need to bring in the tests as wellâ. And very soon a few programmers came to me, and we sat together, and they said âHow about we spend some time, like a month, to cover the code we have now with tests? Before we can actually start doing this TDD, and start, you know, introducing.. and start adding tests with every pull request we need to do some work and prepare our code base for that new mentality. So letâs just spend the whole month of doing nothing, no features, no bug fixes, nothing, just writing tests, just covering the code base with tests.â And we did that. What do you think of this approach? Is it a good move orâŠ
[48:49 GeePaw] So, a month is right there in a range of âmight be a good move, might not beâ. Anything longer than a month - I would say âHell noâ, right? Weâre on this for money, we make money by shipping more value, if I am doing anything that pauses production, then Iâm not adding more value. Now, that doesnât mean I can never invest in the future, but it does mean that when you talk about me not adding new value for a month, you better be sure that in the end of that month Iâm gonna be significantly faster. Now, that does not mean that I wonât spend a few days here and a few days there. You know, adding testing capability where there was no testing capability before, in fact I do that all the time. One of the things that happens when you get to be an old TDD-er like me is you begin to get better and better at incremental and iterative development, where you donât⊠Well, the code I write is never done. I am constantly making small changes inside my codebase. And the more you get good of that, the more you start seeing ways in which you can take just these 87 lines, no more than that. Take them out of this untestable situation, put them in this testable situation, and still finish that feature faster than the guy sitting next to you whoâs trying to run and work with the code in an untestable situation. I know that that seems strange, but itâs true, right? Um, we get better, people get better with doing things and if you get better at learning how to make change in small steps, then you donât have to pause production. You can make those changes even while you produce code. Trade off, well, I think a month is the longest I would even let a team not ship.
[50:59 Yegor] Uh-huh. Yeah, it was a month. I remembered exactly that number, it was a month. And the team was quite big, like 15 people. So it was like 15 people sitting there doing nothing, just writing tests.
[51:12 GeePaw] So, tell me, did it work? I mean, did you feel good, when you got done?
[51:17 Yegor] Yeah, well, the only thing we definitely achieved is that we trained people to write tests.
[51:20 GeePaw] Right.
[51:21 Yegor] Because before, you know, thatâs my understanding that people, like you said actually, people donât write tests not because testing is bad, but because they donât know how. So we need to train them, to give them the instruments, like with the new tools for making HTML, let me give you an example. Of course if you donât know how to use that tool, youâre gonna use the plain text editor. When you learn the tools, you become more, you know, professional with the tool, then you have a choice at least, you can use it. The same for testing, itâs my experience, so when people are like fresh, they look at these TDD books, they read them, they listen to the seminars, and then they say: âOkay, that sounds good, let me get back to workâ and they do that. They just donât know how, they donât have the experience, so that was really good for us and a very good opportunity to like buy time and use that time to train people. I remember the problem with actually buying that time, we had a long discussion for a few months with the management, because like you said, itâs a pause on production development, on delivery. So we stopped the whole work, so we actually got a go-ahead from the higher level of the organisation, like the CTO, actually approved that and said: âOkay, you guys have this month of work, I will protect you from all other parts of organisation, and let you do that.â So we got the training, thatâs my experience in that.
[52:37 GeePaw] So that is⊠That sounds to me like a tremendous win, actually. Once again, right, weâre confronting the fact that the demand for the services is insatiable, and you know this idea that weâre doubling every five years, that indicates you just how much these people want software, they want it so bad. And it just creates this marker where.. Well I donât what your experience is but most of the teams that I visit are 4 of people who donât really know how to program very well. And I donât mean it in that nasty way, itâs not their fault, they didnât get any training, they donât get any support, they learn on their job, and itâs like you go in the army and on the first day they send you out and they show you which.. you know, âThis is the end of the stick you point at the bad guys, now go over that wall and kill some bad guys.â And itâs like âWow, that doesnât work very wellâ.But the demand is so high that it works well enough that we keep doing it, we keep not building the skill sets and the cultures that we need to actually be able to ship more value with fewer people in shorter time. So itâs awesome that your team did that, I think thatâs great, and a thing I would say to everybody whoâs listening here, well, really two things. Thing number one is if it does not actually work, donât do it. It has to actually work. It has just not to work on paper. It has to actually work. And if it doesnât actually work, donât do it. Thatâs the first thing. And the second thing is you cannot ignore the need to teach your people how to work this way. This is not something that you can pick up by watching a single episode of Joe Rainsbergerâs TDD training or one of my videos. It doesnât come in a video, it doesnât come in 5 minutes, it isnât something that you can learn over lunch time and then apply when you get back from lunch. It takes effort. And as long as companies refuse to support us in building our skillset, theyâre not gonna get more value. Theyâre just not. So itâs really, itâs great story that you told me, because it sounds like youâre able to convince somebody important enough, somebody with enough weight to say⊠actually these guys need this and Iâm gonna give it to them.
[55:25 Yegor] Yeah, it was like that. What do you think about⊠well you said that computers will not write codes for us ever, but, you know, there are so many tools which actually write unit tests for us.
[55:35 GeePaw] Yeah.
[55:36 Yegor] So you just give it the class, you give it a method of a class and it just generates you a whole lot of tests. What do you think about this approach?
[55:47 GeePaw] Back in the day, there was a tool called Yacc. Yet another compiler-compiler. And Yacc would take an LALR grammar for programming and it would turn that grammar into the actual code. That would implement that grammar for you. And then you would go in and flash out that code. So itâs sort of, as kind of parser for programming languages. And everything was brilliant as long as⊠youâd never actually had to touch your code to change it in any way. Because computers suck at writing code. Because the hard part in writing code isnât the part where you get the computer to do the thing, a hard part of writing code is a part where you get the code in such a fashion that you or I, or anyone else in our team can come along and maintain, and develop, and enhance that code as we go. Thatâs the hard part. And thatâs a human thing, not a computer thing. I donât trust those apps and I donât use them. Most of tests they write are slow, most of them are difficult to understand what theyâre doing, they tend to have very long setups, which make it very hard to see whatâs going on. Now, you know, I donât know if this has ever happened to you yet, but Iâve been wrong. And I may yet be wrong. Somebody may in fact be able to show me someday, a thing that can do that automatedly better than I can do it as a human. So I could be wrong, I will say this, Iâm not wrong about to_date. Today they have not solved that problem, no matter how good their website looks, they have not solved that problem.
[57:45 Yegor] Uh-huh. Okay, and now comes my final philosophical question.
[57:53 GeePaw] Cool.
[57:54 Yegor] When the code breaks in the production, when the products breaks, when we lose money, when we lose customers, when something happens, we come back and realize that itâs because of the bug in the code. That something doesnât work or something is broken here, and then the question is: do we blame the programmer for that, because itâs obviously a mistake of a programmer who didnât write the tests, or who didnât test it properly, I mean who didnât create the automated tests. Or do we blame the tester who missed that thing on the way to go. Or who do we blame, or we donât blame anybody?
[58:27 GeePaw] So, in general, I donât blame anybody and itâs again, itâs because of the perverse market. I canât blame you for writing a non-tested line of code. When nobodyâs ever shown you how to do this, right?
[58:41 Yegor] Uh-huh.
[58:43 GeePaw] It would be like, you know, thereâs a reason why you have to go to school in order to learn how to build bridges. Building bridges is actually rather difficult. And it takes practice, and you have to do it in apprenticeship, and you have to spend time in a field with guys who are building bridges, to learn how to build bridges. And we donât do that very well in our industry. And Iâm not talking here about the certification or college, I am talking about teaching, we donât teach, we donât teach our developers how to be good. And as a resultâwhen theyâre not good, what are you going to do, are you going to yell at them? âOh, youâre not good because you never did this thing that I never taught you how to do.â Well ainât that right? [laughing] If you want me to do that, youâre gonna have to teach me how to do it, cause people are not born knowing how to write tests. SoâŠ
[59:38 Yegor] Is it the fault in the programmer, when something breaks in the production?
[59:41 GeePaw] No, in general, I take the sort of modern systems approach. Virtually, all the problems that we encounter, not all, but most of problems that we encounter in our systems are problems with the systems, there are not problems with the people.
[1:00:00 Yegor] Thatâs a good one, huh.
[1:00:04 GeePaw] Most of them, you know, people forget this, because we all get involved in our attitudes about the world. You know what, in the most of times people want to do well. They would like to do the right thing, they would like to succeed, they would like to win, they would like to be stronger, and better, and faster. All we have to do is cash in on that. All we have to do is take advantage of their natural desire to do that. And then weâll get better.
[1:00:31 Yegor] Sounds awesome, to be honest. [laughing]
[1:00:33 GeePaw] Haha!
[1:00:34 Yegor] Okay, I like it, thanks for⊠I think weâre running out of time, so thank you very much for joining us and being with me today. Uh⊠thatâs it?
[1:00:44 GeePaw] Okay, I absolutely enjoyed and I hope you downstream had a good time and you can always find me, Iâm GeePaw Hill, itâs G-e-e-P-a-w-H-i-l-l. Thatâs my hand-on Twitter, thatâs my e-mail address: geepawhill@geepawhill.org If you have questions or comments, that come from the podcast, or from any other material, donât hesitate to reach out to me.
[1:01:11 Yegor] Thanks a lot.
[1:01:12 GeePaw] Right, thanks man.
[1:01:12 Yegor] Bye-bye.
[1:01:13 GeePaw] Bye-bye.
