Coding Blocks - Clean Architecture – Fight for Architecture

Episode Date: October 2, 2017

Joe learns of our harebrained idea, Michael learns of Eisenhower’s matrix, and Allen explains polyfills as we begin our dive into Uncle Bob’s latest book, Clean Architecture. Prefer to read these show notes on something other than your podcast player? You can find the full show notes for this episode at http://www.codingblocks.net/episode68. Sponsors Linode – Use code […]

You're listening to Coding Blocks, episode 68. Subscribe to us and leave us a review on iTunes, Stitcher, and more using your favorite podcast app. Check us out at CodingBlocks.net where you can find show notes, examples, discussion, and more. Send your feedback, questions, and rants to comments at CodingBlocks.net. Follow us on Twitter at CodingBlocks, Facebook also, slash CodingBlocks, and head to www.CodingBlocks.net and find all our social links there at the top of the page.

And with that, I'm Alan Underwood. I'm Joe Zak. And I'm Michael Outlaw. This episode is sponsored by Linode. Have your own server up and running in under a minute. They have hourly billing that you can cap on all plans and add-on services, including backups, node balancers, and long view. VMs for full control running docker

containers, encrypted disk, VPNs, or whatever you like. They have their own CLI so you can manage all your Leno needs directly from your terminal. You can even run your own private git server. They are backed by native SSD storage, a 200 gigabit network in all their data centers, up from 40, and Intel E5 processors. They have 24-7 friendly support, even on holidays, and they come with a 7-day money-back guarantee. For your $20 promotional credit, head to www.codingblocks.net slash linode, that's L-I-N-O-D-E, and enter the code CO blocks 17. Again, that'll give you a $20 credit,

which is the equivalent of four free months on their smallest Linode instance. So it didn't you, you called dibs today. I did. Yes. So let's get into the iTunes reviews. The real Brian Choi, a talus pizza,

HD 88 scuba, Steve36, JD Murth, James Strugnell, Al Franken, Mikey Don, aka ProgrammingPD, aka TheManWithTheGram, aka TheGhostOf404thSth street, aka Captain Hunt, aka, oh, Captain Hunt and Peck, sorry, aka General Error, aka the Wizard of WWW, aka Senior Segfault, aka New New Mew, aka PH Pimp, aka whose computer is this,

aka the Thread Safety Inspector, and finally, aka the author of Copy and pasting from stack overflow. That's amazing. He's got a long name. He does. That's excellent. Uh, so I guess I got the Stitcher reviews. So a little precursor to this, for whatever reason, we have two Stitcher pages. We've never been able to cancel one of them and just by happenstance the other day i noticed that we're getting reviews on one of them that we didn't even really know was out there so this is sort of an apology and a shout out to you guys for

leaving us a review there so this is from the other stitcher page so the cause s vod and tv stevens thank you very much. All very nice reviews that you guys wrote. I can explain that. That's the Stitcher page from the Upside Down. From the Upside Down. Oh, come on. Do we have to play Yes, Yes, No with the Upside Down?

You probably will. Hey, wait. Do you know what it is, Joe? I mean, I'm familiar with terms like that from comics and video games. Is it like Stranger Things or It maybe? See, okay, he got it on his very first guess. Wait, was it The Stranger Things? Was that part of that movie or show? Yeah.

I don't remember it. All right, sorry. I watched the whole show. I liked it. It's the other side of the board. Yeah, sorry. Oh, that was a tangent that went nowhere. Yeah, it really did.

All right. And then from the real Stitcher, the one that we always know about, 85... UStorm? Maybe I typed that wrong. Maybe not. Miklik, Fraben, and Jerry4592. So thank you. Oh, wait, wait, wait.

We got more. Joe. Yeah, I wanted to mention we just found out a service called pod chaser it's kind of like imdb for podcasts and you can subscribe and stuff there too and i was checking it out and i noticed that we already had two reviews there and so i just wanted to say huge thanks um particularly to these three people because i i know they both left reviews on other places as well so just wanted to say it was a really nice surprise to us and really appreciate it uh to uh go prog man and surprise to us and really appreciate it to Goprogman and Dance2Die. So thank you guys very much.

Yep, thank you all for leaving the reviews, even the one that hurt a little bit. But yeah, thank you all. All right. And then so one of the things I did want to mention because I feel like after I read Vassiliev's comment on episode 66, I sort of realized that we did come off whining a little bit about time estimates. And so, because we literally just bemoaned them for probably 10 minutes and then we're like,

all right, moving on. So a shout out to him for calling us out on that because we strive not to be those guys that complain and never bring a solution or something to add to the topic. And we didn't. So we'll admit it and we'll have to revisit that and try and look into some stuff to maybe make that more realistic. So anybody that wants to go check out his comment to where he basically scolded us, rightfully so, we got a link to episode 66 there. He's got a couple of good comments in there. And I see him talking with Brad, too. Brad Trager, we've mentioned before, also has left some really great comments. Oh, there's a lot of really great comments I haven't read here.

Awesome. He's just as surprised. Easy for me to say. Yeah just is surprised. It is. Easy for me to say. Yeah. All right. So I do want to bring up something here, and this is awesome for anybody that wants to look at cloud services. They haven't had a chance to get in there.

Microsoft is coming to Atlanta. They're doing what's called the Red Shirt Tour. It's on Wednesday, October 18th. So it is during a workday, but if you guys can swing it, anybody that's going to be in the Atlanta area, this is a free thing to attend. And Scott Guthrie is doing all the talking. There's going to be a ton of good topics here. So we're going to have a link here, but here's some of the things that he'll be covering. And he's going to be doing live demos of a lot of this stuff. So the latest in infrastructure, VM scale sets,

managed disks, the hybrid cloud, which is really cool stuff. If you haven't heard about that, Azure stack enterprise, mobility, security, Xamarin,

mobile development, SQL, AI, machine learning, and more. So again, we'll have a link here, which ironically is going to a cold fusion page.

Yeah. And you mentioned specifically the Atlanta one. And if you can't make it to the Atlanta area, you might want to just Google to see if there's an event coming to your area because, uh, I quickly checked and there is a Dallas, Texas event coming up October 17th. That's the same tour. Oh, awesome. Excellent. Yeah. I mean, this is going to be killer stuff. And for those who don't know, Scott Guthrie, I believe is the VP of cloud engineering at Microsoft. So like this guy knows this topic, right? So definitely,

if you can check it out, it's free, you know, take advantage of it, man. Like there's not too many opportunities to get stuff like this for free. Uh, another thing that we want to touch on quickly is outlaw myself attended connect tech. I thought it was pretty awesome. Do you, what was your takeaway? I'm always excited to go to that event. Yeah. Um, there's good stuff there. I think this year there was definitely react was still like the most popular JavaScript framework there. It had two separate tracks of talks going on throughout each of the days of it.

But I did see more representation from Vue this year than from previous years. So that was interesting. And a lot less Angular. Way less Angular. Yeah. So that was interesting. Um, and, uh, a lot less angular, way less angular. Yeah. Agreed. Yeah. It was surprising to me. So react was huge view view was coming on strong at this. And then there were the separate tracks for iOS and Android, right? Like that's still going really strong. Well, well, I was actually going to bring that up too, because I did notice that Swift, it seemed like those talks got moved to the smaller rooms now from where they used to be from previous years.

So, yeah, I was kind of like curious, like, huh, what does this say about the popularity? But yet, I don't know if he attended any of those talks. They were still, you know still well attended and everything. So it was curious though. Very cool stuff. So that was fun. And then this is a random side topic. Oh, wait, Joe, did you have something?

I saw you move your hand. Nope. No. Okay. Not everything we talked about was random side topics. Yeah, pretty much. We're trying to blow through this as quickly as possible. This I wanted to bring up because this comes up a lot in the gear channel and

even amongst friends and coworkers or whatever is networking, right? It used to be that you would go LinkedIn and meetups and maybe not that. Oh, maybe not that, you know, Slack channels and that kind of stuff, which you can hit at coding blocks.net slash Slack.

You can come join some of these cool conversations, but you remember it wasn't even so long ago in the past that somebody would ask, Hey, you know, what's the best router to get, right? I have this house and I need to reach all the points of my house. What's the best router to get. And that's changing a little bit. Like if you walk into best buy now, like there's, they have like an area at the front of the store with a bunch of different mesh networking technologies now. And some of the big ones out there right now, I'll just name them off quickly and we'll have links to them so that if you've not seen these things, you can just take a peek. There's the Google Wi-Fi, which is by and far pretty much the most affordable one out there. There's the Netgear Orbi, there's the Linksys Velop,

and then the Ubiquiti Amplifier, some of the more popular ones. But I installed one at my house. I know you have. Go ahead. Which one's the, oh, because there's the Eero as well. Eero, yeah. I haven't put that one on here. Oh, okay. We'll add that one as well. I thought that was the Linksys one. No, Linksys is the Velop. So here's one thing interesting to know about these things, and I'll go over this quickly, and you guys can jump in on anything. So the Netgear Orbi works more like a wheel and spokes. So you have a central, and then everything has to attach to that central one.

