ScreamingBox Technology & Business Rundown

SPEAKERS
Robert Martin, Dave Erickson

Dave Erickson 00:30
In this month's podcast Welcome to this ScreamingBox Technology and Business Rundown podcast. Today we'll be talking to Robert Martin, also known to many as Uncle Bob. Robert is considered to be a legend in the coding world for his deep knowledge, experience and advocacy of Clean Code writing. Robert has been a development manager for companies such as Teradyne, and Clear Channel. For the last 30 years he has been a software consultant, lecturer and best selling author. He currently runs Uncle Bob's consulting and you can take his classes and watch his Clean Code videos at CleanCoder.com. He has authored many books and magazine articles on Clean Code principles, and agile development methodologies. He was the editor in chief of C++ report magazine and served as the chairman of the Agile Alliance, which is only natural since he was also the founder of the influential Agile Manifesto. Look it up your mind will be blown. Well, Bob, hopefully I got most of the important stuff covered. Is there anything I missed?

Robert Martin 01:38
Oh, heavens, probably over the last 50 years. God knows what may have happened in that span of time, but you did fine. It was fine.

Dave Erickson 01:50
Well, we're looking forward to having an interesting conversation on Clean Code. Well, in this month's podcast, we're going to focus on Clean Code basics, concepts and business cases. and then next month's podcast, we will continue with Robert and have Botond join in to discuss Clean Code techniques and to get into the technical aspects and applications of Clean Code. As an owner of a development agency, I focused on how we apply Clean Code in a way that helps our clients and our developers to grow. And our particular situation is, we have 150 plus developers in our pool, mostly from Europe and South America. They've all had different educations, although almost all of them have some sort of computer science education and degree, but they all have different perspectives in the way of coding and they have learned different things over the years. And so I'm very curious in the concept of developing a Clean Code culture in an agency that works with such a wide variety of developers and types of developers. And we do hardware, firmware and software so we have a fairly wide variety of technical stacks. But I'm also very interested from the developers aspect of why focus on Clean Code and why do Clean Code and the business argument of why Clean Code would be better than just a standard way of doing it randomly, which seems to be in some way a general trend in the industry. And as a person who doesn't necessarily believe in that trend, I'd like to see it go into a higher quality way. What is your concept or definition of what Clean Code or what does Clean Code mean to you might be the easiest way to start?

Robert Martin 03:55
This is the same question that I asked a number of well known software authors I introduced in the beginning of my book. So I talked to Grady Booch, I talked to Bjarne Stroustrup (Inventor of C++) and Michael Feathers and Ward Cunningham and a whole bunch of other folks and asked them exactly that question, what's Clean Code? And they all had entirely different answers. So it's really interesting to compare and contrast what these guys said and Grady Booch for example, he said, “Clean Code is elegant and direct. Clean Code does one thing that was great”. And that was Grady Booch’s answer and Bjarne Stroustrup said, “I like my code to be efficient and Clean Code is easy to read”, or something like that. There were a whole bunch of different answers. Michael Feathers I think gave the best answer though; It's my favorite of all of them. He said “You know you're looking at Clean Code when it, it always looks like it was written by someone who cares”. And I think that's really the bottom line there. It looks like it was written by someone who cares, and cares about the guy reading the code, the code comes off and communicates to you, it tells you what its intent is. Ward Cunningham said, “You know, you're looking at Clean Code, when each routine you read is pretty much what you expected”. I thought that was a fascinating answer, right? Like, you're looking at this code and as you're reading the code, you're just agreeing with it. Yeah, that's right. Yes. Yeah. So scroll down a little. Yes, I agree with that, too. That's code that has nothing confusing in it, nothing that makes you go, Oh, my God, what's going on inside this module, none of that nonsense. It just communicates to you, it flows. Well, it's well organized. If I had to boil it down, if somebody asked me that question, like you just did. I didn't put my answer in the book. If I had to answer that question, I would say that Clean Code is just about doing a good job, just do a good job, do the kind of job that allows you to go home at night and look in the mirror and say, Oh, my God, I did a good job today, instead of having to go take a shower.