So it's not a true mesh network. It's more like a central repo and then other things can hit it and expand the network out from there. But you're stuck to one link away from that center hub. The Linksys Velop on the other hand is a true, you know, hook up your internet wherever you want and it'll pass it along. So you can literally chain them together and it'll push it across the network. So I thought that was interesting. I've, you know, I'm having mixed love hate with the Netgear Orbi and maybe I'll go into that later. I don't want to jump into it right now. Maybe I'll even do a review on YouTube. How about that? That's probably the best thing to do. Uh, so yeah, I know there was a lot of a lot of a lot of love in the slack channel for the uh ubiquity

amplify um the one caveat though is that if you that i ran into is that if you wanted to be able to plug those extenders into if they wanted the extenders to be wired into the network then they weren't that specific unit wasn't set up for that it's all wi-fi yeah like some of them um like i believe the orbi has um plugs on the on the extenders uh the google wi-fi you can plug you can wire those extenders into the network as well that way your extenders have like the best possible signal strength um you know that know, that they could give outright. So it depends on like what your, your situation is. Okay. Yep. So all cool stuff. I think, I think I'll do a video review. I don't know. Maybe, maybe cause you've got the Google one.

You're pretty happy with that. Yeah. I mean, it's stupid, simple to set up. It's I'll, I like that. I can manage it from anywhere, right? You know, it's tied to your Google account. It's super easy to share that configuration with with like your spouse or someone, you know, because you can just assign Google accounts that can manage it. And so, you know, if you're already if you already use Google services and you already trust Google, uh, they already know everything about you anyways. Why can't they manage your wifi? Yeah. And they do a pretty good job with it.

So. Yeah. Very cool. All right. So that was a cursory jump into that. Just want it like, you know, anybody that's out there searching for things, you know, be aware of them before you go buy a new router, because you might find something that will fill up your space better with the digital waves.

All right. So I'm not really sure what we want to talk about tonight or what this episode should be. Are you kidding me, man? Are you kidding me? Oh, clean architecture is out.

Yeah. We're one of the lucky few that actually got copies of it. Finally came out. You know, what's crazy is like, we said that we ordered this and that actually got copies of it finally came out you know what's crazy is like we said that we ordered this and we all got it like within two days a lot of people on our slack channel were like yeah mine's showing that it's not getting here till the middle of october yeah if you live in germany or even uh i think uh in europe it sounds like it might be even sold out so you go crazy yeah you guys will have to have bad architecture until then that's that's the key well it'd be kind of nice maybe if we sent somebody one i think we might

be able to arrange that yes i don't know i think we've done crazier things in the past so i don't see why we wouldn't do it this time yeah we talked about doing it before the show but we never uh we never settled on uh yes or maybe i was in the bathroom anyway um now that we've mentioned it i guess we got to do it so if you'd like to win a copy of clean architecture if you leave a comment on this blog post uh so that'll be codingbox.net slash episode 68 leave a comment and uh after i don't know a couple weeks or maybe some amount of time we will look in in there and pick a winner and send you a book. So full of definitive information.

So you'll either get your book from us first or from Amazon. Yes. We're not sure which one we'll get to you first. Yep. All right, cool. So let's go ahead and jump into it. What do we got here? All right.

Well, first, I just want to tell you a little bit about the book um we were going to actually talk about and continue on our series on uh object oriented anti-patterns but we got a lot of comments we got a lot of uh people talking in slack about the book and uh twitter and some people just kind of expected us to do it and it looked like a great book and it um kind of tied back into some of the ddd stuff we were talking about kind of higher level and so we just couldn't resist so we kind of rushed order to get the book and like mine just showed up actually just uh i don't know like five hours ago something like that so i had to speed read through the first couple chapters there um but so far i've been really liking it and um it

is part of the robert c martin series which means it is officially tied to CleanCode, CleanCoder, and the software Craftspin, which I'd never heard of that one. And we can all agree we like these, right? Like these are excellent, excellent books that we've all looked at. I've only read this would be my second one, so

I haven't actually read CleanCoder. Cool. Maybe that'll be on the docket here in the near future. Yep. We'll see. And I did notice on the back of the book it's built for architects analysts designers and managers but so far what i've been reading through it doesn't seem like there's a real like firm kind of role uh enforced at least the first couple chapters where they're you know they're saying like this is what developers do this is where architects do like so far as best i can tell it's just really about like good design maybe we'll jump into some more of that but so far like i don't see why a programmer

any programmer would not want to read this agreed you know one thing i'll say about this compared and contrasted to the ddd book, this is enjoyable to read. Not being mean, it's not so overly wordy and so buzzwordy that it turns you off, right? Or you feel like you need to have a dictionary sitting next to you so you can look up what every single word means. It's told in a way that is, this is what you experienced, this is what you've seen. It feels like a story as much as useful information you know yeah i think ddd was uh it was just really thick and there was a lot of stuff to kind of wrap your head around and i still kind of want to go back and reread it and

make sure i get it and it was just um a different kind of book but i mean clean code like i still think about it i still reference it it very much resonated with me i think about it all the time i think that's why there's been so much hype about this book is that i think people are kind of hungry about architecture i think that the problem that most developers face isn't necessarily you know how many spaces lines and you know tabs for spaces or semicolons or not but uh it to me at least i think it's more about like how do i keep adding features without digging myself into a hole? And I think this book aims to address that. And it's written by someone who's very highly respected and has written fantastic books. And so I think everyone's really excited about it, including me.

Maybe it's just because this conversation in the Clean Code series is more abstract. And therefore, you can talk about it in more general terms versus DDD is getting ultra specific and granular. And so in order to stay with the continuum of the chapters, you have to like keep building upon the things that were very specific. Yeah. Maybe just speculation. I think it's a writing style though

for me anyways yeah trying to be nice to the author here yeah i mean he wrote some stuff that people use and you know we're probably going to dive back into it at some point we've just taken a little hiatus he invented a thing that is like well known and received so right it's a big thing all right cool yeah he's been programming since 1970 things were um different and things were kind of the same too and that's one of the things he kind of talks about with architecture and programming it says um that at least with architecture it's completely independent of every other variable meaning that like software architecture in 1970 isn't so much different from 2017 and so programming isn't so much different from 2017. And so, programming isn't really that different either.

Like the tools have certainly changed a lot, the methodologies, the way people do stuff. But at the same time, you know, like if statement or loop, you know, in COBOL doesn't look that different from whatever language you're looking at today. And so, I think that's part of the kind of speaking to those principles that we just kind of alluded to. Yeah, there was a comment, there was a quote in this book where it went back to something that I think Joe had mentioned several episodes back, and I don't remember the episode or what the conversation was at that time, but do you remember talking about coding turtles? Yeah, turtles all the way down. Yeah, turtles all the way down. And I don't remember what that was in reference to, but there was a quote in this book where he mentioned that, you know, he was talking about how it's in the forward where he's talking about like, you know, we often refer to the canonical reference of software architectures to compare it to building something physical, right? But the difference in building a house is that if you build a house, I mean,

you have some wood, you have some concrete, you have some metal for things like nails and screws and wires, and it's all a bunch of different stuff. But software is built on top of software that's built on top of software. It's turtles all the way down. And that's awesome. But houses don't change typically either, right? Or software does. And that's where the analogy always breaks down, right? Well, no, he actually did cover that too. Because you could add on to your house. You can add on.

You could change and tear down things. I mean, that kind of stuff does happen. Yeah. Not quite as frequently, but yeah. Yeah, more than I like and less often than my city of other likes. So one of the things he said in here that I thought was really cool and interesting and so true because I've heard it happen so many times is writing the initial piece of software isn't hard, right? Like he even said, there, there are companies built on just making something work, right? You cram it together, you slap it together as fast as you can by sheer willpower, you make something, and it might be worth millions of dollars.

I loved that term, by the way, because I'm like, oh, that's how I do all my code. I will make this happen. I will figure this out. Yeah. And that's not really all that hard. And that makes sense. I mean, honestly, sure, there were probably a few bumps along the way, but for the most part, getting that first thing up and running isn't the worst thing in the world. But then he goes on to say that making it

maintainable and extensible and something that you can manage over time is hard. And that's what this is all about. Yeah. I love the first part of the book is really kind of setting up why this stuff matters like why does good architecture measure matter like what do i take to my boss when i say i need to refactor something like what am i explaining to him like the the benefits and detriments of not doing it are and um it gives a nice succinct definition in that kind of introduction here and says that, um, that good architecture means that effort is minimized and functionality and flexibility are maximized. So I can make changes easily and the benefits of those changes and the

benefits of being able to make those changes are, are, uh, maximized. Yeah. And, and the, the angle of this,

he was also saying was reduce the number of people you need to actually write these things right that's that's yeah so important go ahead yeah it's kind of funny like the whole idea of being a programmer writing yourself out of job as being the the goal i think we've joked around about the format like it really does make a lot of sense like you know the the and we've talked about this with, I don't remember what we talked about, but basically adding more people to projects, making things more complicated, more communication. Nine people can't have a baby in one month. I think that makes sense. If you can keep the number of people down,

if you can keep the lines of code down, if you can keep things simple, then win, win, win. Another thing. I don't want to get fired. Right. Well, I mean, the thing is, the reality of it is, if you write good software and you can iterate it on it quicker because you made it more maintainable and all that kind of stuff, sure, there's not going to need to be as many people maintaining that thing. But that means you get to work on newer, cooler stuff, right? We've talked about the greenfield versus the brownfield. And a lot of the times, the reason you're stuck in brownfield is because you're maintaining a pile of mess, right?

If you make that thing to where it is maintainable and you don't have to spend tons and tons of time bug fixing and all that. You move on to bigger and better things that can make the company more money, that could be more revolutionary, could be whatever. So I thought that was interesting. Another thing here, though, that he brings out in this book and I love is he's like, this all sounds utopian, right? This all sounds like this place, this golden place that doesn't really exist. And he's like i've been there right doing it right exists and when you do it right then it feels weird because you're

not fighting all these battles all the time and so that's what this entire book is about is how do you get to that right spot right yeah i think the sad reality is of a lot of green brownfield projects is that a lot of times we made it that way you know like how do how do brownfields get brown like we we poop them up the developers right that's not management that's not anyone else like we literally changed the code we made the mess we made the bed and we're lying in it but we're gonna get to that let's, though. Brownfield doesn't necessarily mean that it's crap. I mean, the brown isn't necessarily referring to it being crap, right? Not true.

It's just that it's older code. That's a good point. It's usually a negative connotation that comes along with the brownfield, right? Yeah. That you're talking about. But I mean, you could have something that was like written in great patterns of whatever the technology was at the time that, you know, you don't hardly have to touch because it just works and it's functional and yeah and if you do have to change it you know every now and then you know easier to do but but you're probably not going to

complain about brownfield at that point because you're not going to be spending that much time in it right so i think it's the negative connotation that typically comes with it not necessarily you know i think it's also too like we developers see that the new shiny and we so badly want to play with the new shiny i don't know what you're talking about well no i mean not you not you specifically never yeah yeah no this is awkward but no you're right yeah brownfield does not specifically refer to uhritus. I did not know this. This is something I learned today, TIL. Hey, wait, yes, yes, no.

I know what TIL means. TIL? Oh, today I learned? TIL, yeah. You always accuse me of not having known that. I didn't hear what it was and then, yeah, okay, sorry. Yes, I've seen some of the interwebs. All right. Excuse me. I didn't hear what it was. And then, yeah, okay, sorry. Yes. I've seen some of the interwebs.

All right. So the next part here, this is actually jumping into chapter one here. What is design and architecture? You want to kick us off, Drew? Yeah. So what is the difference between design and architecture? Do we need to guess? Is this a game?

You can guess outlaw. Oh man. Why did I put myself on the spot? Um, design would be graphical and I got to make things pretty. And I care about, uh, the color palette and the placement and the flow of things in architecture. I'm going to say is,

um, and the placement and the flow of things in architecture i'm going to say is um i care about the model and uh data structures and am i anywhere close joe or am i drowning i think in this contest specifically uh we're pretty far off but i think it's just because he didn't erase those lines and i know that you knew that and you knew that you knew that um but uh yes i read that usually when i refer to design uh that's exactly what i'm talking about but in this case we're talking about software design software architecture and uh what what he said was uh and i thought was interesting saying there is no difference if you are a software designer you're designing a system then you are architecting that system those Those words can be used interchangeably. And so I thought that was kind of a cool way to kind of erase some of those lines

because I think a lot of times when people think about software designer, they do think about the art. They think about like the soft, fuzzy kind of, you know, adjusting pixels and CSS kind of stuff. And when people say architecture, they kind of think of like the guy locked in the corner office who, you know, comes out and says, it's not my fault and then goes to lunch.

Wait, that's the architect yeah man wow she's like it's not my fault you can't follow my immaculate designs uh i gotta go to lunch i wrote a 17 page wiki on it you know it's funny though i love this because it always bothered me because i was like if you say that you're designing something it's the same thing it always kind of bugged me that I was like, if you say that you're designing something, it's the same thing. And it always kind of bugged me that there was like this line there. And I like it that he called it out and said, no man, if you're designing a system, it's the same thing as architecting it,

right? Like you are, you were figuring out how those pieces go together in a way that's not going to destroy you down the line. I like that a lot. Yep. And so to put it another way, measure of design uh quality then is the measure of the effort required to meet the needs of the customer so i'm sure we've all given this

analogy to someone where you say like sometimes you want a checkbox and it's a checkbox it takes me five minutes sometimes you want a checkbox and it's like the end of the world right i gotta change so much stuff and so um what we're saying kind of a little bit, you know, of course, my analogies are always, you know, mostly wrong. But what we're kind of saying is that the difference between how much time we think something should take because the customer doesn't think it's a big change because it's not a big change to their conceptual model and how different that is to how much it takes to actually implement that change. That is the measure of design quality. Yeah. So to revisit what you're saying, the way that he put it in the book that was really cool is product manager comes to you today and says, I want this feature, right? And then six months down the road, they want another feature that in their mind is very

similar to what this feature was. And you say, it's going to take twice as long. And you're gonna be like, why the heck is that going to take twice as long? It's kind of the same thing as what you did six months ago. And then a year down the road, they're going to want something that they feel is like about the same scope. And now you're going to tell them it's going to take three times as long. And that's what we're saying.

That's the measure of it. If every time new features or changes need to be introduced in the system, but the time to do this goes up drastically every time you failed at your architecture, you failed at your design because it should not be that kind of, you know, exponential rise or even linear rise of the problem. How else are you supposed to bake in your Reddit reading time, though? Yeah. That's a real-world problem there.

I was really asking. So, yeah, I mean, that's literally the identifier. And let's be honest, right? We've all seen this. Like, that's literally that's the identifier and and let's be honest right we've all seen this like that's how it happens a lot of times a lot of times yeah and i get it i mean they talk about the shape and the scope uh in particular and kind of the shape refers to um kind of like what the code actually looks like right it's like you know where the files are the actual um you know i don't want to say physical but you know that basically uh what the implementation is and then the scope is

like the conceptual model and so if somebody says like oh customers should be able to go back to accounting then and do something then that you know is like drawing lines in their heads from box to circle or whatever but when it comes to the code you know we know that might end up being like 44 different files and then deleting this folder and you know a big pain in the butt and that's a difference there in between the scope or the domain and the actual physical code um i used a word i didn't want to dang it but if you know we talked about um triple d uh domain driven design and that whole book was really around keeping your your code really close to the model and mimicking that and so that when they want a change in scope then that change isn't so different in the shape and you can kind of keep these two worlds somewhat in sync yeah keep it close to the business need

that way it makes sense hey one of the things that we called out here in the show notes and and really is cool and i highly recommend picking up the book at least so far as we've gotten like they have a he has a ton of graphs in here that shows some some interesting things like uh some case studies where an engineering staff increased by, geez. I want to know what company this was. Right? Like eight or 10.

I know. Yeah, they anonymized it on purpose, but it looks like eightfold almost, right? Maybe tenfold. Well, at one point, the cost of development, he was talking about how with bad architecture, they were able to chart out how the development effort um as the developers were small you know everything was okay but then as they would like ramp up the development team

that there wasn't an increase in code that it actually kind of flatlined the the amount of code flatlined if you just considered code as lines of code um which maybe there's some argument to be there about productivity whatever on one of the graphs it was actually productivity well the flatlining one though i thought was the was um lines of code yeah it was it was lines of code but the the um but he goes into the car but it also includes the cost of the development and in the beginning for like release one it was you know the monthly cost was a few hundred thousand dollars per month to pay the developers to do it and by the time you got to release eight it was 20 million dollars a month to pay the development team what company could this possibly be and it was climbing and yeah and that's

the kind of stuff that they see like they even so the productivity per release went way down because it was difficult to maintain um as they ramped up the engineering staff the the productivity flatlined like literally they they it looks like a 10 times increase, maybe 20 times increase in the number of engineers, but the productivity just completely flatlined. Come on, give me a guess as to the company. That's all I've been thinking about this whole time. This was Microsoft during the release of Vista.

I don't know. No? No? Okay. Let's see if it gives it a deploy count. And I don't want to give away too many numbers on the charts because you should really buy the book and read it. Oh, yeah. Hold on. I'm going to give you another number from the chart.

Two. Two. I'm just giving away a number. Yeah, there we go. No, I'm curious. I'm looking for it. So in eight years, we went from basically a handful of employees to 1,200. Who could that be? Well, we don't know what years. 1,200 employees could be anyone. Yeah, we went from basically a handful of employees to 1,200. Who could that be?

Well, we don't know what years. 1,200 employees could be anyone. Yeah, we don't know what years. We don't know anything about this. We just know that the releases, one through eight, he didn't correlate that to time. But one of the interesting things that he points out, and I think it was even earlier in the chapter, was this is where you have to be careful. Where you see trends like this, it's not just a development team, right? Like as upper management looks at this stuff, they're going to go,

holy smokes, man. Like we're not getting any features, but we're spending the same amount of time. And, and, and uncle Bob here even says, this isn't because developers aren't working. If anything, developers are working their tails off. But the problem is the architecture doesn't support making these changes. And so now not only are developers working their tails off, but they're frustrated because everything feels like a grind, right?