Dave Erickson 06:34
Well, it sounds to me that the root of Clean Code is a care or a craftsmanship of what you're doing that you know, it's not enough just to write the sentence, it's not you have to check to make sure the punctuation is correct, the grammar is correct, you have to do all the things that make quality, right. You know, some people may argue, well, isn't it better just to get code that does the job as cheaply and as efficiently as possible? And, you know, businesses are asking the question, does it really matter whether you put the quality in at the beginning, or put the quality in at the end? That's why they have tests, right? So, you know, I come from a manufacturing background. Actually, we share a little bit of a past connection, because I worked for a contract manufacturer called Express Manufacturing, Inc. in Orange County, and we built a lot of Teradyne stuff. We would build a lot of functional test equipment, circuit boards, and assemblies for Teradyne. You've probably worked on the coding side of that. So there is kind of a background in manufacturing, if you try to, you know, inspect the quality and at the end, you're just gonna have a lot of bad quality that has to get rebuilt, right? So software may be the same thing, right?

Robert Martin 08:02
So there's two kinds of quality that we're talking about here. One of the qualities is, does the software work? Is it loaded with bugs? Do you have to reboot it every night? You know, how often do you have to hit the reset button to get the thing back and get its sanity back? That's one kind of quality. But there's another kind of quality which people often do not pay enough attention to and that is the internal quality of the code itself. And so if we focus on just that outside quality, we can build systems that work perfectly, but cannot be maintained. The productivity of the software developers plummets. And if you've been a developer for any length of time, you have ridden this roller coaster, where you start out with very high productivity, but then the code becomes messy and tangled and there are weird shortcuts and strange things going on. And the productivity of the team plummets, probably as much as an order of magnitude, you know, maybe it's asymptotically approaching zero. As time goes on and everybody understands it, everybody feels this. ‘Why are things so slow?’ And yet the reason that things are so slow is that they've made a mess, and nobody wants to back up and say, you know, maybe we shouldn't make a mess. Maybe if we kept this code internally clean, we could keep going fast for the duration of the project. We could keep going fast for the lifetime of the project. And that's really the emphasis of Clean Code. Clean Code is saying, you've got to focus on that second kind of quality, so that the team can continue to go fast, the team can continue to make progress at a predictable and stable rate rather than slowing down through the morass.

Dave Erickson 09:59
So Clean Code, although in one aspect is about craftsmanship and clarity. On the other aspect, the business case for it is, in the long run it’s going to be much more productive and efficient than just randomly producing code as it gets messier and messier as it gets bigger and bigger.

Robert Martin 10:21
You have to be careful with this long run argument, right? Because then you say, Well, okay, in the long run, I buy it, you know, yeah, we will go faster in the long run. But what's important is the short term because we've got to get to market fast, and we've got to be out there. So the hell with the long run, let's drive like mad Banshees and get something done. And that ignores the problem that this long run argument is literally about a week. It can make a mess in a week that nobody can penetrate. So you go down that curve really, really fast. In fact, I mean, every programmer has had the experience, where they work in the morning, and it's lunchtime, and they go away for lunch. And then they come back after lunch, and they look at the screen and wonder who the hell wrote this crap on their screen, and they can't deal with it, tear it apart and try and put it together in some better way. So this long run short run argument is very dangerous, right. We really have to look closely and say, you make a mess within a matter of hours, maybe a day, maybe two days, it's, it's worth throwing out unless you have kept it clean, it'll cost you more. So the tagline I like to use in this argument is, the only way to go fast is to do a good job, regardless of the timescale. The only way to go fast is to do a good job. The only way to go fast is to go well.