Like everything's an uphill battle. And honestly, if you're the, you know, he caught out the CFO in this, like if you're the CFO and you have, let's say, let's say you only had 20 developers on your team, right? And you're looking at that 20 developer and you're looking at this chart and you're like, well, you know what? I have the same level of, you know, productivity when I had 19. So why don't I just go ahead and only have 19, right? That guy, it's his job to start scaling that stuff back, right? And the problem is, is mentally that makes sense for somebody like a CFO, right? Because you're looking at numbers, you're like, well, okay, well, if we just move this curve back

down, but that obviously wouldn't work. Right. Because now you're going to have 20 people just spinning their wheels, trying to maintain however much code was written by those, you know, 1200 engineers. So it's, it's a real, real problem, right? Like, and, and it's something that snowballs. People hear that all the time but when you start writing code that's not maintainable and and you're rushing to get it in there it snowballs there there was this quote related to this section that you mentioned about like uh it wasn't the it wasn't due to the efforts of the developers you know it wasn't that they weren't doing hard work and he actually referred to it as the heroics of the developers and the overtime and dedication

but he says that you know the problem is that all their effort has been diverted away from features and is now consumed with managing the mess. Yep. And that's, that's unfortunate. Uh, we've all seen it. At least all three of us. I know we've seen, um, you know, in multiple places, right? And sometimes it's not the entire app. Sometimes it could just be a portion of the app that you're just like, Oh God, please don't ask me to fix that part of it. Like I'll, I will literally rewrite any other part of it, but let's just leave that one alone. Yep. Yep. Please don't throw me in the briar patch. Yeah, man. I, it looks like both of us wrote down something in here to where one of the quotes is the lie that we tell ourselves and that the product management team tells us and that we internalize is we can clean up the code later, but we got to get this to market first. We got to be so-and-so to market or we have to get this to market.

And the problem is that is a total lie because after you get that one to market, the very next hot feature is going to be on its heels, right? You never have time to go back and clean up that code. Rarely, seldom, if ever, do you? Because you're always trying to chase that market. I had a thought on this. So I wanted to read this quote from him. And then as soon as I read this, like a thought came down, I just had to like pencil it

in. But he writes that getting to market first was going on with what you just said. Getting to market first simply means that you've now got a horde of competitors on your tail and you have to stay ahead of them by running as fast as you can. And it made me immediately think, have you ever noticed that sometimes like company X might come to market first with some product, but company Y is the more successful. And it made me think that maybe this is why we see the second competitor be more successful in the long run, because they weren't pressured to be first. They were able to think more about design, which allowed them to think about the structure in a way that they could iterate faster. That's possible because eventually they're going to be the tortoise, right? And the tortoise and the hare, they're going to pass them slowly but surely.

Yeah, because they don't put that undue pressure on themselves. They're like, oh my God, we have to be the market first. We have to get this done. We have to be the first ones to solve this problem. But this does kind of fly in the face of what a lot of programmers have been saying for a long time about focusing on the MVP, about performance being optimized too early. So it's definitely kind of internalizing the culture that we should release

early and often and get this stuff out. However, I've read the whatever that book was with the MVP, I can't remember the name of Lean Startup. Lean Startup, yeah. Nowhere in there did it say you should sacrifice on infrastructure or quality. It said you should sacrifice on

features. You should pare it down to the least set of behaviors and features that make sense but nowhere in there did it say that you should sacrifice on architecture no that's true so in other words alan's doing it right when he scales it out his application for a billion current current users definitely absolutely i mean you like you look at these charts it's a scaling problem absolutely like things are great when it's you know when you're first starting out and you got one two three you know releases like it's not so bad but as things go on

it's just you start to see that curve level out and it just gets to just insane levels and it's just totally unsustainable so well there's there's a couple more things in here that i want to point out that i don't think we wrote down um but this whole thing about, about us as developers, if we just bang it out fast right now, we can, we can go fast. Right. And, and it'll slow us down later, but at least right now we can go fast. That's actually a falsehood by what he says. And it sort of makes sense because he put it this way.

And if you think about cleaning your house, your apartment, your car, whatever, this is so true. If you just maintain the cleanliness of the area, it's a thousand times easier, right? Like if you're throwing McDonald's bags in your passenger seat and they just keep piling up over there, guess what? You are going to have a nasty mess when it's over because it's not just going to be, Hey, you got to get rid of those bags. Now you got stains in your seats. You got stuff all over the place, right? It's going to take a lot more effort. It's the same thing with code, right? I mean, it really happens that way. If you let that stuff pile up, it's going to get to a point to where it's very difficult to clean up. So I thought

that was awesome because it's so true. If you maintain the cleanliness and then he goes into, it kind of goes along with the thought that, you know, some people make against awesome because it's so true. If you maintain the cleanliness and then he goes into, it kind of goes along with the thought that, you know, some people make against testing where it's like, Oh, we don't need to, we can test it later. We don't need to write tests or whatever because we can come back to that.

But it kind of went along with the sentiment of the TDD approach where it's like, you know what, if you actually do your testing in, in the beginning, you're going to be able to iterate faster. And he actually had a chart here where a colleague of his did a test of writing code where we just spent a little bit of time each day. And on three days out of the week, he would, you know, write his tests first and do a TDD approach to it. And then and then document how long it took him to complete the amount of work.

And then on the other days of the week, three other days of the week, I guess he was working a six-day week, he would not take the TDD approach to it. And he was able to chart that there was an actual, you could see the learning curve in both approaches, but in the slowest day when he took the TDD approach, it was still faster than his fastest day where he didn't take the TDD approach in terms of being able to iterate and get something done to completion at some respectable time. By 10%, by at least 10% on each day,

he beat it with the TDD approach. So riding slower, but it ended up being faster, right? Because we all think, hey, if I just skip doing the test, I can do this faster, right? But he proved it. It sounds like a hassle. Like you got to set up that infrastructure or you got to set up that plumbing or whatever it is, you know, if it's a new project.

And if it's not a new project, then you're like, well, I got to make this new test. I don't want to want this new test to be yet, you know, in. And yeah, so it's you can easily see why it would be why you might think like, oh, let me just skip the testing. I'm not going to worry about the testing. I can I will skip the testing. I'm not going to worry about the testing. I can, I will write the testing. Let me focus this week on just getting the core functionality done. And next week I'll come back and write the test. But what's going to happen is next week, assuming you even got it done the first week, then you're going to be tasked with doing something else because you know, the, the customer, uh, whether that customer be your boss

or your boss's boss or an actual paying customer outside of your business, that test to them isn't a feature. It's not material to them. Yeah. They don't care. They don't know what exists. There's a better term for it that's not coming into my head right now. Yeah.

So this all leads into something, though, that I think, joe you actually put in here in the quote yeah did i put my name there no i did i did okay somebody's kidding wow uh okay uh yeah uh slow smooth smooth as fast which is uh like a military saying i don't know if you guys have heard that before um i read it in a book recently um and uh actually another quote the one you're probably referring to is the only way to go fast is to go well and that one was actually from this book but both are kind of speaking to the same thing where if you are rushing around frantically trying to do stuff you're going to make mistakes there's going to be stuff to pick up afterwards it's a big mess this is also kind of the the main point behind the uh the infamous or famous um

toyota like the the new me plant whatever the andon cord you know the idea was previously all those car companies would rush everything to the assembly line because stopping the assembly assembly line meant stopping the production it slowed the numbers down and they would kind of fix their mistakes afterwards but toyota had a different approach where they would actually stop the problems as they and deal with them as they arose and that ended up being so much faster and so much more efficient in the long run and we've heard similar stories i know pat flynn's got a similar story to like doing wedding announcements and stuff and i found um it was faster actually to do each one individually rather than trying to kind of do all the folding do all the stamping do all the whatever

and it's just the same kind of deal whereas if you kind of take the care and have the patience and kind of do things slowly they end up being a lot faster in the long run but the thing is it's a convenient story to tell or is it rather as a sort of convenient story to go along with when you're you know your boss or your manager whoever wants something done faster and you know there, there's a little, you know, a little if statement, a little hack, a little, you know, flip of the wrist that you can do and get it quote unquote done. Then there's a lot of pressure to do it that way. And the only one who a lot of times can say, hey, that's not so great is another developer who's got their own pressures and lives to live and probably isn't looking over your shoulder. And so's kind of like you know you've got the devil on your

shoulder that wants to go home and just make everybody happy and and close the ticket and then you've got the angel over there that nobody else can see nobody can hear nobody will ever know about um so it's it's hard to do the right thing and there's no one else really to fight with you a lot of times it's it's kind of up to you to defend uh what doing it right means and why it's important yeah and this is where the one of the conclusions is so what's the answer did you rewrite it that's the answer that comes up a lot right yeah he says that developers think the answer is to rewrite it from scratch right you know one thing i was reading about when i when i read when i was reading this book or one thing i thought about while i was reading this book

was that um basically he wrote this book for whatever company you're working at while you're reading this book totally this this applies to your company. I'm sure. I'm sure of it. That's not ours. But to Joe's point about like, you know, the responsibility thing,

he has a statement in here in, you know, skipping ahead to the next chatter where he says that the business managers are not equipped to evaluate the importance of the architecture and that it's the responsibility of the development team to assert that importance of the architecture over the urgency of that feature. Yes. Right.