Dave Erickson 11:50
Yes, yeah. You know, there's another business case here, and that is quality. It may cost a little more on the front end, but it will save you a lot more on the back end. And I think that in regards to Clean Code, this is a really important aspect, that it is important for clients and people who are managing software projects, really kind of understand. Because, you know, we have a wide range of clients, some clients have no technical ability whatsoever and we handle all technical aspects of the project in the product development. I have clients that have large in-house teams, and they're having us work on a little tiny module or a small part of that project and they micromanage everything to the point where they're looking at every log that the developer wrote. You spent an hour doing this. did you really have to spend an hour doing this? That should have been 50 minutes instead of 60 minutes, you know, you have a wide range of people, you know, saying, you know, do this or do that. And so if I have a developer, you know, work on a piece of code, and he actually spends some real time on it to make it good, to make it clean, you know, the question is going to be can the client even appreciate it or recognize why that time was spent?

Robert Martin 13:14
You know, I can I can, I can count the amount of time I've spent on one line of code I have saved in some cases, I've spent an hour on one line of code, because I could not quite get it right. It wouldn't work, or it didn't fit quite right. And on the other hand, I have spent 10 minutes on 50 lines of code. So there is no good way to measure this kind of thing you can't look at, at software at that micro level and come up with some kind of you know, you that function took you too long to write. One of the one of the tricks I learned over the years, was to measure the amount of work that gets done in about a week, maybe two weeks. This is the Agile idea, right? You block up time into some kind of relatively long period, like a week or two weeks. And you measure how much gets done inside that period. And then that is roughly repeatable. Not real repeatable, but roughly repeatable. If you were to, if you were to somehow come up with a point value or a metric that measures the amount of work done, you would get roughly the same amount of work every week or every two weeks. And so one of the things I did when I ran a company like this where where, you know, we were selling software, we were selling our services to write software, is that I would I would go to my clients and say, Look, we're gonna deliver a certain amount of value every couple of weeks and we're going to split the way we get paid. You're going to pay us an hourly rate that small, kind of a stipend hourly rate and then you're going to get a bonus for every feature we deliver. And this was really good, because it set the set the incentives well, it was kind of share the risk idea, if we got done really fast, if we were moving fast, we got paid a lot of money in the short term, and the company who hired us paid less money than if we took a really long time. So, it was a very good balance of incentives.

Dave Erickson 15:29
We use UX a lot, user experience, and we bring in UX people at the beginning of a project to really kind of take a look at, okay, do you really need this feature set? All the shareholders touch the software? What are their expectations? What do they want out of the software, you know, and develop an actual software architecture on the front end, using UX? It seems to me that UX is kind of part of this concept of Clean Code, that by organizing this stuff on the front end the developers have an understanding of what they really need to be developing. And that may help them start off correctly and have the information they need to really write cleaner code from the beginning, because they're not trying to guess, okay, well, I do this, or should I do that? Or does the software really need this? Or does it really need that? I think that UX has a role in Clean Code, but I'm not certain if people would describe it that way.

Robert Martin 16:32
So UX is really important, obviously. And if you've got a good definition of what the user experience is going to be like, that communicates very well to the development team. So, as far as that concern, I agree with you. But there's a trap involved with this. And the trap is that nothing changes faster than the UX. The people who are doing their mining, the user experience will be changing that, for all kinds of reasons throughout the lifetime of the project. Some of those reasons will be substantial. Some of those reasons are completely cosmetic, based on fads of whatever the hell is going on in the current world outside, you know, our buttons should no longer have diesel looks. They shouldn't be round cornered now. And they should all be pastel colored. Because these guys, they think, in weird ways and they look at what the user seasonally, it's some kind of fashion experiment. So the problem with that is that you've got these really variable things that you are using to try and drive something that is much less variable, which is the structure of the system, the architecture of the system. There, it's not bad to have the UX be an input early on, but you can't trust it, it's going to change in weird and strange ways, you have to come up with a software architecture that can tolerate that change really easily. So that's one of the reasons we like this agile approach where we start with a little UX, and a little bit of software, and then a little bit more UX and a little bit more software and then the guy has changed the UX, they change it right in the middle of all this. And we're over here going, Ah, we see how this is going to change. Okay, well, maybe we can adjust our structure so that it can tolerate that kind of change. And then a little more UX, a little More code. Oh, it changed again, oh, yeah, our code over here is actually tolerating that change, okay. And you realize you're onto something.

Dave Erickson 18:26
Let's open up what I consider a Pandora's box, in a sense. And that is testing. You know, from a manufacturing background, I've had that experience of, you know, build the product and put the QA at the end. And the experience of if you put the QA in the beginning and throughout the process, have very different results. In software there's all kinds of testing procedures, there's all kinds of testing theories. Maybe you can talk a little bit about the role of testing and Clean Code. And I'm sure it has some kind of relationship.

Robert Martin 19:06
Kent Beck said, “First, make it work, then make it right.” Very, very good advice, right? Get the thing to work. And then you can fiddle with it and make it right. And that that second step is the step that many programmers neglect. They get it to work and they go Okay, check it in with Elgato here. How do you know that it works? Well, you know, it works if you've been able to come up with enough tests to characterize it properly. Right? A lot of programmers don't even bother with that. They just kind of test it manually with their eyes and then kind of cross their fingers and say, Well, geez, I hope that works. Let's ship it, maybe QA we'll find out something about it later. I think that's fairly irresponsible, right? So what programmers should be doing is making sure they are surrounding their code with tests and they should do that on a very incremental basis. And the way I like to do it is to write the test first and then make the test pass. I follow the discipline of Test Driven Development, which is another one of Kent Beck's inventions, right? So, little tests, little code, little tests, little code, little tests, little code in a 10, second, or a, or a 30 second cycle, little bit of test, a little bit of code, and then build up the code that way. And if you follow that principle, if you follow that kind of discipline, you wind up with code that does what you believe it's supposed to do. Now, it may not do what the customer believes it's supposed to do, okay, at least it believes what it does, what you believe it's supposed to do. So then the next layer of testing that I like to have is to have the customers, the QA people in the business, analysts and the people who are really worried about features and business value. I'd like them to be following the same kind of process where they are writing tests. And they have to write it in a different kind of language. You know, a softer, gentler kind of language that allows them to express, you know, the features and behaviors without having to write if statements in a “while” loop. And they write some nice tests, which the programmers must make the code pass. And the programmers cannot say they are done with anything, until all of those tests pass as well. And so now you have the programmers writing tests that prove that the software does what they think it should do and you've got the programmers executing tests that prove that the software does what the business thinks it ought to do. And that's pretty good, not perfect, but it's pretty good.

Dave Erickson 21:37
So if you get everything passing the tests from the development perspective, and everything passing the tests, from the business perspective; you basically have code that is functioning at a high level, you still probably should go back and “clean it up”, depending on the definitions of Clean Code. But building that in the beginning is going to eliminate a lot of problems on the back end, basically.

Robert Martin 22:04
If you don't clean it up. You can get all those tests to pass, but you wind up with something that Martin Fowler famously named flaccid Scrum. Okay, okay, it gets weaker and weaker as time goes by. The team slows down and slows down because they haven't been cleaning things up as you go along. So the discipline that I like to advocate for is called the Red Green refactor discipline. And it's tied in to test driven development, you write a little test that fails, you write the code that makes it pass, then you clean it up, little failure, little passing, clean it up, little failure, little passing, clean it up. Again, in this 30 second cycle, there is no scheduled time to refactor. There is no nothing on the schedule that says, this is when we will refactor. We're refactoring all the time, we're cleaning all the time, it's like going to the bathroom and then washing your hands, you just always do it.

Dave Erickson 23:06
So in this kind of process, we'll call it a competent software development process. The concept of Clean Code comes into a fact where a developer is looking at a piece of code; How does he define or decide that it is, quote, clean? What are the aspects or attributes that one would consider Clean Code? Right? Because everyone's working with, you know, comments; They think putting lots of comments in the code is Clean Code. And I've heard some developers say, you know, functions that are really expanded and just encompass the world is Clean Code. And so I don't, you know, there seems to be some attributes of Clean Code and maybe you can talk a little bit about what, what are these kinds of attributes, so that a person who doesn't necessarily understand Clean Code can at least understand these are aspects of what Clean Code means.