And we need to jump into that deeper in a minute too, because I think that is so incredibly important. I do want to point out though, that the term that I was looking for was non-functional. Oh, okay. Yeah. Non-functional. Yeah. Yeah. Yeah. Non-functional. Yeah. Yeah.

There was a race condition in my brain, so it took a minute for that one to get there. But it eventually got there. But the Semaphore, it kept everything good, right? Yeah. All right. So the thing on the rewrite, and I love this, he says, no, that's not the answer. And just about any time somebody says rewrite to me, I get a little vomit sick. Like, you know i feel

some bile rising because it almost never works out like twitching yeah yeah the seven minute abs oh six minutes well what's always really funny to me is like a lot of the team a lot of times the people proposing the rewrite are like a big part of the reason why things got so poopy to begin with right those people who've been maintaining this thing and not fixing it up not taking the time to push you know not taking the energy to push back and kind of fix things as they went along so what makes you think it's going to be any better and they say he even says typically it won't be right because you're gonna have you're gonna have so much overconfidence that oh i'm rewriting this thing i'm gonna make it perfect and you're not going to take the steps necessary to not make it a mess. And so you end up in the

same situation you were at before. So rewriting is typically not the answer is what the gist of it is. Yeah. And you end up right in the same trap where like the first couple of days of rewriting feel amazing. And that's kind of the trap of it is like the first portion of that rewrite just feels so great. You're moving so fast. You're replacing large swaths of the system. But as you get into those little edge cases and those little weird things and those bugs that you didn't think were bugs. And then next thing you know, you're right back where you were. Except now you've got two crappy systems you're trying to maintain somehow.

Yeah. And now you're probably going to be under more pressure because you put yourself out there as, hey, I can make this better. And so, now you're probably going to rush things even more because you want to prove that you can do it faster, better, all that kind of stuff, and you're going to cut corners. Yeah. Oh, and we didn't talk about the hare and the tortoise analogy that you used quite a bit through here, which I'm sure everyone's familiar with the story. But the idea is that the hare thinks he's so fast he's gonna win the race no problem so he ends up kind of slacking off taking some breaks taking a little nap whatever while the slow turtle who's racing against him like plods along and eventually wins the race and i never thought about it this way i don't know why my entire life i'm questioning what i

thought people were saying when they used the expression harebrained but they're referring to people using like you know kind of like the reptile the hair brain you're you're doing your short-term thinking you're overconfident and you're not just focused on your task i always thought hair brain meant you're just an idiot but that's fine that's what i thought too i googled i was like wait a second does hair brain being like you're thinking with your hairbrained, like the hare and the tortoise? The answer is yes. Is that really?

We got to fact check you over here, Joe. I never thought about it either. Coming in live from Georgia, we're fact checking now. Wikipedia says. A rash decision. Actually, this is coming from Dictionary. Something. And I would have, if you had asked me to spell, if you had tricked me before I read this book,

you said, hey, how do you spell hair brain, Joe? And you hit record. I would have spelled it A-R. Spelled like hair head. You mean A-I-R? Yeah, that's what I was thinking. Hair. Well, he would have spelled it his way.

He would have spelled it hard break. And then autocorrect would have corrected it. He would have gotten there. We need to autotune for our spelling. All right. All right. So, yeah. So, really, the key takeaway here is not rewrite to the answer. None of that's the answer.

The answer is start taking your quality seriously. That's where this ended in chapter one. Yep. So I want to take a few minutes here to ask you to please leave us review. We really appreciate it. There are a variety of platforms and you can go to codingblocks.net slash review. And there's a couple of links there. And if you don't want to install iTunes, that's fine.

We don't either. And there are alternatives.'s stitcher there's pod chaser and we really we really love getting that and it helps for the show and it's just really meaningful and we're very thankful for it so if you've done it thank you if you haven't please consider it and coding box.net slash review is the way to do it and a huge thank you to everybody that did it this past time we had quite a few come in and that was that was awesome so thank you it really does mean a lot to us and with that it's time for survey says bing all right so last time we asked, how many different podcasts do you subscribe to? Your choices were, there can only be one, which is obviously coding blocks. I mean, that only makes sense, right? Yep. Less than 10, YOLO. Less than 25, less than 50 and less than 100 all right so i'm gonna go with you first joe which one address the controversy we should we should i think you need to okay fine let's start

with the negativity yes thanks joe i don't know if i got negative i i call it amazing i call it impossible i do too i call shenanigans that's what i'm calling i don't know i'm up to 47 now and that's three more than last time there's only a couple weeks so i mean it happens but we did get a few people writing in uh and saying that they listened to over 100 which is just astounding to me that's crazy that's insane yeah crazy town even if each one of those, even if you listen to only exactly a hundred and they were each, and what 30 minutes long, that's still 50 hours a week.

That's a full-time job of podcast listening. And even if you double the speed and listen at chipmunk rate, that's 25 hours, 25 hours. Yeah. That's almost as a part-time job. Yeah. But if you skip the news, you can get that number much, much lower. Man.

That hurt, dude. Just kidding. That's like a dagger right there. I can't kick him off this podcast. I'm trying to figure out how. Well, I was going to say you can't kick him because he's not. Hey, guys, if you're listening to this episode, just fast forward to the 20-minute mark and you'll totally skip the news. Oh, man. And if you're an advertiser episode, just fast forward to the 20-minute mark and you'll totally skip the news. Oh, man.

Whatever, man. And if you're an advertiser, totally ignore what he just said. That's right. We would never endorse that. All right. And you like how we tell them at like minute 50. All right. So, Joe, with all your negativity, which one do you think was the most popular and what percentage?

Only one. Less than 10, less than 25, less than 50, less than 100. Less than 50 at 40%. 40%, less than 50. Doggone it. I'm going less than 50 at one. At 1%? This is Price is Right rules, man.

Yeah, you're right.'re right yeah price is right rules uh where we mix you know multiple games survey says yeah right price is right uh the price is wrong yeah right no don't finish that quote for anyone who doesn't know what we're talking about watch happy gilmore go Go watch Happy Gilmore and laugh. All right, so both of you think that the most popular, you really think that all of our listeners listen to more, or I'm sorry, under 50 episodes, but that obviously implies greater than 25.

Subscribe to. Subscribe to. I don't think they listen to. Subscribe to. Subscribe to. I'm sorry. Subscribe to. I think so.

So I guess that you're leading the jury here. No, I just misread that. Yeah, don't. But you're wrong. Both of you are wrong. Is it less? Far and away, the answer was less than 10. Really?

Wow. Dude, that's exciting. Thank you for listening to us as one of your 10. We are 10% of their important subscription. When you say far and away, are we talking greater than 50%? Oh, okay. Well, now who's being negative? No, it was 47% of those surveyed were less than 10. Well, I'm not going to recommend any more podcasting.

Cause you get one of those in like, this is a good chance. We're coming out. So this is a stack. Yeah, man. Y'all cutthroat. No,

that's not fair. There's a frigging survivor over here. We just got voted off the island. No, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, voted off the island no no no we're still your torch has been put out all right all right so on this episode survey we ask how often should your employer replace your computer? And your choices are every three years because you got to respect the money. Every two years. Come on now.

Or every one year because I deserve it. Or who stays at any employer long enough to have that problem? And lastly, wait, they're supposed to replace it. So just so you guys know, this will be an anonymous voting as they always are. They are all your votes are safe with us.

Yes. Do we want to add a four to five option i'm kind of scared of not representing now what four and five year options yeah oh fine we'll say well how about if we just say greater than three yeah greater than three i like that all right greater than three seems very nebulous like 10 years i'm upgrading my 486 DX two this year. I mean, I'm sure your laptops are three years old. Come on.

Wait, no, we're not talking about personal. I'm not. We're talking about your company. We're talking about your employer, what your employer should do. Cause like our,

our personal, that makes more sense. Cause it's not going to get the daily use that, you know know your work computer does now if you're self-employed if you're self-employed but that's where you are the employer yes so this question still applies to you so don't try to come at me with any shenanigans about like well i'm self-employed so it is my personal no you're employed you're employing yourself all right all right just real quickly here um we don't want to uh we're trying to let me just tell you let's like let me spend 10 minutes tell you about how we're trying to save

time anyway preach it brother moving along uh google feud i've got one quick one which i just happened to look at the other day i thought it would be fun to do on the show so let's try JavaScript is outlaw you want to go first no this is your opportunity do not miss this chance to blow okay so all spaghetti right thanks Eminem

JavaScript is um JavaScript is like Java. I'm trying to think what the most common Google search is going to be. JavaScript is always changing. I'm horrible at this. This is why I ask you guys the questions. JavaScript is popular. JavaScript is popular.

JavaScript is popular. Alright. You guys are so far off. It's amazing. Yeah, I'm sure. What is it? Do you want me to tell you? Yeah. Alright. Well, JavaScript is... Hold up, hold up. Hold on, hold on. Before you do Well, JavaScript is. Hold up. Hold up. Hold on.

Hold on. Before you do this, there was somebody I ran into and I cannot remember his name. That's horrible. But when we did the Atlanta Code Camp, he said a suggestion, open up a private window and run the same query. Because maybe Google won't do it. Although I said that maybe by IP address, they're still hitting it that way, but no, no, no. And when I've done the Google feuds in the past, I've always done it in cognito window to see like what, what Google will come back with. So we've been doing that. All

right. So do yours incognito, sir. All right. Got it. Pretty much the same. Got it. Okay. Probably because they're looking at your IP address and they're like, this is JavaScript is amazing. JavaScript is hard. JavaScript is javascript is amazing javascript is hard javascript is stupid javascript is uh you're cheating by the way i know i'm thinking up the top of my head like what would these search what would google searches be all right i'm just gonna go ahead and lump those all together and give you a big fat no on all of those not nowhere i'm not good at this all right so here's what it says so if i do javascript is and no space afterwards then i get things like javascript is nan is numeric and then then we start getting into other stuff eventually is set is defined but. But if I do JavaScript is space, I basically use the same kind of thing.

JavaScript is array, is null, is string, is integer, is numeric, is numeric, is undefined, is defined, is not a function, is not null. So I thought it was really funny for, you know, a weakly typed language, you know, a dynamic language. I see where you're going. Yeah, apparently it's just the programmers are the compilers. The programmers are the ones checking for error, and they're using tools like Google instead of a compiler.

So I thought that was really funny, and I never would have guessed that. But, dude, this is ridiculous. Come on. That's where they went wrong. This doesn't make sense. They should just have used Stack Overflow. I feel like they need to talk to, what was his name again? Mikey Don?

No. Yeah, Mikey Don. Mikey Don. Yeah, he's the one that authored the book on copy and pasting from Stack Overflow. Well, next time someone says, hey, I don't got time to learn TypeScript, you just say, that's your harebrain. Your harebrain thing. Hey, wait a second.

Wait a second. So, funny for you. That's your hair brain. TypeScript is not a module, is array, is not a function, not a constructor, string, not assignable to type. So, it's the same garbage, man. Okay. Oh, man. I am so used to that comment.

Somebody says something to me from now on. That's your harebrained speaking. You got to put son at the end there. I love the way that he pointed at the camera when he did it, too. It's like, that's your harebrained talking. Yeah. You got to check out the YouTube video for that. Oh, man.

All right. Well, let's get into chapter two. Yep. A Tale of Two Values. Yes, sir. All right. we're done. That's it. Yep.

So two values, the two values that we're talking about here are basically structure and behavior. And when I'm not used to those terms in this context, I'm used to words like features and architecture or features and non-functionals. But they're kind of the same things we're talking about here. I didn't really detect any sort of major difference between those concepts i don't know about you guys no it's the same okay and i think what they're saying here is really stressing the beginning is that both of these are high in a good project right we like we want a lot of features and we want really solid features and we want a lot of structure. We want a lot of architecture, which I thought was interesting. He didn't say good or simple or clean kind of said a lot.

No, no. I think it was, it needs to be a high priority, right? Or high importance. Okay. High importance. Yeah. Okay. So I'm, yeah, I'm on board with that.

I think that makes more sense. Yeah. Cause a lot, a lot of architecture isn't necessarily a good thing. Yeah, this seems really silly now that I've said it out loud. Dude, one of our good buddies, Will, I'll never forget at one point he had on his messenger something to the effect of, I hate abstraction for abstraction's sake or something like that Where there were like 20 layers of interfaces And he's like I can't deal with this So yes a lot of Isn't there like a quote though about that

Like abstraction for abstraction's sake is bad Or something like that I feel like Joe knows some book that has a quote about that Joe knows that feels like a Tecmo Bowl thing So You remember Bo knows? I remember that, but I'm trying to make the reference to the, the, the football game from Bo knows, like, um, don't tell, I know Bo, but no, no, that Tecmo bull, he was the dude

that you couldn't stop. Bo Jackson. If you had his team, you, you couldn't, you couldn't tackle the Raiders. Yeah. Yeah. But there were, there were, There was like a player like that on every team though. I don't know, man. Bo Jackson. Yeah, because who was the guy from the Buffalo Bills during that same time

frame? Oh, Thurman Thomas. Yes. He was the same way. Sports ball. Sports ball. I'm sorry. I'm sorry. I let the internet down. Dang it. There's actually thursday night football on right now it's running in the back of my head and i'm like oh man all right okay so uh yeah the two two different sides of the same coin right um behaviors and structures

and we'll just go ahead and use their terms for it um and one thing one good point it really makes about this is that software as opposed to hardware is called software because it's supposed to be malleable it's supposed to be easy to change the difficulty in making a change should be proportional to the scope there's that word again of the change not the shape of the change so if conceptually it's not a big deal then theoretically code wise and shouldn't be either and if there is a big discrepancy there then we kind of have to ask ourselves why or where we go wrong or have you know is has there been a miscommunication this whole time or have we not been adapting the shape of our code to beat the scope of our ever evolving scope yeah well said and um you know kind of nail that point home talks about the stakeholders meaning that you

know the heads of customer service or whoever is commissioning the product for you, they provide a steady stream of changes that are roughly similar scope, right? So they start off saying, I need this, I need that, I need this. Their requests three years later haven't gone completely crazy, right? They're not asking for things that are dissimilar from what they used to ask for, but now it's taking you, you know, a lot longer turnaround. I've seen this in pretty much every business and, you know, as things get bigger and more complicated, it happens that way. And I think the analogy that he gives is fantastic. Here, I highlighted it like three times. Yeah. From the dev's perspective, every time we get a new request in

we are rearranging the pieces of an ever ever increasingly complex jigsaw puzzle every new behavior that we add is additive to the problem it's additive the number of code lines of code that have to be maintained it's additive additive to our abstraction, to our model. And we've got to keep rejiggering that stuff. And it's hard as things get bigger, especially if we don't keep that shape and scope in sync. And this is where, by the way, like in the previous thing, in episode 66, when we were talking about time estimates and all that a lot of times developers

are pressured to get things done as fast as possible right and and ship it and that is completely why this happens right here because as a developer you're like man i'm being held to the to the coals on this thing. I need to get it out the door and it needs to be good, but that always comes with ever increasing risk, right? Because now you don't have unit tests because you tried to ship it fast. You didn't take the time to say, Hey, how can I make this thing fit in a way that we can come back and reuse it later? Or it's not going to be a problem and that's exactly why this thing turns into a jigsaw puzzle right in the long run that's really why it happens yeah and it's a total trap

too right as the shape and the scope get out of sync things take longer and so you have less and less time to go back and fix infrastructure type stuff because now you're telling them well that checkbox just like the checkbox added last week is going to take five times as long checkbox added last week, is going to take five times as long. And you can't say it's going to take five times as long. And I'm going to take a month off to, you know, add testing or replace the ORM or whatever. Right. It's never going to happen. And it's because you kind of worked yourself with your harebrained into this hole.

And there's not a good way out of it except to kind of own up to it and start trying to do better. Yep. And he brings up, like in this very next section, he brings up this almost contrived sort of ridiculous thing about, would you rather have a system that works that's difficult to change or one that's busted but easy to change? But when he says busted he basically means has no value right like it doesn't work that it doesn't work for the business and he said i would argue that you'd rather have the application that doesn't work at all but it's easy to change because then you can change it to meet the business's needs well he was

specifically saying in this section that like more than not, your management is just saying, it's more important that it just work. Yep. Right? And that's where he was taking this extreme approach of, do you want the one that works, but it's difficult to impossible to change versus the one that doesn't, quote, work, but you could easily change it. And he goes on to argue that yeah well actually i don't want to jump ahead so yeah i'm going to skip that we'll get back to it here in a second and i'll bring it up but yes so that was the whole thinking about the problem at the extremes and and what he says sort of makes sense right like if you can't iterate on the problem then it doesn't really work

out that well for you but But if you can iterate on it quickly, you could potentially add more value to the company. And I think he even pulls it out in a different way. Well, I was going to read the two extremes here because I really liked the way he put this. Going to this extreme example where one quote works, but you can't change it, and the other one doesn't work, but you can easily change it. And he says, if you give me a program that works perfectly, but it's impossible to change, then it won't work when the requirements change and I won't be able to make it work. Therefore, the program will become useless, right? So as time goes on and you want to add new features or whatever, and you can't, right? Versus if you give me a program that doesn't work,

that does not work, but it's easy to change, then I can make it work and keep it working as requirements change. Therefore, the program will remain continually useful. Yep. And I want to read like the last paragraph here where he gives the more because he even says that's kind of contrived. And some of you might argue that because it is super extreme. But then he gives the real world example. If you ask the business managers if they want to be able to make changes, they'll say, of course they do. But then they may qualify their answer by noting that the current functionality is more

important than any later flexibility. In contrast, if the business managers ask you for a change and your estimated costs for that change are unaffordably high, the business managers will likely be furious that you allowed the system to get to the point to where the change was impractical. So it's literally a catch-22, right? And that is the situation that often happens. But that's where we're going to get into this next section.

Have you guys ever been in a situation where you're working at a company and you get some sort of quote from a third party and it's just unreasonably high and you think basically they gave you the applaud way of saying no. It costs a million dollars and you think they're giving you the take a hike number. Maybe they're just really good at estimating. And they know that it's going to be more trouble than it's worth or, you know, it's going to be worth X amount of dollars. I think we need to be careful about talking about estimating because we don't know yet. No, no, no. Hold on.