Robert Martin 24:11
So Clean Code is well organized. And by well organized, that means that you have decomposed it into small, understandable chunks that have nice names, that are well named. And those chunks are placed in positions that are intuitive. So our modern languages are very nice about this because our modern languages have things like namespaces, and classes and fit fields and methods and inner classes and inner methods and things like that, that allow us to build a very nice hierarchical structure of well named elements. Early code did not have this right. If you were an assembly language programmer, there was nothing like that. What you had, you know, was a deck of cards. That was your organization, and you fought like hell to put some kind of organization into it. And it was very, very difficult. Modern Languages give us all the tools we need, right to, to organize the code in nice little chunks. When I look at code, if I see functions that are more than 10 lines long, I start to get suspicious, right? Somebody's, somebody's being careless, right? Could you take a function that's 10 lines long and extract another function from it and give that a nice name? If so, that would be cleaner, that would be better. And the names, the names themselves, did you choose the names? Well, or did you call it function one and function two? That would probably not be a good set of names, right? Like to have names that specify, Well, there's a very interesting characteristic of these names, as you are extracting from methods. You've got some nice big method; and you start taking it apart into smaller methods. And then you take each of those, and you take them apart into smaller methods. And as you do that, the names of the functions get longer and longer, because they're more and more precise. And the things that they're doing take a lot of words to describe. So the names of these functions start to look like phrases, sentences, almost, and those sentences fit inside of our keywords. So all of a sudden, you'll see if and then a sentence inside parentheses or a phrase inside parenthesis, and then you'll see the THEN clause and that will be a call to another function. That is some kind of action. If this happens, the action, and the code starts to read. Not like English, it's still code, but it starts to read well, even someone who's not a coder could probably look at it and go, Oh, if the employee needs full benefits, then pay full benefits. I see where you're going with that. So, that's Clean Code, Clean Code is well organized. And the code itself has a kind of readability that is beyond the technical mathematical guru programmer kind of thing that even a non-programmer could look at and sort of see. I'm not recommending COBOL, I don't think that route, but I do think that, you know, someone who's familiar with the business should be able to look at parts of the code and go, Okay, I see the logic in that one.

Dave Erickson 27:49
It's almost as if the code should be so descriptive. I mean, developers should not be afraid of having a function name that is too long, right? If it's descriptive and precise, right? On the other hand, if you write the code in such a way that you're being descriptive and precise, you don't really need comments very much, right? Comments should be reduced. Whereas some developers, they write these weird, you know, car crash dot whatever is a function and then they have to write a comment that says, Well, this variable is taking the information from, you know, the number of pies that the factory made, and you know, and they write all this long comment. So, and some people think that a lot of comments mean, it'll be easy to work with. But it seems like that's not the case.

Robert Martin 28:41
Oh, I don't think that's the case at all with comments. Back in the early days, back in the assembly language program days, or even the Fortran days, comments were utterly indispensable. You had to have them because the code could not communicate that the name of a variable is restricted to eight letters. In a lot of languages, it was six, right? You just couldn't have it any longer than that. So the ability to express yourself in code was severely limited. In assembly language, it was literally impossible to express yourself in code. Nowadays, we can write code that is extraordinarily expressive. And so it should not need an awful lot of comments. The reason to write a comment is because we fail to express ourselves in code, every comment we write is a failure. Now, we do fail to code because it’s not a perfectly expressive language, there are concepts that cannot be communicated that way and therefore we should write comments in those instances. But the idea that we write comments everywhere is a very bad idea. It's the thing that's taught in school, is that comments are pure good. They're like Schindler's List, right, Absolutely pure good and that's wrong. And because they're taught that, programmers will write with far too many comments and then those comments age and they get old. And they're not, they're no longer correct, they lie to you. Most programmers nowadays will tune their IDE so that the comments are painted in some color they can ignore gray or green, you know, gray fading into the background or green, it's like the grass outside, you don't have to pay any attention to it. Like because most programmers don't want to read the comments. My IDE will actually collapse the very first comment in every source file, regardless of what it is. If there's a comment in this, if it starts in line, one of the source files, they'll collapse it because they know nobody wants to read that comment.