I needed to whine and complain about it for a minute. Give me a second. We definitely need to come back to that one. Oh. Yeah, and give some positives for it. Yes. What to do about it um eisenhower matrix uh i always forget what this is called i i don't know why but it's it's the grid of four i'm sure everyone's

seen it by now where you've got like behavior or sorry behavior uh urgent in one corner and important in another and um well what are the other four squares. Important and urgent. There's important, not urgent. There's unimportant, but urgent and unimportant and not urgent. So it's that quadrant, right?

They fit into them. I've never heard of this. He's talking about this. Like I should have known about this. But one of the interesting things was this is what Eisenhower said. And this is the irony to it all. I have two kinds of problems the urgent and the important the urgent are not important and the important are never urgent so

it's basically that whole you know everybody wants something right now but they don't matter or the things that we do need right now nobody cares about and and that's what he's getting at here. And Uncle Bob here goes into this and he sort of lists them in order of what they should be important to software architecture. Number one was urgent and important. Two was not urgent and important. Three is urgent, but not important. And four is not urgent and not important. So basically, you know, you take your

highest priority, most important, most urgent thing all the way down to doesn't matter at all. Right. And go ahead. No, go ahead. No. So all I was going to say was he said, the biggest problem is when they invert, they move number three up to number one, they move what's urgent, but not important. And they try and cram it into urgent and important. Because that's typically what product teams are doing, right? Everything's important to them because they want it done. They want that feature in there. But it's our job to make sure that we keep those things in perspective, right? We need to identify, is that truly important or not, right? And it needs to be noted to the business so that everybody's in the right line.

So crazy, crazy thought. Everything that comes across via Skype, Messenger, maybe Slack, it's all urgent, right? It's all things that are kind of pressing. You're supposed to respond right now. And a lot of times that stuff isn't important you know the stuff in your your ticket system that's important everyone's agreed on the stakeholders are in game we have deadlines set but then we've got this little flashing thing in the corner but but it's hard to say though because what's urgent and not important to me may be very much different so outlaw sends me a message because he's having a hard time with an urgent, important issue, right? And he needs answers.

Well, that little flashing light may not necessarily be important to my goals, right? Well, really, it's sort of about the company goals, though. And that's really where the problem lies, right? Is there are personal goals because everybody's held to a certain level of performance and what they have to get done. So there's those personal ones, but there's also what's important to the organization, right? Is, is spending, you know, a week on this one thing that really doesn't add much value. Is that truly what's important? important and and then you might even argue whose job is it to say right and that you know yeah but if you're not careful you could have

all your time eaten up by just dealing with these little flashing lights and trying to you know prioritize yourself what's important and not important or make it yourself rather than all the stakeholders who have already kind of agreed on what's important for the two weeks but i don't know a good way of telling the difference so i you know i like luckily i don't get that many sky messages so it's not a big deal but i just kind of always wonder about that with like uh slack being so important in so many organizations now and uh you know chat's always been really important but uh i think it's kind of interesting because by definition it is urgent and it's not always important. Right.

Was that the only one though that, that read this quote from Eisenhower and then was like, okay, how did these two things explode to four? Well, I think they just built a quadrant out of it at that point. Right. But it's still like, yeah, even cause he even listed them out as, you know, numbered bullet points, right.

Or a numbered list. And it was like wait he never said something was important and urgent so number one can never exist right yeah no i don't think he did but or maybe he made the chart but he said he said all my stuff falls in one corner or the other yeah if this is your really the first time you've seen this then you need to read or rather i should say i've been reading too many self-help books because if you read any sort of like productivity book this thing is like front and center like getting things done um self-help or the seven the seven highly effective habits of successful people whatever like all those guys uh any book

like it like this is like front and center like chapter one interesting okay so then explain that then no i'm just kidding we'll move on so here's here's one thing that came out of this that i think is really important because this boils down to the software architecture part of this is they say that the dilemma for the software developer is that business managers are not equipped to evaluate the importance of architecture. That's so true. They can't be equipped because that's not what they look at. They don't see it. They're not down in it. It's your job to make sure that you are fighting for keeping the architecture clean so that when they come for another request in the future, that it doesn't turn into this big snowball effect to where the same request scope and shape ends up being three times the amount of work.

Right. So he makes it, he makes it a point here to say, that's what we're hired to do. We're hired to not just write lines of code. We're hired to make sure that we create a system that is maintainable. You know, I gotta say this. I really enjoyed the first parts of this book that I've read. Like it, it touches on so many different things that we've talked about in so many different ways, but it didn't go into every little one. Like it didn't talk about tech debt. It didn't talk about project management and ticketing systems. It didn't talk about, you know, all the stuff that

I'm kind of bringing into it now, because it really focused on like the specific clean clear messages of architecture and you know behavior or structure and scope for shape and so i really like dealing with in those terms if you look at some of the future chapters man i'm super stoked to continue reading this because, you know, structured programming, object-oriented, functional programming goes over all of solid. Yeah, there's some really cool topics that are coming up in this book. So I'm happy to – this is – I know we were waiting for this to be released. We saw it, what was it, like a month or two ago. Yeah. And kind of got excited

about it. There was one thing in here, though, that I wanted to, as part of the wrap-up of this section, that, you know, often we talk about, you know, when you're going over, you know, some requirement or feature or part of the application or whatever, you know, and you refer to to like, you know, getting the stakeholders involved and, you know, having that discussion with them because they're an important part of, because, you know, they're the stakeholders, but he makes the important point, uh, to note that you are a stakeholder and that, uh, it is your job as a software developer developer to safeguard the code. It's part of your role. It's part of your duty.

Yeah. Absolutely. And what I like about this too, the stakeholder thing is, he makes it a point to say that it's never easy. As a software developer or architect or designer or whatever. It will always be a struggle because people aren't exposed to that part of it. Right? So when somebody comes to you and say, Hey, I need feature ABC, you know, let's get this crammed in there. And you're going to be like, well, this is going to take us a little bit of time because we

need to do this, right? There's going to be an argument. There's going to be pushback. No, we need this in two days. No, well, you're going to have it in five. And he says, it is always a struggle. And he said, frankly, that's how it's always going to be. And that's how it's always going to be done. Because there's always this whole balance between it. But you as a stakeholder, he even says that it's not that you're somebody that is reporting to these people.

You should be treated as an equal in this argument, right? Because you're the one that knows about what you're doing to make it work for the company. But every one of the stakeholders involved, that struggle is there because every one of the stakeholders involved is doing their part to protect the overall organization from their perspective yep and it's your job to protect your slice of the organization which is your code you don't know their domain they don't know your domain yep and and he's just kind of go ahead oh go ahead no no i don't want to oh no yours is much better no mine's like cut off top stop all right all right uh so i was just kind of like you know thinking about spitballing like how what does it mean to defend or what does it mean to fight for something right and so i was just kind of thinking of a couple like off the cup

examples like one way to do it would be to talk to your boss about having like uh you know uh like what's called um lunch and learn type thing where you talk about better techniques for doing stuff and you can share that knowledge with your team. Another example I could think of would be going to different... Encouraging going to conferences or whatnot would be another one that's not so direct to your code or you know maybe even something like the google 10 percent um or was it 20 percent uh 20 20 and that was based more

around like kind of innovation um 20 projects and but you can imagine having something like you know what every other friday we're gonna have tech debt fridays and you know every developer gets to pick their favorite thing that they hate and work on it. And so that's what we mean by fighting. It doesn't necessarily mean saying I can't do this ticket because I need to clean up. Um, you know, you may want to bring up the problems and the things that you should do there, but there are other ways to address this than, you know, saying I'm not doing this ticket. I will say the tech debt Friday thing where each developer works on things that they know that they want to clean up or whatever. I have split mixed feelings on that because I've seen situations to where

people know what's important to them, right? What they, they've seen some bad code. They want to clean up that code. But oftentimes I, if you look at it as more of a big picture or a whole type thing, I feel like a lot of times there'd be wasted efforts down on, you know, feature X, Y, Z, because really what should happen is further up above something should have been fixed there that would have lined everything back up. You know what I'm saying? Like, I feel like sometimes the problem is, and I'm, you're saying like you put in the cart before the horse kind of scenario. Yeah. Like, like I do agree that

everybody should be a part of making sure that things stay clean, but that means everybody also needs to be involved in that conversation of what does that mean for us? What is important for us to clean up so that we can make better steps towards a better application, right? Just because you're going to go clean up an ugly section of code doesn't really mean you bought much, right? Because maybe that ugly section of code shouldn't even really exist, even as a clean section

of code. Maybe that thing should be completely removed because there should be something else further up that should be driving some of these things. You know what I'm saying? And that's where I struggle with some of that stuff is I think if somebody doesn't have enough context, they think that they're doing right by spending time in one area when really if that time could have been better spent elsewhere, that would have affected many areas. So here's an idea then.