Dave Erickson 30:51
Yeah, it's almost as if you wanted to kind of look at code and see if it's well written code. If you start seeing a whole bunch of comments, it's kind of an indicator that the developer feels like he's trying to communicate something he couldn't communicate in the code. And so that's kind of maybe a red flag in that sense. Although, some developers may have gone to school where they said, just code, you know, comment everything, right? Yeah, yeah. It's another methodology that is sometimes taught. But it shouldn't be you're, you're commenting because you don't think the person reading the code could actually understand it, then you're kind of creating a real problem in that sense. And the problem isn't necessarily enough comments, it's maybe your code needs to be more descriptive and detailed.

Robert Martin 31:39
Another reason people write too many comments is because there is a corporate coding standard that demands that comment for everything. That is possibly the dumbest thing that could be in a coding standard, right? You will comment on every class, you will comment on every variable, you will comment on every function. Okay, no, that's just a really bad idea. The first first time I read that comments should be limited was in Kernaghan and Ritchie’s book, The C Programming Language, where they literally came out and said, you know, we're not going to put a lot of comments on this, because the code is pretty easy to understand.

Dave Erickson 32:18
Yeah, I really liked this philosophy of writing the code in such a way that the code explains itself. And whether you know, you know, code or not, you can at least understand kind of what's happening in this area of the code, whether you know the code or not, you know, I think that that's a good application of it. You know, and that goes back to functions, you're trying to name a function, you almost need a business sense in the way that you understand what the code is trying to do. Usually code is trying to achieve some kind of solution for a business challenge, right. And so if you can write the functions in a way that describes what they're actually doing, that makes it much better. But sometimes, you know, if a developer is trying to pack too much into a function, it could get really hard to describe the function. So it might be that for Clean Code, you know, breaking your functions down, maybe might be part of that, is that correct?

Robert Martin 33:23
Oh, sure. Because the more you break them down, the more you separate the business stuff from the non business stuff, and the weirdo detailed stuff, and you can kind of separate all that out very nicely and give it nice names.

Dave Erickson 33:34
Yeah, how far should someone go? I mean, should someone have a rule? You can only do one thing with a function? Or, is it okay, that functions do multiple steps, as long as they're described correctly. Or do you put in the kitchen sink and do everything you can with a function? I don't know, what would be a kind of guidance for Clean Code in that regard?

Robert Martin 33:57
Well, my rule is extract till you drop. You know, if you can extract one function from another, you should extract that function from the other so that every function does one thing and that's an old old rule, right? Functions should do one thing, you could go back into the 1960s and read that in the books that were out there at the time, but nobody understood what one thing was. I wrote a 3000 line C program in my younger days called GI, right, Graphic Interpreter. And if somebody had said, you know, Bob 3000 lines, it must do more than one thing. I would have said at the time, Oh no, it interprets graphics. So, this idea of one thing was very subjective, but I think we can make it objective by putting this rule in, “extract extract extract” until you drop. Any function that can be separated into two functions, It does more than one thing. The only functions that do one thing are those that can no longer be extracted into other functions, which means that you're going to explode your code out into a million little tiny functions and people get scared of that, and they shouldn't get scared of that. It's a good thing, not a bad thing.

Dave Erickson 35:17
It's not about how long the code is, it's about how precise it is and how explanatory it is and breaking every function out and you have a zillion functions, it's okay, as long as those functions are named in a way that makes sense and is correct. And you know, whether they're eight characters or 80 characters, that almost doesn't matter as long as it's descriptive in a correct way.

Robert Martin 35:42
There's another rule that follows along with this, it's a direct result, right, which is, is sometimes called the slap rule. And it's sometimes called the stepdown rule. And it goes like this, every line of code in a function is at the same level of abstraction and that level is one below the name of the function. There's no going up and down the abstraction levels, as you're reading the code inside of a function. Every line is at the same level, one level below the function name.

Dave Erickson 36:14
What are some of the things when you have a large group of developers who are coming together on projects, you know, 20 - 30 developers, some are full time, some are part time. Some are very tech specific. Some are generalists. How do you kind of develop or promote this concept of craftsmanship and have everybody working on the same kind of principles of Clean Code?

Robert Martin 36:42
Well, that's a tough one. So some of the rules we've been talking about are pretty specific, right? Extract the drop, step down rule, minimize your comments, make the code read nicely, you know, long names, as you get down farther into the list, that kind of thing. So those are more objective measures. Then, you get the subjective one says, Is this code clean? Is this the best way to do it? Or should I do it this other way, and people will argue about that. If you have a team dedicated to the principle of just doing a good job, then you can resolve those with some simple heuristics. For example, Kent Beck used to say, no argument is worth more than five minutes of discussion. If it takes longer than five minutes to sell your point, you don't have a point. And you might as well flip a coin if people disagree, right? If you can't resolve it in five minutes, neither of you really have a point, flip a coin, try it one way, if then it doesn't work so well, then, you know, the other guy was right, and that's fine. So a nice team of people who have already agreed to this idea of cleanliness of code and craftsmanship and doing a good job can use a rule like that to solve most of the issues. Then, you get to the other problem and that problem is when you don't have a team where everyone agrees that we should be following principles of Clean Code and you get this a lot. And what happens then is you will have the team divided itself into two, two sets of different values and the team cannot survive that way. There will be a divorce and the divorce may come suddenly. I have had entire groups of people just walk out and say no, we're not doing this and they leave and that's fine. And sometimes it happens much less abruptly as individuals seek better places to go. But there is no way to force them to adopt the rules. Either they accept the values, or they don't and if they don't, there will be a separation. Now, you can encourage people, you can have lunch and learn. You can do demos, you can do podcasts like this, you can write books like I do. There's lots of ways to encourage people, and that has an effect. But, there will always be people who say no, and separate themselves off. And that's a cultural issue that, as an industry, we're going to have to resolve through a different mechanism.

Dave Erickson 39:30
It's kind of like you do the work on the front end, when you're bringing a developer into a team or getting him a project or work. We go through a step where we evaluate their technical abilities, looking at their code and have a homework challenge. That's one of the ways that we measure a developer. We do a lot of personality based assessment, where we look at, What are their work patterns? Are they extroverted or introverted? Are they detailed? Are they creative? You know, try to put them with team members that, you know, connect with them and won't cause a lot of conflict. It's almost like we have to look at their philosophy of coding, or their beliefs in coding. Do you understand basic principles and maybe as a company or as an operation, we can say, Okay, we believe that you use minimum amounts of comments that, you know, your functions are descriptive that you're focusing on breaking these general kind of Clean Code, rules and philosophies and find out if they believe in them at the beginning, if they've had the training or the upkeep. So you do that on the front end. And in that sense, you can then put together teams that will all agree with the basic philosophies, then it's more a question of will the client agree with the basic philosophies and support that but that's a kind of a different side of the coin. But I think that that that might be one of the ways to do that, that the company is going to have to kind of do that on the front end, that you have to really look at the developers and find out what do they know what are their believes in Clean Code, or if they even understand various concepts, I think education may have a basis for it as well.

Robert Martin 41:24
That may be. I'm not a big enthusiast of higher education, systems, teaching programming, university programs teaching programming. My experience is that people who are either self taught or they're taught through a kind of mentorship program do a lot better than those who come out of university. Because the professors in university, generally speaking, have never had to write code in anger. They've never had to actually work in an industrial or professional environment. They've never had to solve the kinds of problems that the poor programmer who comes out of university suddenly finds themselves involved with. So my experience may be a little different. I look at programming as a discipline that ought to be taught in more of a trade school than a university setting. We don't need computer scientists. We really don't even need computer engineers. We need computer tradesmen, we need software tradesmen, people who understand the nuts and bolts skills of putting code together in vast quantities. Because we are writing an incredible amount of code. Yeah, you do, you know, the rate at which we are hiring programmers. The number of programmers in the world doubles every five years or so. It's astounding. It's astounding. And, and you know, we started in 1946, or something with one programmer, Alan Turing. And now, here it is 2022 and there are 100 million programmers in the world. That's a crazy exponential curve. And it's still going up. It is still going, we're still hiring people at a rate where, you know, we're doubling every 5, 6, 7 years.