And I don't have like a nifty little name for it, like the Google 20% feature. But what if on those days where, you know, refactor Friday or whatever, you have unit test Thursday. So instead, you maybe you don't have time to refactor something or whatever, but you introduce one new unit test to a piece of code that didn't already have any coverage on it. And if that requires that you need to do a little bit of refactoring to make that test work, then okay. I mean, in a little, right. And I'm only asking for one unit test. If every developer just added one unit test one day a week, right. However, that's however many developers you have. So if you have 20 developers, that's 20 new unit tests that get added that week, right? And then that would go along towards your ability

to do those future refactorings, like what you mentioned, where something's up a higher level and like, oh, do I actually have the impact? Did I introduce any regressions? It gives you that confidence that we've talked about before. Yeah, I like that.

I do like that. Yeah, I also also i really like the idea of uh devs having a seat at the project management table like a lot of times the the tickets kind of get determined in some you know back room where people are playing some sort of point poker or something looking at velocities but a lot of times um the devs will have the manager there but the manager is more about um you know, kind of keeping those behaviors rolling. And so it might be nice to have someone who's like specifically there just to kind of represent these non-functionals and structure and architectural concerns. Yeah, I honestly believe that the devs need to know more of the big picture stuff so that they can think about things in more of the big picture.

Right. How can I make something? You know, I have this one thing that I need to build. Oh, but this exists somewhere else in the app or or or oh, there's somebody else is going to be working on something else. Maybe we can work together and build something that we can both leverage. Right. I feel like a lot of times that's not done well enough. And that that is hyper frustrating, right? Because then,

then you get this whole thing where it's just not maintainable over time. Yeah. So we want to keep the devs closer to the domain experts. Yeah. I sometimes, you know, the, the problem is, and this is always a challenge is when you get too many people in a room, then the meetings will drag on, right? Like it's like going through, it's like walking through mud because there's a lot of questions. Everybody has ideas. So I think a lot of times the answer is you get a smaller group of people, then you involve more people after people have already hashed out some of the things and then, and then you hash them out in little mini

sessions as opposed to, you know, one long meeting that everybody loses focus on because it takes 80 tangents. And it's a practice that you have to try and do. And it's, I mean, but it's valuable. And I think that's a key. And don't forget, if you leave a comment on this blog post slash episode 68, then you're eligible to win a free copy of this book. And one great comment idea would be a suggestion for how to fight for good practices, right? How to fight, how to push back, how to deal with bosses that favor behaviors over structure. And to wrap this particular section up, I thought he summarized it excellent here in the first sentence of the last one. Just remember, if architecture

comes last, then the system will become ever more costly to develop. I mean, that's true. We've all seen it. And don't take our word for it, right? Take every project you've been involved with. Right. And if you're new to programming, if you're new to programming or you're a new developer,

keep this in mind, right? Like it's your job to, to start really thinking about this stuff. You really need to internalize it and don't let it stop you from working. But you know, this needs to be a part of what you are because you'll be respected for it eventually as well.

You can't be the guy at the meeting saying like it's all too big of a crap we need to rewrite the system before we do anything don't do that don't do that don't do that because all the senior devs will look at you and be like man yeah don't do that all right so we're gonna have a link to this book obviously as the resources we like uh and with that we move on to alan's favorite portion of the show it's the tip of the week it's the tip of the week all right so i'm gonna go first with my tip and that is that this is specific to, Alan's going to love this one because I got a SQL server tip or a SQL tip. And we all know how much Alan loves SQL server.

It's actually his favorite thing. It's one of my favorite things. It's his favorite thing. It's not one of, it's the. So always, if you're creating a view always explicitly name your column names for your view because if you think you're doing yourself a favor by just creating a view that does select star and you then change that underlying table the view is not updated with that change. Isn't that crazy?

I never realized that. And when one of our coworkers shared that tip, I was like, oh my God. Now immediately I was like, I'm probably guilty. Am I guilty? I'm not guilty. No, I'm not guilty. am i i'm not wait no i probably am guilty i've probably done that i don't think i've ever well ever in years and years and years i don't think i've i've put in a proc or a view select star just because there's the hit as

well on top of that of it has to query the sys columns and all that to get the stuff back. So it's running more queries just to return your query. Yeah. I mean, I honestly, I don't know. I honestly, I don't recall if I have. I'm going to guess that I probably have. But more importantly, though, was that it didn't matter if that it was just I didn't realize that that it wouldn't update like that. That's crazy. Talk about some some bugs that you chase down being like, why?

Yeah. Interesting. So I've got one. This came from Connect Tech that we mentioned at the beginning of the show here is there was a a session on web api and i almost skipped it because i'm like man i know web api what are they going to teach me in here right like literally those are the thoughts yeah those were the thoughts running through my head and i get in there i didn't know anything it had nothing to do with C sharp. It's what the Mozilla developer network MDN, if you're familiar with it, it's what they call web API. And it's part of these design things that exist in browsers that are amazing

things that I'd never heard of guys, like just killer stuff that you've probably never heard of. So one was like there's this uh what was it there's a payment request or or something like this payment form like basically what one of the big things that's happened in in a lot of companies keep metrics on this like i bet you you can bet your money that the Amazon does Walmart does, but I forget what the stat was that they threw out in this thing, but there was a study done that like 60 plus percent of people, when they go to buy something on mobile leave, because

when it gets to the checkout page, it's an absolute pain in the butt, right? Like you don't want to type in a bunch of stuff on your phone. And so there's this whole payment API thing on here to where if you implement that, which is, by the way, supported by a number of browsers and the browsers that don't support it, there's a polyfill for, but it'll actually pull up the payment instruments that you have available

that have either been stored on your phone or whatever, or in that particular browser. And it makes checkout super easy easy i don't think we've ever described a polyfill oh okay a polyfill let's talk on that real quick so if any of you unfortunately like we've had to in the past have to support something like ie8 right which unfortunately still exists for some reason somewhere out there in the ether. Just if it starts with IE, it's already like, really?

Yeah, I do. I'd so man, another tangent. So IE, uh, eight, nine,

10, 11, whatever. I ate eight. I think I was looking at was released in 2009. It was still being used, right? Even a year ago until they supposedly stopped support on it in 2016.

IE 11, which is the newest version was released like three years ago so we're talking about browsers right like there's security holes everywhere chrome has an update every other week firefox is the same thing they're like on version 60 and 50 and whatever it's crazy anyways and that's what a polyfill is. So, so yes, that's not a polyfill. So a polyfill, I apologize, coming back around. So a polyfill is when there's functionality, like new functionality that most browsers support, but there's a browser out there that doesn't support it yet. Somebody will write like a JavaScript script or something, a piece of code that will make that browser work like all the modern browsers. And so if you're ever looking like shims used to be a big one, right? There was polyfills for the old ones. And so like these, these payment, uh, a APIs and all that kind of

stuff, there's polyfills for that. There were really cool things. Like there was this, um, what did they call it? Enter something. Same in. Intersection observer. So this was an interesting one. If you've ever been to one of those websites or pages to where it has like the infinite scroll thing, if you want a good UI experience, a good UX experience, you don't want somebody to hit the bottom of the page before it starts loading up the more stuff

so that they're waiting once they get down there, right? So you can have this intersection observer where it will say, oh, this object is intersecting by X number of percent. Is it completely on the screen? Is it 80% on the screen? Is it whatever? And you can have it, you know, eager load some things or something like that. But what I'm getting at here is there were tons of features here that I'd never even didn't know existed because I never had heard of this web API thing. And there's, there's literally just pages of this stuff.

So I'll have a link in here. That's my tip to you guys. It was news to me and it's really cool stuff. Very nice. All right. my tip of the week is actually something i heard on ms dev show a long time ago oh wait i wasn't gonna mention another podcast so we'll leave that out we just fell off just kidding yeah fell off the wagon um anyway uh the idea there is sketchnotes which is uh just a way of taking notes where you kind of do some drawing and stuff and it's supposed to engage different parts of your brain. And just a better way of taking notes. And if you've ever seen any of the pictures, we'll have a link in the show notes.

The notes just kind of look like fun to take. So I always think about that when I'm taking notes with pen and paper. And there is something kind of nice and, I don't know, satisfying about doing that on paper compared to just, you know, notepad. So I just thought it was kind of a cool thing and kind of a cool idea for your next meeting. Although it does kind of look like coloring or, you know, it's like drawing pictures, which may not be cool depending on the meeting, your end, you know, if you're with the board of directors, whatever, maybe that's so cool, but it's actually just fun to look at. So you should go, go up there, look at it, see what the person has to say.

And they've got a whole system for um for kind of how to how to draw and how to how to emphasize the right things in order to kind of maximize your learning and also reuse of the notes so it's just really cool so you should go check it out good stuff all right well with that uh we ask that you subscribe to us on itunes to learn more using your favorite podcast app. Be sure to leave us a review by visiting www.codingblocks.net slash review. And while you're up there, check out our show notes, examples, discussions and more. And send your feedback, questions, rants and Destiny 2 clan invites to the Slack channel at codingblocks.slack.com. Make sure to follow us on Twitter at Coding Blocks or head over at codingblocks.slack.com make sure to follow us on twitter at codingblocks

or head over to codingblocks.net we can find all our social links at the top of the page and I'll be on Destiny 2 in about 30 minutes here so uh let's get to it