Dave Erickson 43:22
Yeah, that rate is even expanding now, I mean, there is such a developer shortage and it's generating a lot of, I guess you could say, generating a lot of opportunity. There's a lot, there is. Exactly, there is a lot of online learning that's occurring. Now, the techniques for doing online learning are much better than they were even five years ago and we've had some developers come through here that were superb developers, and they did everything through online learning, which I consider a valid education. It’s the same as going to a university in a sense. If you do a good course load and take the online learning correctly, you can easily become a world class developer over time, right? Yeah, there is a thing happening per se, that is termed as low code or no code development. Now, in my experience with no code development, and low code development, it's a lie in the sense that people think, Oh, no code actually means I don't have to do any coding, but that's not the reality of no code. And that's not even the concept of no code. And the difference between no code and low code is there is no difference, right? But I do agree with some of the concepts of no code, how many people need to know how many times do we need to re-code a login screen right? Yeah, they're pretty Simple, you know, so taking elements and using that to bring, you know code that is pretty much the same and everyone writes the same code to do a login screen, it's very little difference using that. But you still need code to kind of glue it all together. And you definitely need an understanding of how code works to make it all function in this sense, where you're taking pieces of someone else's code, and putting it all together, and then trying to figure out how to glue it together. So it actually functions as a whole concept or product or system. Does Clean Code have a place in that?

Robert Martin 45:43
So I love this discussion, right, the whole low code, no code thing, because you know what happens? Well, we've got a new framework. And that means you don't have to write a lot of code. Oh, that means I can do a lot more complicated things, those complicated things, like auto code. So, think about this as a Pareto distribution, right? The little things, there's a lot of little things, and not a lot of big things, this is a nice Pareto distribution. And as we get these frameworks that give us more capability, we want to do bigger and bigger things. Now, the great thing about a Pareto distribution is that it's scale free, no matter what magnification factor you use, the damn curve looks exactly the same. Programming is scale free, it's always going to be difficult, it's always going to expand to fill whatever complexity you want, you know, you got some framework that mobile, it's going to minimize your code, you're just going to do a lot more code that way. So Clean Code is a rule that applies to all scales. And you can't go in there and say, Oh, low code, we don't have to do Clean Code, we can make a great big mess and it won't matter because we have a low code environment. Now you don't have a high code environment, because you're gonna want to do more with it and if you do more with a mess, you won't be able to do very much.

Dave Erickson 47:08
All right. Well, thank you very much, Bob. It's been great, really good. Thank you so much for your time. We really love this. Till next month. This has been the ScreamingBox technology and business rundown podcast. Thank you for joining us on this month's podcast. Remember next month's podcast. We will continue with Robert and have Botond join in to discuss Clean Code Techniques and to get into the technical aspects and applications of Clean Code.
Thank you very much for taking this journey with us. Join us for our next exciting exploration of technology and business in the first week of every month. Please help us by subscribing, liking and following us on whichever platform you're listening to or watching us on. We hope you enjoyed this podcast and please let us know any subjects or topics you'd like us to discuss in our next podcast by leaving a message for us in the comment sections or sending us a Twitter DM. Till next month. Please stay happy and healthy.

END

SUMMARY KEYWORDS
code, clean, developers, programmers, function, comments, tests, people, write, software, business, nice, rule, kent beck, long, called, understand, clients, ux, modern languages, cleancode, cleancoder.com, Rober Martin, Uncle Bob, Grady Booch, Bjarne Stroustrup, C++, Michael Feathers, Ward Cunningham