Coding Blocks - Clean Architecture – Keeping Your Options Open

Episode Date: January 23, 2018

Joe drinks too much coffee, Allen spits his coffee out, and Michael feels vindicated as the discussions about Robert C. Martin's latest book, Clean Architecture, continues.

You're listening to Coding Blocks, episode 73. Subscribe to us and leave us a review in iTunes, Stitcher, and more using your favorite podcast app. And 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 Coding Blocks or head to www.codingblocks.net and find all our social links there at the top of the page.

With that, I'm Alan Underwood. I'm Joe Zach. And I'm Michael Outlaw. Freelancers and small business owners, I feel for you. Tax season is here and there's a good chance that many of you are trying to dig your way out from underneath a pile of receipts and spreadsheets. Do yourself a huge favor and stop digging. Before you completely disappear under that abyss of paperwork, go and check out FreshBooks cloud accounting software. Not only is it going to save you a ton of time and stress, it might actually change the way you feel about dealing with your taxes. Need to send your accountant a quick summary on the amount of taxes you collected last year? How about pulling

together a profit and loss summary? FreshBooks can generate these reports in seconds instead of hours. It would take you to do them manually. You can even set up FreshBooks can generate these reports in seconds instead of hours. It would take you to do them manually. You can even set up FreshBooks to import expenses directly from your bank accounts, which means next time you can use your debit card for that meal, tank of gas, or new computer. Boom, the purchase is recorded instantly in FreshBooks. All this and FreshBooks is ridiculously easy to use. It's made especially for people who don't like dealing with numbers and their taxes. Right now, FreshBooks is offering a 30-day unrestricted free trial to our listeners. To claim it, just go to freshbooks.com slash coding and enter coding blocks in the how did you hear about us section. All right, so today we will be talking about the responsibilities of the architect and how best to express the intent of a system.

But before we get there, let's have some news. What's up? Yep, so first that we always like to start off with are the reviews and a big thanks to all who left them. So first, starting off with iTunes, we got M. Baumbach, Raldo, JeremyRose22, SipplyYoung, Arbinger, DanMarshall909, AndrewScottVT, Gopher, and FearGalWash. All right, and on Stitcher, we've got M. Baumbach,

MadJack, GotSkillsNowGiveMeJob. And one of those was twice. Did you catch it? Yep, M. Baumbach. That's awesome. Thank you very much. GotSkillsNowGiveMeJob. That's amazing.

Yeah, that was a good name. All right, so in other developer news, one thing that was of interest, I don't know when JetBrains snuck this in, but for the longest time, the free tier of TeamCity has been limited to only allowing you to have 20 total configurations. right and uh recently they they with one of their recent updates they've increased that up to 100 configurations now which is awesome yeah that's a lot of configurations yeah that is yeah so i again they also snuck in a cool feature too like um a while back where you know it used to be such a hassle every time you needed to upgrade team city, you know, cause it was always a manual process. You know, you'd log into whatever your build server was and, and, you know, reinstall it from scratch every time. And now, uh, I think it was the last thing. It was the 2018 or 2017.02 or something like that. Like it was like the two

releases ago. I think it's when they introduced the feature where now in the admin portion of the site you can just click a button and it upgrades itself so awesome i feel like 10 years ago somebody would have said you know like who would ever need more than 20 build configurations that's absurd here we are, 2017. Yeah. Only 100? 20 steps forward, 80 steps back. Right. Yeah, so a little bit of news for me.

I have volunteered to speak at the next Orlando.net meetup. I'm going to be doing a little kind of micro talk on dedicated practice, kind of gearing up for potential talk at CodeCamp. And I'm pretty nervous about it. I've done lots of presentations, you know, work work and even the podcast group. I've never done one at a tech meetup. And for some reason I'm shaking in my Nikes. So, you know, wish me luck. Cross your fingers

for me. That's coming up February 8th. Awesome. Everybody go out and watch them. Help them. Yeah. Everyone should, if you're not already in the Orlando area, just go ahead and fly. Make reservations now. You can see some Disney World while you're there. But, you area, just go ahead and fly. Make reservations now. You can see some Disney World while you're there. But most importantly, you can go see Joe Speak.

Migrate on down there. I was hoping more for nobody, but hey. We want standing room only. I mean, I'm going to be drunk anyway, so who cares? Just kidding. Hey, if you want to win a book, we're going to be giving away another copy of clean architecture so uh as we've been doing um just go ahead and leave a comment on the episode and we will hook you up yep and make sure if you're listening to this check your email because

that's how we typically contact you for the winner so uh somebody who won for last episode waiting to hear back so and also if you want to help us out while getting stuff that you want anyways, like things like Pluralsight or the books or anything, a place that we've set up for that is codingblocks.net slash resources. So you can see all the things that we recommend and that we like and we use and all that. And it'll help the show out. You don't get charged anymore. It's the same price if you're going to go buy it on your own.

But we'll get a few pennies here and there and it helps us keep the things rolling. So much appreciated. So with that, let's get into the show and decide what is architecture or maybe we should learn what is architecture. It's kind of weird to be talking about that starting in chapter 15. I thought the same thing too same thing too right yeah and obviously we've been talking about architecture the whole time i just thought it was kind of interesting to kind of um you know draw the line in the same now and say like okay now padawan we're ready to discuss what this all means we're halfway through the book and we can tell you we can wax on wax on, wax offing until now. Although I will say, like, the way this starts out, it's more like what is an architect as opposed to architecture. So, yeah.

And the first thing they say is it makes us think of weighty decisions and deep technical prowess, right? Like, it's the architect. Like, you almost think about the dude in the Matrix or, you know, Gandalf gray or somebody you know like this all-powerful being and right they're really still just programmers right yeah and i thought they'd really hammer the home that like the architect is really still a programmer you are still down in there otherwise you're going to be separated from the problems that you're trying to solve and you're not going to be attached to it yeah it's important that the architect feels the pain. And that's, man, that's huge.

Yeah, that part right there is how can an architect be doing things to improve the overall system if they don't know the state of the system in the first place? Now, I can imagine being an architect and not having a program along and be like, yeah, sure, DI all the things. What's this, you know, a new, like, where's your test coverage? It's so easy to say, you know, like, where are all the best practices? But once you get in there and actually try to start doing some things,

everything changes. Yeah, he does say that the architect might not write as much, though, as the other developers. Right, but they still have their hands in it. They still see, because it's all about, and we talked about in the previous chapters, this is about the shape of the software and and if the architect's not seeing that then they can't make decisions or any informed decisions on how to improve things

do you think the architect has to be held to a higher standard like do you think all the programmers are like oh check out what mr architect did today i certainly hope not yeah that's right like the architect's code has to have all of the best practices oh man like it has to be amazing scrutinizing your variable names i i mean i will say like having the title architect one of the things that i do take on upon myself is like some of the things that i hear that people complain about, like I really try and make sure that I try and move us in a better place. Right. Like I'll even take extra time on something that I'm working on to say, well, we're feeling the pain because we have this one huge project. Right. Like how can I break this thing up into meaningful chunks so that so that maybe we start evolving some patterns so that other people can do that, right?

So, I do try and take it upon myself to look at the pains and hear the pains that people are saying and see them myself and try and move away from some of those pains, you know? You do a great job about doing presentations after doing something interesting. So, I really appreciate those kind of tech talks and brown bag lunches. And I think all organizations should consider doing that sort of thing. So that's actually, go ahead, Mike. Well, I was going to say like another way that we could put that then is that the architect kind of leads by example. Yeah. I mean, that's sort of what in my role as architect that I try and do. I will say that is what you just said, Joe. That is actually one of the more frustrating things is when you do make

changes, how do you communicate that out effectively, right? I think we've talked about it in the past about how you can talk about system scaling and all that kind of stuff, but how do you scale communication? When you have a team of 25, 30, 40, 50, 100 developers, how do you communicate stuff effectively, right? And that's actually really hard. I mean, I think with the clean architecture, we talk about breaking things up into components that teams work on. And that's nice.

But then once that component's ready, how do you communicate that out in any kind of meaningful, effective manner? That's actually a hard problem. Well, part of what the, you know, one of the other themes though here was not just breaking things out into components, but it was like the chains of communication among the teams, because that would be a dictator in, you know, somewhat as to how things might, how the pieces may fall. Yeah, definitely. So we're actually going to talk about that here in a little bit. But rolling along here, the nodes, one of the things that we have here is, and we talked about previously, is the purpose of the shape of software is to facilitate the development, deployment, operation,

and maintenance of the software itself. The strategy that they keep pushing for in these two chapters is to leave as many options open as late as possible, which I really thought was interesting. We'll be going into some techniques on how to actually achieve that later. But they also really hammer home the point that software architecture is not about the correctness of the system. It's just about maintaining that

development, deployment, operation, and maintenance. Yeah, that was really interesting. I love the fact that they were like, yeah, it doesn't matter if the software works. That's not what you're trying to solve with the architecture. You're trying to solve how do you improve the ability to move forward on it. And one key point is they say that architecture has almost nothing to do with the behavior of the software, right? It's just about how the pieces fit together. It's all about that life cycle. So another way to say that then would be the non-functionals is what we're saying. Yeah.

There's the functional requirements, which is how the system behaves, but then there's the non-functional requirements. And that's more about where the architecture comes into play. Yep. Well, there's that. And there's also, we'll get into it in the next section here, but also about expressing the intent of the system. So I think the non-functionals are really important and it's really important that we leave those options open.

But we also want you to be able to tell what our system is about by looking at the code. So we want to make sure that the intent of the system is kind of reflected throughout the code. Yep, great point. And as we all know, hard to develop software equals unhealthy software. The harder something is to do, we find ourselves taking shortcuts. Like, you know, I don't really know how this works.

It's really fragile. So I'm just going to add add a little function try to change as little as possible and that's how things kind of you know grow even worse and more complicated over time yeah and he says that you know small teams probably don't think about or need to think about the architecture because they can work well and create a well system without having to draw lines between these different components. But I wonder too, if that in part plays because it is a small team, it's easier to communicate. Yeah, I'd lay money on it. Yeah, totally. But you know, the funny part is the very next thing he says is this is probably why most software systems aren't architected. Well, it's because they'll start out with that small team,

right? Like think about it. You're, you're a startup company. You write your software, you're, you're doing it fast. You're doing it agile.

You got, you know, three or four of your buddies next to you. And then all of a sudden the thing takes off and now you scaled your team out to 20 people. And now what worked for a small team doesn't work for that large team. And so it's not architected well, because now you have different concerns. Yeah. Think about how we teach people to

program. You go to a four-year university, maybe you'll have a big project by the end of the year, maybe not. If you go to a bootcamp, you usually start with a blank notepad. They encourage you to do small little projects on your own time, throw them up on a GitHub page. But all this small, small, small doesn't really leave a lot of room for getting experience with maintaining large systems or maintaining an architecture, which is a shame, but I don't know how to fix it. Yeah, so he goes, continuing along with this, this idea, he says that systems developed by multiple decently sized teams need to have dividing lines, you have to split up the concerns, you have to split the components. And, and, you know, those dividing those lines goes i'd like say even if you're on a team of 20 people it kind of is implying that hey um maybe we shouldn't keep spreading people around so that they're everyone's familiar with everything like maybe we should kind of keep people in the

same area so they can kind of build and develop those systems and and uh enforce those lines yeah it's interesting because they even say a lot of times what will happen is if you have split up teams, typically your number of components ends up being the number of teams, right? And that may not necessarily be the best thing to do either. And we'll get into how you can actually slice those things up better further on here. So the next session that we get into is the deployment. And this might seem like a shocker, but software should be deployable. And he wasn't being facetious about it. Basically, what he was saying is it's usually an afterthought, right?

So software that is harder to deploy is usually not as useful because if you're spending all your time trying to get something deployed then you're not spending time developing the functionality and making the system better and i remember working on the early days of dynamic languages there was a like a really strong culture of working sometimes even in production because you didn't have data or whatever you needed in the staging environment so you would work in production and then hopefully you remember to bring that down to source control hopefully yeah visual source safe yeah he also makes me feel better though too because he he mentions that the deploy the deployment of it or the deployability of it is something you don't really ever consider up front. Yep. And it's funny because there's a little buzzword

that we'll talk about in a second. But he even goes on to say, and Outlaw has a lot of experience with this, is software should be easily deployable with one action. And he can even tell you, I mean, you've done quite a bit of DevOps type stuff. That's not a small task, is it? No way, man.

I mean, like, just think, just think of some of the tools that are out there to handle it. Just in like a.NET world, you know, there's some common ones like there's JetBrains, there's Octopus Deploy. There's, you know, the stuff built into team services, for example. And I'm not even, I'm not even scratching the surface yet. I haven't even gotten into like all the other languages, you know, tools that are out there for them too, you know? So yeah, I mean, there's each one of those tools that you gotta learn and then understand this configuration, but then trying to piece together the right way to build in there,

you know, and then figuring out like what pieces had to be deployed in the right way to build in there, you know, and then figuring out like what pieces had to be deployed in the right way. And then trying to automate that to where it's repeatable. And now there's just a simple button to click to do that one time to a new instance. That's no small task, but it is an extremely valuable task. But at least you do it once and you're done forever, right? No. That's the sad part. and you're done forever, right? No. That's the sad part. Like that's the hope, right?

Like you would, you would like it. Yeah. When you start digging into it as well, you know, he just mentioned some of the technologies that he has to use, but then you have to think about things like, well, how do you keep artifacts around? You know, how do you orchestrate these things? How do you like, there's, there's tons and tons of things. There's a reason why DevOps people get paid a lot because you're a developer for developers, right? It's a really important role that enables teams to move faster. It's almost like you got to treat configuration

as code, right? So that's why it's not going to be like a configure slash write once and then forget about it. And then there's your build system forever. And you never have to think about it a second time because you just as your code evolves, so are the configurations as to how you're going to build that system. So you are going to keep evolving it. Yeah. I mean, it was worth a little sidebar because it's something that if you're interested in it, you know, definitely get into it. It's, it's a, it's a huge world and there's a lot to learn and it's kind of fun and it's a little frustrating and it's always changing. One of the things that I loved and, and we've talked about this in the past is microservices, right? There was a huge move towards them without the knowledge of some of the pitfalls to them. right? And they even talk about in the book

or Uncle Bob talks about in the book that when people decide they want to go the microservice route, typically deployment is the very last thing they think of. And it is probably the one thing that will cause you more pain with the microservice architecture than just about anything else.

You can imagine a new team starting off on a new project, getting the microservices set up, you know, finally getting to where they need to deploy something. And you realize like, crap, we're three months into this project and we're still kind of messing around the pipeline. We haven't really made much progress towards the future goals. Yeah. And then when a microservice fails, how does that thing get deployed back out? How does it get started back up?

Like there are so many moving parts when you work on a microservice architecture. So I thought that was really interesting. Yeah, it's really important that the architect consider the deployment. And so as the architect role, you're responsible for thinking about this sort of stuff up front. And if you didn't think about it up front, it's kind of steering you back to a good spot after the fact. So it's not to say that microservices are bad because I feel like they get kind of picked on. But it's just that you got to realize that the more variables that you introduce into your overall system's ability to work, to function correctly from, you know, from end to end end then each one of those variables is is going

to introduce complication of some sort and with a microservice i mean it's its own system so yeah it's called micro but really is it i mean it's still it's still the functional equivalent in terms of like configuration and everything as another system. Right. Right. So now you're just like multiplying out all the, you know, you're just, you're just adding on additional variables, uh, to your overall systems configuration,

which is why it becomes more painful or can be more painful. You know, our buddy, uh, will, um, he sent me something about, uh, like a, a go framework for protocols, but I only glanced at it quickly, but it looked like it was a good way of being able to deal with local code as if it was a service. So if you want to microserve it later, it's easy to break up, but you don't have to deal with a lot of those complexities first.

And I think that could be a really good option. And I think that more and more frameworks and more and more people are thinking about sort of ways to kind of start with that monolith, but do it in such a way that you're not pinning yourself into a corner. Yep. And next we're going to get into the operation of software. And when I first read the title of this, it wasn't clear to me what they were talking about really what it what he's getting into is the how efficiently the software runs like is it fast enough does it is it not destroying your servers or whatever the case may be or even your desktop it was desktop app right this is usually never the first thing you think about when you're like never a problem yep and it's because a lot of times they even say don't micro optimize right like don't don't consider it because you

need it yeah hardware is cheap and and they even talk about it in this like typically the answer is throw more hardware at it right throw more ssds throw more networking bandwidth whatever the case may be just add more cpus and yeah that's true and the reason they say it is because it's way cheaper than a software developer working on the system trying to micro optimize something and i think especially with the rise of cloud competing and you know for a long time it's just throw more hardware as virtualization is kind of taken over i think it seems to be more of a concern back when you would go ahead and buy and provision servers months ahead of time.

But then again, we've got Meltdown and Inspector. So with the cloud costs shooting through the roof, we'll see how that applies to developers over time. Yeah, your efficiency of your computer went down like 30% overnight. Yeah, if my bill is 50% higher, then we're going to be talking to those devs about getting those loops under control.

Right. Yeah, so one way that he summed this up that I liked was he's referring to the fact that the hardware is cheap and that the people are expensive. So he says that architectures that impede operation are not as costly as the architectures that impede the development and the deployment and the maintenance. Because that's where your people time is spent, right?

That's where your man hours are going to be spent and therefore your cost. Who cares if it takes a second server to run? Exactly. Because that's a fixed cost. One time and you're done, you never have to think about it again. Well, that's the hope, right? Ideally, though, a good architecture should communicate the operational needs of the system. You know, what I think it means by that is by just looking at the various components and breakdowns,

like you should be able to kind of see where the brains are needed, at least at a high level. Yep. Yeah, he says the architecture, another way he phrased it, because he said that point a couple times, and he phrased it a second time as the architecture should reveal operation. And I'm still trying to like kind of wrap my head around exactly what does he mean by that? Like when he says reveal operation, does that like oh hey uh we're gonna use kafka so then you think oh okay well i gotta i gotta use kafka so there i know what that architecture is going to look like and you know like what i don't understand i'm still trying to figure that one out i'm glad i wasn't the only one that read that and was like well it makes it itself apparent

to the developer the only thing i could think is is the breakdown of maybe your projects or your jars or whatever will communicate, you know, like, I don't know, maybe you have something that's like, you know, high bandwidth or, or, you know, a gazillion new processing per second types. I don't know what it is, but somehow it should jump out at them so that they know what they're dealing with. Yeah, I was in the same boat until reading the second chapter. And then I at least kind of rationalized it back to myself and thought like, oh, I think what he was kind of saying here ties into the idea of horizontal layers. And so ideally, your components would kind of reflect that layered approach. And so that, you know, if you kafka involved and a website involved you shouldn't ideally have a component that kind of ties the that in your middleware all together and so you've got kind of one component that spans three different layers because that obfuscates the

operational layers and so it's not a clean line between the different layers that you can use to kind of scale independently and so that's kind of where my head was at after reading that chapter correct or not okay i mean i like that it's much better than what my original go-to was because originally when i first read it i immediately thought like oh he he's referring to like um you know your your system exposing like its apis right like it's it's rest endpoints and things like that but But then I'm like, wait, wait, wait, wait. This is operation. This isn't development. Right.

Man, random side note here. If you hear the scratching, that's my dog. You guys have dogs that try and dig a hole through China in their beds? What is that? They'll sit there and do it for five minutes, and then they're like, well, that's good. Nothing changed. They'll just lay down. i don't get it not not exactly like that but i did once have a dog that would

pretend he was digging and burying his toys and he would even take the time to to cover the whole back up yeah it was hilarious to watch he's like you can't see that right dad you get you get so mad if you just like it's right there i picked it up yeah i'm doing my due diligence i mean you know i'm pretty i'm pretty sure that was on like some lsd or something oh man that's awesome all right so next up we have maintenance and this shouldn't be surprising to anybody who's been a software developer for a while maintenance is the most costly aspect of software yeah and it's also uh horrible i think this is the hardest part right like being able to make changes to things and do it

doing it in a good and clean way and fast um Yeah. And just to, to expand upon that a little bit, like typically when we think about maintenance, you think about something in your house, right? Like, oh, the, the pipes burst or, you know, my, my faucet's leaking or something. We're not talking about that kind of maintenance. When he talks about maintenance here, he's talking about making changes to a system. So as, as things go on, it's not just fixing things that are broken. It's how rough it is to add something new. And they say the reason why maintenance is the most expensive is because you're typically spelunking through the code, right? Like you were exploring the code to find the best place to add something.

And then there's always a risk when you do that right and i do love the use of the word spelunking as a way to describe how we work because i'm like that's so true it is it's an exploration right like you're walking through a cave in the dark trying to figure out okay well i see how they did this what's how do i add something to it so that it's not completely you know foreign like how do i fit some sort of pattern in here and and anytime you add something you add risk and and so that's why you know you potentially introduce a regression or whatever and hopefully you've been adding unit tests so that that's less of a problem but you know maybe not yeah based on our survey results probably not

walking through the cave is optimistic like my cave the caves that i write you're going to be crawling upside down like which way is up you're going down you're going up who knows spirals so you know going back to that about the most um the primary reasons for it being the most costly are the spunking and risk, I want to throw a possible amendment and see if you guys agree with this statement, though. of any software is because that's the longest time cycle of the software's life cycle. That's the longest period of time of its life cycle. I don't, I maybe depends on the software because I mean, some software,

like I don't, I can't think of anything off the top of my head, but maybe it just runs for years and years and you never change it right let me just phrase this a different way um your initial version of windows was created decades ago everything after that has just been you know adding on new features and main maintaining that to extend it but going forward right does that sound anything that's changing totally yeah i could see that well most software is changing right like most software doesn't just get written and thrown away in a closet and you never look at it again or if you do that then

it's probably like super hacked by now that's i guess you'd call that machine a honeypot yeah that's probably right you know i think machine a honeypot yeah that's probably right you know i think about like starting a new project though and like you know that first week you're just making amazing progress let's say you're making some sort of application website or something you got 17 pages like week one you've got 17 pages out there and they're roughly in shape and they're like week two well you still got 17 pages and i mean some things aren't working week three week four well you know next thing you know you're in week six and you're still like working on stuff and you know someone says add a checkbox or rearrange this and you're like that's gonna take a day and

like it took you a week to do the whole thing what do you mean it's gonna take a day to move this thing around it's so true well to put this a different way i mean we've talked about um greenfield applications and brownfield applications, the majority of the software that you're going to work on is going to be brownfield, meaning you're not creating something from scratch. It was already created, right? So, you know, you're adding a feature or maintaining like that. I consider adding a feature a form of maintenance, right? It is. If you're complying with a new standard that's a new fan a new a new uh

feature right but it's also kind of maintenance right yeah you're you're plugging it into the old system somewhere so it might be greenfield for that one little component but you're still having to make sure that it fits into the existing app somewhere so yeah and and the whole key of this part that they talk about is a well thought out architecture greatly reduce these costs or risks. And we'll be getting into why here in just a minute. So in other words, going back to like the Windows example, right? Because you could break things out into, say, separate DLLs, separate applications, you can mitigate those risks by keeping, as you mentioned, that new feature is the greenfield component, even though it's fitting into a

larger overall brownfield application or system. And going back to the previous chapters, if you try and keep those couplings between those new features in a good state, then you can stay in that. What was it? Zone of usefulness and stay away from the zone of pain or the zone of uselessness. And really, that's looking at those is how you'll do that over time. Stay along the main sequence. Yes. Which reminds me, we got a lot of feedback about our

description of graphs again. Sorry about that, guys. We're working on it. But if you do head to the show notes for that episode, we do have a nice picture there that sums up very quickly what our thousand words had a hard time with. Yeah. I mean, honestly, that's the thing, right? Even in major companies or even small companies, dashboards are all the rage because a picture tells a thousand words. So we try and describe it as best we can, but talking about lines and graph points and all that stuff, unless you've got your TI-82 in front of you, is there even a thing anymore? Yeah, and they cost the same. Are they really? They're still there?

Yeah, I sold mine actually not that long ago and got $60 for it. I'm like, what the heck? This thing's like 20 years old. That's amazing. So the next portion in what we've tentatively titled the show after is keeping options open. Because this seems to be the big thing. Software has two types of value value the behavior and the structure yeah and he says it's the structure that's what makes it soft the soft and software yeah i remember the whole advantage of software over hardware is yeah it's slower but it's so much easier to

change and malleable and we can roll this stuff out quicker. So the softer we can keep our where the better. And it's funny because they talk about by, by keeping the option options open as long as possible. They even say things like when you're designing the software, you're doing something, you know, don't make that decision that it's SQL server or it's my SQL or whatever, you know, think about it in a way to where it doesn't matter what it is. You can plug in the thing, right? It could be an RDBMS like those two mentioned, or it could be a horizontally scaling thing like Cassandra or, you know, DynamoDB or something like that. But really the thing shouldn't be, how do I design my software to work to this particular application, right? Like, think about how can I make the software work in the proper layers so that that's just a detail that's plugged in at the end.

Well, first, make it work, right? But yeah, there was this great summation of that where it was, you know, options that can be left open are the details that don't matter. And it seems weird, right? Like to say something like that, especially in terms of a database, because if you've been working in software for any amount of time, chances are you've been working with things that are backed by some sort of database storage, right? And almost always, that's the first thing that's done, Right. I mean... Well, I mean... I'm sorry. No, go ahead.

Well, I was going to say this in like another way, like, you know, taking your database example, like you might be fine from reading from the database and not realize like, oh, maybe we should bring in some kind of streaming technology. Or we've talked about caching before in previous episodes. Like in the beginning, you're like,

who cares if I reread that value from the database every time that it's needed right until you realize like okay fine this thing has scaled out to the point where it's like i should probably cache that thing and and you know read it from memory because it's a lot less expensive to read it from the memory um you know those are the details they don't matter until they do right and once they do that's when you you take the time to invest into those technologies in in the time but you know leaving that option open for as long as possible allows you to delay that decision as to how you might even solve that problem and then by the time you

are you you are ready to solve that problem you have a lot more information at your disposal so that you can make a proper decision as to what's the appropriate way to tackle that problem. Yeah. And think about it like this. When you go to describe your product to, you know, say an investor or to a customer or whatever, you don't say it's a SQL server app running on C sharp, but you know, you know, you don't spend that 30 seconds describing your, your tools, you talk about the features unless, unless it's one of two areas that I know about in which you are very likely to mention, uh, mention them in your company pitch. And one is machine learning. I feel like every company, if you've got like 1% machine learning code, then that machine learning is in your business description.

I agree. that buzzword is so hot yeah and uh the other i can think of is blockchain in which it's the technology itself is so hot right now that not only will you have it in your business description right you'll have it in the name of your company now it's when when technology becomes buzzwords that's basically what you're describing i remember like back in the 90s, like when Java became the thing. Do you remember that? Like you literally see it advertised on TV. And I just found it hilarious because I'm like, wait, why do we care?

Why does that matter? Why is that important? Man, I just saw an article the other day. And it's funny that you mentioned that about like machine learning. I think the co-founder of Google, I can't remember which one it was, but he said that machine learning is going to, or artificial intelligence or machine learning, I can't remember which one it was, was going to be more important than fire and electricity to mankind. That's a pretty bold statement. And that's why these buzzwords go off like they do, right? Yeah.

I mean, it's kind of ridiculous. So next up, they say that all software can be broken down into two themes, the policy and the details. And for the life of me, I think because it's early, I can't remember what the policy was. Reading on the notes, it says the policy is the true value of the system that sums it all uh not really all right it's up to you to save this all right you're welcome so the details would be like the configuration things like that like um where where are you going to have your database it's going to be on this other server we're going to keep it separate from the app server those are those are details right policy would be more like the overall function how things are work like how are we going to authenticate a user? Like that's policy,

right? Like how are we going to validate an order? That's policy. Those are the things that truly matter. Like you want to make sure that the user who logs into the system is who you think they are and they are who they say they are. And when they place an order, that order is legit and that they actually intended to place that order and that you're charging them the correct amount and the correct amount of tax, and you're going to ship it to the correct place. Those are all the, but how you do it is the details. Those are the policies that matter. The details are all the other things like, Hey, are we going to use SQL server? Or are we going to, is my SQL good enough? Or maybe we don't, maybe a no SQL solution is the the thing way to go maybe a document db right like those are

details that are that aren't as that's not the value going back to what uh the example joe gave those are the details that you're not going to go to a customer and say like hey you know you should shop with us because uh we use mongo db said no one ever right and that's not a jab at mongo db i'm just saying like those are the type of details that nobody cares about right right said no one ever. And that's not a jab at MongoDB. I'm just saying those are the type of details that nobody cares about. Right? Right. Nobody should care about that stuff if at all possible.

So yeah, they say the goal of the architect is to shape the system so that the policy, which is equal to the behavior of the system, is the most important aspect while making the details irrelevant to the behavior of the system is the most important aspect when making the details while making the details irrelevant to the policy. So loosely couple those things. Yeah. Your, your, how that order gets placed should not care if the system is going to save that data to SQL server, for example, or MySQL or Mongoongodb like that that should be irrelevant so this also kind of goes along with our our discussions about domain driven design too right

if you think about that right because then you're keeping the domain which you know in one book it's the domain and then this book it's the policy right you're keeping those things separate from the details of the system so know, like maybe in our domain driven design discussions, it was the repository pattern, right? So that you could, it didn't matter what the underlying architecture was. You're just going through some repository to do your reads and writes. Yep. And that's where things become pluggable, right? Like, you know, that you're going to have an order. Okay. Where's that thing get fed from or where does it get stored at? Who cares, right? Figure

that out at the time that you need to. There was this really great quote that I loved from this section of the book that I wanted to include where he says, a good architect maximizes the number of decisions not made, which seems so counterintuitive, but yet it really sums up what he's trying to say here, which is like, just leave as many options open as possible. Don't make those decisions yet until you have, until you're armed with the proper information to make them. Yeah,

I really like that. And it reminds me of the notion of the last responsible moment, which you can see kick up on the blogosphere once in a while,, but it's just the idea of deferring decision until you have as much information as possible. So don't make decisions early, make, don't make them too late either. So it's about figuring the right time to defer this is until you have as much information as possible, but it's not too late to make any wrong decisions. Um, however, don't tell your, you know, your boss don't tell your hiring manager that um you specialize in deferring decisions so that's not going to go

very well i'll tell you i'm gonna put that as a skill on my resume defer decisions yeah my significant other does not appreciate this uh this idea either well let's let's bring this back in house then um so not to pick on alan but i mean we've joked quite often about like alan will start a side project and it goes off in like you know a random tangent because it has to support a billion concurrent users before the first line of code is written so like you know it gets um you know caught up in all of these details that don't matter because, you know, making the system functional is the policy. That's the number one goal, right? And I mean, I know it's a joke, but, you know, I mean, that's the kind of idea here is like, don't get caught

up in trying to support a concurrent, you know, some insane concurrent number of users yet. Who cares about their operation of it yet? Just make it functional and then we'll worry about those problems when they become a problem. Yeah. And let's be clear, when we're talking about real software that you really have to write, you should definitely take these to heart. When you're doing something on the side, if you're trying to explore some technology because you have an interest in it, you know, and that's what your goal is, do whatever the heck you want. But definitely true. When you're definitely true when you're, when you're actually trying to accomplish something, there's a, there's a goal that

you have to achieve. Then, then yeah, man, don't get, don't get tied up in stuff that doesn't matter. You know, do what you need to do to get the thing done. And then you can revisit the other details later. Yeah. So wrapping up this section. Oh, go ahead. No, no no that was it go oh wrapping up the section good architects separate the policy from the details so thoroughly that the policy has no knowledge or dependency of the details what does that really mean it's just uh to me it almost sounds like the the ddd like domains uh domain driven design ubiquitous language like the policy is the language of the users it's the language of the system it's person logs in does this thing does that thing and the details are

the sql servers it's the configuration it's the you know how the the nuts and bolts work and so the idea for the architect is to basically keep those keep those things abstracted and keep clean lines which is the thing that keeps returning, keep those clean lines up. I do love how a lot of our previous conversations and episodes are like all sort of coming together, right? Like it's all these little building blocks and these pieces that start to make more sense when put in the context of, well, why does this matter, right? Like it's easy to see why clean code matters because everybody's going to be coding behind you. But then why does it matter that you have a domain? And why does it matter that you have these other things?

It all really starts to make sense, especially as teams grow. So with that, we would love to beg you guys to, if you haven't already, please leave us a review. We say it all the time. We read them. We love them. Even the ones that are painful, we read and we take into consideration. You probably noticed that our news section is a little bit shorter now.

And it's weird. We're not going to be able to please everybody, right? Like some people love the banter that we have because it's more personal, right? And then some people just want a lecture. And we try and, we try and walk the line. So, you know, please do, if you have a moment, go out there. If you haven't already leave us a review for the most part, it makes our day. Some of them don't, but you know, we, we do take them to heart. So you can do that by going to codingbox.net slash review. All right. And with that, we'll go into my favorite portion of the show.

Survey says, all right. That was very important. So I love that. So last episode, we asked, how often do you shut down your computer and your choices were shut down daily every week every month only when the updates force me who shuts down their computer or my favorite i don't shut down often but when i do it's because it blue screened or Colonel panicked. And then they ride in only right before taking some much needed time off. All right. So let's go. Who wants to go first? Anyone?

Me. All right. Joe wants to go first. He sounded like Roadrunner when he did that. Me, me. Me, me. Yeah, sorry. I'm at peak caffeine right

now we're actually recording this episode in the morning i've got my coffee right here i am flying right now i haven't been beat down by my own code mistakes yet yeah you and my dog that does the imaginary digging are flying yeah i think alan almost spit out his coffee he disappeared off camera all right so what do you think joe uh i'm gonna say uh only right before taking some much needed time off because i think you can disable those updates from automatically restarting your computer. And I think that a lot of programmers are like me. All right, go ahead. Sorry.

And we're going to go, and I'm going to go with the write-in that I annoyingly snuck in last time. At what percentage? 26%. 26%, all right. That's pretty high. But you can't disable that in Windows 10, can you?

Man, no, it's really hard to. Like that was, that's what i remember was that especially if you did the free upgrade you absolutely can't only on like the enterprise levels you get some that the administrators can have some controls over it but it's still kind of forced they just get some um discretion as to like when they roll those out was like the way i thought it worked with yeah we're in windows we're developers you know you know what's funny before i answer mine here is it is ironic that every other device you own has these forced updates to some degree right and people don't get that mad about them but

there's a difference right typically when you're working on a computer you're being a producer of some sort when you're on another device you're a consumer so you're like ah whatever if it restarts it's not going to kill me but if you're in the producer of some sort. When you're on another device, you're a consumer. So you're like, ah, whatever. If it restarts, it's not going to kill me. But if you're in the middle of writing some code and you left it up overnight and all of a sudden your computer shut down, you're like,

oh my God, you know what just happened? Like it's a different world. But so for me, I'm going to say who shuts down their computer and we'll go with, uh, I'll go with 30 all right so we have only right before taking some much needed time off at 26 of the vote and who shuts down their computer at 30 of the vote right we're either of us even close i feel so vindicated no people don't do it not every day

no my brethren daily for the win how much it it had uh it was over 37 of the vote wow it was strong like the two options that you guys said weren't even close not even close it was number two weekly number two was uh shutdown was like 37 and a half percent shutdown daily was 37 and a half percent only when the updates forced me was 36 those were far and away the top two choices weekly was a distant third wow man yeah and people be crazy i got time to shut down everything started all back up that's ridiculous we need to create a profile for like the average survey responder to coding blocks we know you got a busted a busted phone well there was actually a restart your computer there was actually a comment that came in, and I don't remember who wrote it now, but he was saying that he took his to more extreme where he'll reboot throughout the day.

Every time he would start a new, he would start a clean slate anytime he was starting a new task, right? So anytime he would context switch, he'd be like, okay, let's clean slate, start it all over. Yeah. And I mean, that's why I like to do it. That's a Windows developer. They are on Windows for sure. Yeah. Nah, man. No, honestly, Mac with VMware, you're doing it every two hours. I mean, I like the kind of idea of keeping it from a clean slate, but also part of my reason is just battery management. Like if i'm not using the laptop because that's what i typically work on i'll just go ahead and shut it down when i'm done for the day so that i can just unplug it because i don't want to leave it charging you know when

i'm not using it and then the batteries swell they've gotten so much well you've had the swelling problem i've never had that so so I haven't been as worried. But I mean, generally, that's what kills laptop batteries though, right? It's just like overcharging them. Yeah. All right. So for this episode survey, we ask, is it okay for a site to open links in a new tab or window for you. And your choices are, absolutely. No one's got time for holding extra keys. Or yes, but only for links to external

sites. Or yes, but the site better warn me first. Or, lastly, no, nope, never, nuh-uh. That's what control or command click is for. I'm going to reserve my thoughts on this one. I don't know if I want to bias anybody's opinion. I definitely have strong feelings about this. I can't wait. I can't wait.

I can't wait to see these results. I'm actually twitching a little bit inside because of some of these and it's so hard it's so hard not to say something i just realized i feel differently based on whether i'm using my mobile phone or a browser oh man yeah we must defer these yep put that on your resume. I defer decisions and discussions. But seriously, nope, not ever. Who's had to leave this time? Small business owners, it's time to be honest about how you feel when dealing with your day-to-day admin work. Admit it, you can't stand it. It's a total grind. The truth is over 5 million small business owners felt exactly the same way until they discovered FreshBooks.

FreshBooks is the dead simple cloud accounting software that's transforming how small business owners handle their paperwork. Invoicing? No problem. Using Fresh Books to create and send an invoice literally takes about 30 seconds. There's no formula or formatting, just perfectly crafted invoices every time. Online payments? Your clients can pay you online, which means you end up getting paid a lot faster.

How about project deposits? There's a super handy deposit feature, so you can invoice for a payment up front when you're kicking off that next project. Insights? Freshbook can even show you whether or not a client has looked at the invoice you've emailed. This is only a fraction of what FreshBooks can do for you. You owe it to yourself to feel the full effect of FreshBooks on you and your small business. For a 30-day free trial, just go to freshbooks.com slash coding, that's C-O-D-I-N-G, and enter coding blocks in the how did you hear about us section. All right, so recapping what we've already covered here,

an architect must support use cases in operation, maintenance, development, and deployment of the system. And so let's go ahead and get back in here, and let's talk about some of the use cases where the architect must support the intent of the system. And this is what we kind of referenced a little bit earlier. The idea here is that a shopping cart system should look and feel like a shopping cart. You should have big, obvious kind of reflections of the intent. So what I'm trying to say is like a shopping cart system,

you should have a big obvious chunk of code for adding items to cart tracking the state of that placing orders removing items like these are the kind of things that should jump out at you when you see the system as opposed to having shopping cart system you double click in there and you see a bunch of um you know i factory factory i abstract you know a bunch of um god i'm doing you know, a bunch of, um, God, I'm doing terrible. Well, how about I put it this a different way? How about, how about to say that the shopping cart application supports the intent, the architecture of it supports the intent. Then you might think that, um, that you would have a component for order handling, uh,, a component for customer authentication or customer management, a component

separate for product listing and product searching, right? And fulfillment. Each of those components, right? Because before I described where I got kind of confused about something he said as it related to operations about, you know, my mind immediately went to thinking about like, okay, well, the APIs are exposed, right? But this, we still haven't even gotten there necessarily. Like we're, or maybe we have because we are talking about use cases. So, yeah, what do you think?

This is exactly what Joe said to me earlier was this is when you start getting into things like domain driven design, right? Like, so if you're thinking about, you know, a project like a.NET project or solution, you'll have projects in that solution, right? One would be just like you said, order processing, one might be product listing, another one might be, you know, order fulfillment. There's all these different things. And if you have these projects named properly, the intent of the system should jump out at you, right? Like you should be able to look at it and say, oh, okay, this is a shopping cart or this is an order management system. Are payments fulfilled? They're in my payment project. Yeah, exactly.

And I think that's what they're getting at here is, you know, what Joe was saying is, you know, you shouldn't just have a ton of folders called factory and whatever else. Like don't have a project called, you know, factory project. This thing should be, this is an order management or this is whatever. At a high level, the next time you open up your favorite IDE, Visual Studio, Eclipse, does anyone use Eclipse anymore? They still use Eclipse. It's still highly recommended, by the way. That's why I was making the joke. But yeah, at a high level,

you should see those use cases at a high level by the projects that you might see in that application. Yeah, and the first thing that kind of jumped out to me was back in the day, I would do a lot of stuff with ColdFusion frameworks or even a lot of the SPAs and a lot of like, I've seen this a lot with Java programs. But you go into, you get this, you know, you download this project, you go in there and you see, oh, models use the same with ASP. Here's my models, my views, my layouts, my, you know, whatever.

It's basically the framework. Okay, well, what the heck is this website about? So you kind of like open out the layout and you see main and a lot of times especially if it's like a really dynamic website like you don't even know what the heck you're looking at you couldn't tell just from looking at the source code for 15 minutes like what your website is even supposed to be doing right and i don't really know how to fix that in terms of like you know asp and i know that um you know the the frameworks opinions are are so strong that that could be really tougher in the case of java you can have um you

know so many layers and different folders of you know uh package names basically that it can be really hard especially if you're using something like a spring to know what the heck is going on and how things are moving about and so i don't know how to necessarily fix this, but I definitely recognize the problem. And I think a lot of my hate for things like spring and things I've had bad experiences with this because I've gone and downloaded the package and said, all right, let me get started. And I can't figure out how things are put together and what it's supposed to be doing. Yeah. It's interesting because that's what he says here. And I love it. And you just hit all those points is screaming architecture should emphasize the purpose, right for bloggers out there or people that create content or anything like that. Like a lot of times if you go to a page and you're looking for information, how many times have you guys gotten frustrated where it'll be like, oh, here's the code. And you have no idea what the context of that code is inside the app, right?

Like what file is this thing in or how does this thing get laid out? Like it's nice to be able to have one huge file that does something. inside the app, right? Like what file is this thing in or how does this thing get laid out? Like it's nice to be able to have one huge file that does something, but at the end of the day, that's not how it's going to live. And so having some sort of guidance to where does this thing actually exist, right? Like where does it live within the structure of the application? And I feel like it's a hugely overlooked component of teaching in most cases. And I feel like it's a hugely overlooked component of teaching in most cases. And I feel like we probably all have projects like this where there are those tasks that you get asked to work on to where occasionally you'll be like, oh, man, I dread working on that area because it's just going to be painful to even find the right place to work in it, to put it, whatever. But, you know, it's very refreshing when you're like, oh, hey, we've decided to change the way ad rotations are going to be displayed on the site. Oh, look, I can open up the project and there's the ad project. There's

where ads are served. Okay, I can just, I know exactly where I got to go, right? Even at the top most level of the project structure. Yep. It's way more important than what it sounds like. And I mean, we talked about it in the past, you know, naming is one of the hardest things, you know, organizing things in a way that's meaningful is also it like, you know, the framework thing, a lot of whatever your, your development language of choices, you know, you'll see these MVC models or the MVVM models, and they'll say, put all your views in one folder. That's to me, completely useless. Please don't do that. Right? Like don't put every single view in a view folder, break it down by its component and, and then put a view folder inside that if you want, and then put a model folder inside that if

you want. But at least that's meaningful as opposed to just having a hundred files that are all views that doesn't it doesn't tell you the true intent of what's going on a lot of this oh sorry joe oh you a lot of this is the common theme though it's also about like how do you draw the lines where do you draw the lines right because how you draw those lines about like okay um i've segregated all the ad portion of the site that responsibility is in the project right so you've drawn the you know the circle around that kind of going back to some of the drawings that we we looked in with the domain driven design right it's like how do you draw those lines around the various components to express that intent of like this thing is just that don't don't go adding caching capabilities site-wide into the the ad project or the customer management

project right like those aren't related yeah i just pulled up a couple of my projects just to kind of look at how i've done this in the past and i'm looking at color mine which i've had around for years now and in the top level namespace where things actually start happening, I've got three main folders, one for comparisons, one for conversions, and one for like math utilities

called utility. In that case, I feel okay about utility because it literally is like very specific, like, you know, converting angles to radians or, you know,

whatever kind of stuff. So I feel pretty good that like if you come into here, you can see like, oh, this is a library for comparing and converting and doing some math and i'm looking at my uh my little game project here uh after i i introduced dependency inversion a framework just to kind of see what would happen see what i liked about it but actually i found after i did that it was really easy for me to um chunk components by their, by their, what do you call it their

subject, I guess. So I've got a namespace for audio, which is all around playing sounds and another one for scoring, which is all about scoring. I'm working on breaking out another one for behaviors. I feel pretty good about that too. Like I go and I look in my scripts folder and like, I can tell like immediately, oh, okay, we've got playing sounds, we've got scoring, we've got behaviors. And at the top level, i got a bunch of stuff called like game bootstrapper or game session things like that like i know i'm looking at a game so i'm not saying that i'm good about this all the time but i do like that um the idea that what the things that i consider kind of good and clean code do seem to have this format as opposed to a lot of projects i've worked

on and written where you can go in there and uh not know what the heck's going on yeah you end up hitting you know navigating through code just to figure out your way through it right or debugging through code and if you're doing that to find out where something lives then chances are it hasn't been broken out in any kind of meaningful way and i think this does get a lot harder as like projects get bigger. You know, I feel like if I went and looked at the Firefox source code that maybe this wouldn't be the case, but it's just got so much stuff going on. It's got rendering engines. It's got all sorts of other what I would call weird stuff. But just because it's really complex and hard.

I'm going to try and pull that up right now. Oh, yeah. It's like it's in 10 different repos, you know. So, yeah, it's tough. And, you know, it's for great reason, I'm going to try and pull that up right now. Oh yeah. Look, it's like it's in 10 different repos, you know? So yeah, it's, it's tough. And I'm,

you know, it's for great reason. I'm sure. Oh my gosh. Is it SVN? Say it ain't so. Delete and Firefox. Dude.

I actually, speaking of which I will say, I mentioned it, I think as a tip or something in a couple episodes ago about the new Quantum Firefox. It's really good. I truly like it a lot. I've heard nothing but rave reviews about the performance of it. Man, I've been using it almost exclusively.

And I mean, there's some things that just don't work because some things were made for Chrome or whatever. But man, it's really good. I've been impressed with it. Are you referring to, like, extensions when you say made for Chrome? What do you mean? Yeah, like some extensions. Or if you go to, like, for instance, a frustrating thing is I have, you know, I've gone without cable and all that stuff because I got mad at the cable company. As you do.

Right. As everybody does eventually right so i have chromecast and you can't cast to your device if you're watching youtube from firefox it won't let you do it yeah because there's not an extension for it for fire right so it's just kind of frustrating that there's little things like that but other than that like i've been i've been super happy with it so so anyways, yeah, go ahead. I did go, I did find a mirror on Git so I can actually understand it because I forgot how to use SVN of Mozilla.

And just like, you know, as you might imagine, there's a lot of weird folders in there for things like international or the mobile app that kind of shares components. And so it's pretty hard to see what's going on. But they also have a folder called browser. And if I go in there, I see things like branding and components and experiments and extensions and fonts. And so I do really feel like I actually, you know, as complicated as I'm sure it is, like it's pretty easy for me to see like the structure.

So if I want to see how extensions work, like I'm clicking into extensions and I see all sorts of interesting stuff. So this does look like a browser when you look at the code. That could be a fun little website to put together that I'll never actually do. But you can imagine like take various source code projects and then have people guess as to what the project does just by looking at the code in like say two minutes or whatever. Oh, that's fun. Cool. Well, jumping back in here, the next thing that we talk about is operation and what they say is sometimes it can be tempting to rearrange the architecture

of a system around processing requirements and an example they give is a high throughput system they need to take great advantage of independent scaling and parallelism and you shouldn't your your architecture shouldn't be based around that right yeah your architecture should be abstractions around um you know the the actual like domain of your code and should be screaming that uh scream that architecture and intent so if you see things like we're talking about large components so if you see like something like the order queue then we're telling you something about the operation of that uh code which is maybe not that important maybe it's an implementation detail that we've kind of raised to the top level because of our naming scheme and uh it's maybe not such a good idea because those things are

details and that may change so today it may be a queue and tomorrow it might be, you know, sort of like weird serverless, whatever that has nothing to do with queues anymore. And, and I think just that doesn't mean you can't have files in your application named order queue, right? Like you, you might very well have that, but at your architectural level, looking at the components or that kind of stuff, you probably shouldn't have an order queue project, right? Like, and maybe I'm missing some things there, but in my mind, you know, we're not saying you have to skate around exactly everything that you're doing, but you should at least abstract those things out so that, you know, maybe if you have an order processing pipeline,

you know, that order processing could use an order queue, or it could just write straight to a database, or it could, you know, write out to some service out somewhere, you know, maybe you have implementation details of that, that are going to be those separate files, right? But at the higher level architectural view of this thing, you shouldn't have a order queue processing project, right? Or something like that. I think that's really what they're getting at here. So in other words, to expand on your example, the act of fulfilling the order shouldn't care what it's writing to. Correct. Yeah. There was another statement here where he says that an architecture that provide that properly isolates its components will be easier to change over time as the operational needs change.

So true. I feel like we all just like poured one out, you know, like, yeah, I feel your pain. I mean, you know, this goes back to what one of your favorite topics is, Mike, and that's unit testing, right? If you have things broken out into smaller chunks, it's a whole lot easier for you to say, hey, let's make sure that this one little thing is tested very well, right? When you have everything in this one huge project and everything's just kind of touching everything else, it becomes very difficult. And so breaking those out into meaningful pieces or components, not only does it make it easier to see just from an architecture level, coming in and anybody can look at it and say, hey, I know what this does. But it also makes it to where it's easier for you to break out some of those dependencies so that you can test things better. So another example to this, though, might be like if you have properly abstracted away your database from the rest of your application and your code.

Right. So today you're running on, say, SQL server and everything's fine but then over time you decide hey you know what um that's not good enough we need it's time that the sql server isn't scaling to what we need we need to be able to horizontally scale out uh the the data layer you know much wider than what we can with SQL Server. So we need to go to some sort of DocumentDB that will allow us to index it differently or whatever. But because you already took the time to apply some sort of a repository in front of that database and you already drew that line of what was responsible for reading and writing the data, then when it did come time to replace that with some DocumentDB type solution, right,

you only have the one place where your changes are isolated to. So you only have that one place to focus on for the effort. So it makes it easier to focus and concentrate your effort on that one thing, right? And now you could scale that out to like, you know, other, other types of scenarios as well. Right. And I want to point out like a detail of that, that, that in a real world example, and we've seen it and we've done it. I mean, pretty much anybody's done a bad practice at some point in time, if we're all being honest, but like entity framework, uh, if, if anybody's used entity framework in.net, they have this whole, you know, entity to SQL type stuff, which is really cool, right?

Like you can, you can write any kind of I queryable to do, to do joins at an object level. When you use something like a repository, you kind of cut it off there. And the reason is, is because that entity framework, that entity to query or to SQL thing exposes your storage technology. And so the problem is, if you let that abstraction leak out into your application code past the repository, then now you've got something that you can no longer break, right? Like if you do need to go to something that scales more than SQL, you can't easily do it, right? And you've got something that you can no longer break, right? Like if you do need to go to something that scales more than SQL,

you can't easily do it, right? And you've got this abstraction that is no longer an abstraction. It's now an implementation detail that's leaked throughout your code. So it's fine for your repository to use the entity to SQL code behind the scenes, because if you ever wanted to swap out the implementation of that repository, you can swap out that entire thing, right? And that entity stuff hasn't leaked into your code. So it's one of those things that seems really small until it's not, right? Like once it starts leaking out into your code, you start realizing that, man, people are doing crazy

stuff all over the place, right? We're not enforcing business rules anymore because now people are just querying the objects directly and they have no idea that there's even a business rule around this thing. New developers might not even realize that a query is being executed. Right, right. There's all kinds of things. And so it's just one of those things that not only does it make it to where your system is easier to reason about and change in the future, but it'll also protect you from having a bunch of stuff leak into your system that you have no control over over time. So basically, it's not that you're saying don't use entity framework. You're saying only let the repository level use entity framework.

Nothing that is using the repository pattern should know or care how it's communicating with that data. Exactly. And I love entity framework and I've heard many, many people like PooPoo and many other ORMs out there. And that's because typically what happens is they end up getting all mingled into the code and then you have performance issues because people don't realize what's happening behind the scenes and you can control all that. So yeah, use the tools, but use them in a way that benefits you. Yeah. And push those dependencies out to the edges whenever you can. Yes. So that takes us into the next section, which was development. And right away he starts off with Conway's law, which maybe I shouldn't be embarrassed.

I hadn't heard of this one until reading this. But he says, any organization that designs a system will inevitably produce a design whose structure is a copy of the organization's communication structure. That's interesting. I hadn't heard this one either. Yeah, I thought it was so awesome because I was like, structure. That's interesting. I hadn't heard this one either. Yeah, I thought it was so awesome because then I was like, man, he's right. Like this Conway guy really knows his stuff because he also has the game of life.

You know, because it's like, if you think about it, like if you have a hodgepodge code, right? Then is that, ask yourself, like like honestly is that also how the structure the communication among the entire development team is right is it just like you know is the if the communication is a free-for-all then so is the code right but if there's clear lines clear boundaries between how you would interact with another team then so are those deliverables going to be, right? I mean, like, thinking back in my past, right, there were times where, like,

I would work with, you know, someone from research, for example, right? And there was a very clear line, like, we were in different organizations, very clear line of communication, and so the code would be delivered in a similar format that matched that. But I never thought about that until reading this law. Yeah. And I kind of wonder if I'm fixing one or the other, we'll kind of have effects on one or the other. So, you know, the idea is if your, if your code looks like it's been really additive, it's really hodgepodge, it's a mess of things that look like they were quickly done with loose requirements um you know maybe you could start by focusing on those you know requirements

and fixing those business processes but also kind of wonder too if like if you start pushing back on the code quality angle and trying to do a better job there about organizing your requirements up front and figuring out um how to kind refactor things, if that would also have some influence back on the business, just because of the perspective you're kind of, you're coming from. I don't know if that's true or not, but I just thought it was kind of an interesting idea of like this, just the idea that like, if you start pushing back on code quality, maybe we'll have some other effects on the actual business processes as well. It's interesting. Maybe it would work that way.

Yeah, probably not, but you know impossible yeah i like the idea of we need like um a coder focused phoenix project where uh the coder starts with the code and by refactoring the code and making things cleaner and writing unit tests they somehow fix and save the business i know the person to write it dance and i we need you yes i mean it was kind of interesting too because like one of the other themes that we've we've come across several times in this book though have been not just about the structure of your code uh or your your application but the the um relationship between that and the organization of the teams and how to structure the teams right and i don't think in any other conversation about architecture i've ever

heard those two um you know mentioned at the same in, right? Yeah, I would agree. It's almost always about code or it's always about organization, not the two together. And I think, you know, coming up here in one of the other sections, I think it hints it weighs to where you can do things and then maybe teams become responsible

for some of these things. So I am kind of curious to get into that one. So the next step we have is deployment and the goal should be immediate deployment. And it's funny, and I'm curious to get your thoughts on this one, Outlaw. They say not a hodgepodge of scripts and FTP. This is achieved by proper partitioning and isolation. So basically they're saying that your deployment shouldn't just be a bunch of cobbled together stuff. And I feel like some deployment kind of is that,

and I'm curious your thoughts on this. Yeah. I mean, I really kind of struggled with this one because at one point i guess the way i interpreted some of this part and i i could have been wrong but when he was talking about like you know the hodgepodge of scripts or um you know dozens of little configuration scripts as he puts it and property file tweaks is that um if you manually have to go in and change those things, then that's where he's saying is wrong. But as long as you have those things automated, right, then that's okay. So for example, the deployment using an installer, yeah, there might be, you know, several configuration files

for different parts of the overall application or system. But as long as you have an installer that is consistently making those changes, that's okay. It's okay that those configurations exist, right? Okay. Okay. So like in putting that in scope of like DevOps, like builds and deployments and all that stuff then. So it's expected that you're going to have multiple properties and configurations and all that kind of stuff. But really the goal is there should be an easy way to run that whole thing. I think the key here is reproducibility. Okay. Right. If your deployment can be going back to one of the other comments, which was like, you know, one, a one action to kick it off, right? You know, if you can kick that off in one action and it'd be reproducible every time in the same way, then that's okay. It doesn't matter that there might be, you know, I mean, because think about it, you know, you,

you have to lay down dozens of files into different locations, you know, when you're installing any kind of application, right? Like take an operating system, for example, like think of the, you know, insane amount of files that are getting laid down in the different destinations and structures, like of like of where it's putting stuff and the decisions that it's making it where to put stuff like of course it has to do that right so it's not it's not that it's bad to have those things it's just that it has to be automated it has to be reproducible if if it requires human intervention and that's when there's the problem if you have to manually transfer a file you know if you're ftp'ing

or well first if you're ftp'ing anything these days you know shoot yourself ssh but yeah but uh but if you have to like manually connect to your web server to transfer a file over in order to fix a change or to put down a new feature or something like that that's what he's saying is wrong from a deployment or at least that's my take on that section yeah something like that that's what he's saying is wrong from a deployment or at least that's my take on that section yeah i like that i do think uh things have gotten so much easier in this arena over the last say 10 15 years i mean back in the day like even wordpress it would be like okay uh first you got to set up php here's instructions for windows here's for debbie and here's for red hat and then here's your instructions if you're using apache if you're on apache 2.2 here's your you know it was just tough and you had to go configure

multiple spots you had to make things make sure things were familiar um were all set up and then you had to you know check the various faqs because it would never work the first time something like setting a wordpress could potentially take hours and um i i think a lot of that was because people had such varied setups and so if you were doing WordPress, there's a good chance that you were running other websites. It wasn't just the same thing on the server. Things like that used to be more common. And nowadays, it just kind of seems like everyone's just kind of gone with it. Like the Docker approach, we're like, just keep everything self-contained, keep it to you.

And that way, if you make some adjustment to Apache or Nginx or whatever for this project, it's not going to break your other projects that would normally have been running under the same web server. So I think the Docker and DevOps mindset has made this so much better. Yeah, containerization is amazing. I mean, the big thing is you almost don't have to worry about hardware infrastructure as much, right? You just think about, hey, what do I want to deploy?

And if it's just a little piece out here, then it's almost like a module that we're talking about in the architecture for the software, right? You plug it in and it's an appliance that you use as opposed to, oh man, I have to go configure 900 things to get this one piece up. Yep. I think-

I remember- Go ahead, Joe. I was going to say, I remember going to Linux things to get this one piece up yep i think i remember uh go ahead joe i was gonna say i remember going to linux after many years of windows and um you know being introduced to yum which is like a popular package installer at the time it's being amazed because that you know at the time i had been doing so much stuff on windows like installing java setting the home pass setting that you know whatever and just to have like some sort of package manager take care of that was just amazing to me and i never thought that uh you know i was like okay this is why linux is for for hosting things uh and things have obviously come a long way but i still have

yet to see like a a really truly amazing experience in windows for package management like chocolatey is really good one get uh it works i haven't seen i haven't ever used one get uh i haven't seen i haven't ever used one get is that even a thing it is yeah i mean it it uses chocolatey it can use chocolatey behind the scenes but it's like a it's like a higher level on top where it can have multiple um like if you want to think of chocolatey as a repository of packages right you can have like multiple repositories and chocolatey can be one of those that it pulls from and installs from but i how do i use it like what would i one get yeah i still think like you know if i'm going to install a like a elastis search or something like now it seems like everything is kind of docker assuming i'm on the appropriate

version of windows but i i've yet to use one guy i don't even know how to get started or to browse what's available here's the beauty though about docker um and i kind of made some kind of reference to this earlier when the devops part came up but it was um you know treating your configuration as code right you can go out in um on github for example and find repo after repo after repo of people's Docker configurations for various things, right? I'm trying to think of good examples, but I found one guy who works for Microsoft, and he must have had like 200 different repositories up there in his GitHub account for different Docker configurations for things within Windows, like all the different ways that you might want to use parts of Windows. That's awesome.

And that's just treating your configuration as code then, because now you can check that in and that becomes you know, becomes reproducible. That environment becomes reproducible, which is great. Excellent. All right. So the next part that we're going to jump into is leaving options open. And, and we talked about this a little bit earlier is good architecture balances these concerns, right? It, it all sounds really easy. Like that's the whole thing. Everything that we talk about here sounds really easy, but in practice, it's not. It's not because there's too many pressures coming from outside your department, inside your department

for timelines, whatever, right? Like these are not just super easy things to do. And here's the reason why. There are things that we don't know up front like all the use cases right sounds ridiculous but that's always the case right and then those things change too yeah yeah or maybe the use case doesn't change but the details around it do so yeah i mean the requirements for it um and we don't know the operational constraints yet. We don't know that caching needs to be a thing yet. We don't know that SQL Server isn't going to be good enough yet. We don't know that we need to horizontally scale the data layer out to 100 servers yet, because right now we're just trying to build the thing.

Right. And then you have your team structure, right? That's a, that's another one of these things that you just don't know how everybody's going to be split up on these, um, your deployment requirements. How does this thing need to be pushed out? Is it an installer? Does it have to get pushed out to five different servers? What, whatever the case may be. Like all these things are things that you typically just don't know yet. And so it's hard to come up with something that's going to work within all those necessary pieces, right? Yeah. And as Joe said, the worst part about all of this is that all of these things are going to change consistently over time. They will always be evolving. So basically what this means though is you're always trying to hit a moving target with whatever system you're trying to build, whatever architecture you're trying to design,

it's always going to be a moving target. So that's why you want to defer those decisions for as long as possible until you know that you need to make a decision on that so that you have the most information for that moment in time. I do want to say something for anybody that's – because we have listeners that are all across the spectrum, right? Brand new in college to have been doing this for five years to people who have been doing it for 20 years. A piece of advice I would like to give anybody that is wanting to get into this or is in it and gets frustrated by it. Is to use tabs. That too. But this is the world.

You are always going to be working on a moving target. If you're a person that is extremely inflexible and you need to have everything laid out in front of you before you can get started, this is going to be a struggle, right? Like this is going to be a real problem. You need to be flexible with this because business needs change. We write software to, to solve problems, whatever those problems may be. And those problems sometimes change, right? The face of that problem changes a little bit. And so it's on us to be flexible enough to work within this.

Yeah, totally. Next up is talking about decoupling layers. The goal is to support all necessary use cases, even the ones we don't know about. And as we just said, those cases often change too. Now, the architect should know the basic intent of the system. Like, are we here to place orders? Are we here to take refunds? Are we here to browse the internet?

And so as long as we know that and we focus on the single responsibility theorem, which is each thing should only do one thing and have one reason to change. And the common closure principle layers which is to say a front-end website a middle tier like a service tier a data layer um a mobile app layer things like that in order to separate these different concerns and so that they can change and scale independently. This kind of makes me think of what we've been talking today about Vue.js. Like, I don't know how it is now. I don't have a lot of experience with the new front-end frameworks.

But I know back in the day, like, it wasn't so difficult to move between, say, like, Prototype.js and jQuery. You know, you would change your selectors a little bit. But for the most part, your HTML was separate. Your CSS was separate. It wasn't really, it didn't matter what glue you were using. I don't know how easy it is to move from like Angular to React. Right. But I'm kind of wondering with something like Vue.js where like everything is in one file.

You've got your CSS, you've got your HTML, you've got everything kind of bundled together in little components. How easy is it to change that framework? Well, actually, Vue is very similar to React in that regard. You can bundle as much of that stuff as you want into the one file as you want. So if you want to put all the CSS in there, you can, but you don't have to. It's treated more like web components in the general sense so that so

that you can truly break that stuff out i i know outlaws probably spend a little bit more time writing the view stuff than i have but but it looked very similar to react in that regard so it felt like a mixture it felt like a mixture of like let me take the best out of angular and the best out of out of react and um i think if I remember right, we discovered that the guy who started Vue was actually from the Angular team. Does that sound right? I think so. Yeah. And here's the thing though, Joe. I would argue that changing any of those was never easy, right? If you went from jQuery to Prototype, you were doing straight up DOM manipulation, right? So it wasn't pretty.

I would actually almost argue that with something like Vue, it would be much easier to go between Vue and React than it would have been from jQuery to prototype. Because at least now with these front-end frameworks, something like Vue and React, you're dealing with a component. And all the DOM manipulation is happening for you under the covers, right? So you might have to tweak some properties on your component if you

were to move from one to the other, but I think that you'd find that it'd be less of an overhaul. I think anyways. That said, going back to this whole layer thing, this is where I really started liking where this was getting into some, not implementations, but some guidance in terms of where these layers should be. And so they point out, and we've probably all seen these things, right? A decent set of layers is you have your UI. So if we're thinking about a web app, that's going to be, you know, whether you choose Vue or React or Angular or something like that. Then underneath that, you're going to have another layer that is going to be your UI business rules. We'll call it that. That are things that drive things that should happen in the UI as data comes in and back and forth, whatever. Then beneath that one, you're going to

have your core business rules. And that's going to be probably some server technology. If we're thinking about like a website, that's probably going to be your server technology that enforces data coming to and from the system and how things change state. And then after that, you're going to have your database layer. And so it's easy to see those four layers, right? Because now you can see, okay, yeah, I could, I could totally separate these things out because they all sort of do things independently. Yeah. And so let's talk about decoupling use cases. Use cases are narrow vertical slices

that cut through those horizontal layers. So if a horizontal layer is like the database layer, then the use case would be place in order, which is something that goes through each one of those. And what I thought was particularly interesting here was the book seemed to be advocating, no seeming, it definitely advocated for keeping those features as separate as possible. So if you have something for deleting an order or adding an order, treating those as separate use cases, which is obvious, but also trying to keep the code completely isolated.

And that goes all the way up to the UX layer. So even having a different web page for adding and a different web page for removing, which I thought could kind of be antagonistic towards the owner, because now we're talking about changing the user experience to make things easier for programmers. And I didn't love that idea. But I don't think he was, you know, slamming the gavel down saying this is how it must be done. I think he was saying like, this makes it easier for us. But I don't think that's necessarily the right answer, depending on our situation, the kind of decisions we want to make, because the customer service person may love to have both of

those features on there. Because if they need to cancel an order and add a new one, like it might be really convenient for them to be able to have both sets of information up there at the same time. And so I do think that the user kind of wins in this case, and we as programmers just kind of have to suck it up. But maybe you you're thinking of it as too granular though because he says that he does say that the use cases are a natural way to divide the system but maybe the use case of those two things that you're talking about are just under an umbrella of order management right and maybe that's the you know bringing back in the domain driven design conversation maybe that's the domain and back in the domain-driven design conversation, maybe that's the domain. And so that's its independent thing.

Yes, it crosses all of the layers, UI and business rules and database and things like that. But within that domain, it has a set of use cases like add an order or delete an order or fulfill an order. Yeah, I think I might have had just kind of a knee jerk reaction because I just listened to a fantastic episode on Eat Sleep Code with Sarah Ford, who's a UX expert. I think she's working on PowerPoint team at Microsoft now. But she was talking about how when she was working on a project, she worked really hard on the time she kind of published it. She realized when other people started to try and use it, that the program is really organized around her testing the program, like while she was working on it. So it was really optimized for her to work on it. And then when other people came in, they didn't know where to start, they were confused, there was this this learning curve. And she kind of had this, you know, revelation, like, oh, crap, I designed

this for me, not for the thousands of people that are actually going to be spending their time with this. So I thought that was a great episode, first of all, but I think it just right after listening to that episode, and then reading this book, I was like, oh, crap, this is a little scary to me, because I don't want to change my UI based on, you know, what makes sense for me. And, you know, maybe I'm kind of thinking about it too much. You know, she obviously wasn't talking about the code level. She was talking about the experience level, but I think it's something to think about. Well, that's, I mean, it's really important though, to distinguish that in the fact that

if you have these layers separated properly, then that UX should be able to change freely and then just leverage that next layer under it, right? Like that's really the goal is, and that's the same thing that we talked about with the database earlier, is if you have a repository fronting those storage mechanisms, then it's easy to swap that out. Well, your UI should be somewhat swappable, right? Like if you want to have add and edit and delete all on the same page, fine. It should just know to call the underlying, you know, business layers for each one properly when it's, when it's done. So yeah. I was just imagining, like, say you're working with a PayPal or something, which we always love

to talk about. Um, if you end up making your UI, your UI over and just, you know, complete developer land, like you're probably going to model that user experience based around the even the objects that PayPal expects. So you might have a screen for gathering this information, a screen for gathering that information, the screen for putting the order through. And you're not necessarily thinking about it as a user because you're thinking about it as like, how do I get to the next step in this development process to make sure that integration is actually happening and if i don't have a ui as a programmer it can be really difficult for me to script that kind of stuff out because it does involve like web hooks and going back and forth and stuff like that

and then someone you know actually tries to use it and they're like well why are we doing this you're like well that's how paypal works you're like yeah but that's not that's not what i want that's not what makes it to me i don't care if it's paypal or not i just want to place my order so you better make it as easy as possible for me right yeah so i kind of thought of an example as you were describing like a real world example that maybe people can um relate to uh if you are a last pass, for example, as a user, it's very nice when you go to whatever page you're trying to log into and both the username and password are right there on the same field.

LastPass is very good about handling that situation. But when you start dealing with logins where the username is on one page and then you have to click a button to take you to another page and maybe that page is the password, maybe it's a token, or maybe it's going to ask you for a security question. That's where LastPass sometimes gets confused, right? And so that's where it's like, I know that those are two separate systems we're describing, but just as the usability of the system is, you know, in one example versus like the ideal way that we would like it where it's, you know, all on one page, just ask me at one time and I'll enter it in, right? Yeah, a great example is Microsoft. Like you enter your username and depending on how things might be set up, you enter your username it's like wait is this a work or personal account right and it's pros you got both and they don't want to ask your password because maybe you're already

locked into one or the other maybe they don't even need your password but for me it's like every time i go to microsoft it's like here we go yep yeah here we. And I don't know which ones, which, you know, I'm going to end up logging into both more often than not. So the, the, the gist of this whole part, this part here with the decoupling, the use cases is the benefit is doing that makes things easier to add and change over time because you've got a very small discrete area that you're working in. And so it's easier to test, make sure that you don't have regressions, you have limited risk by doing so. Yeah. Maybe, you know, to mention Sarah Ford again, the idea is that if we design this in a good way that we can make it easy to modify it, we can go ahead and get V1 out there,

make sure it's working and then,, and then continuously adapt to that user experience over time. We just have to make sure that we budget some time and think about that experience evolving to make things better. Yep. And so the next thing that we're getting into is the decoupling mode. So having your components divided up into layers makes it easier to scale those layers separately, which is interesting because now you can deploy those things separately as well. It's important to point out that by decoupling mode, we're really talking about operation. Yes. Yeah. So if something's parallel or if you've got, you know, you need more database servers or more front end servers, stuff like that. Yeah, that definitely ties into the operation over deployability, your intent.

Yep. And so this whole decoupling of your code, breaking things into projects like DLLs or jar files or whatever the case may be. Now those things can be deployed out individually. And so your ability to scale or use other architectures or hardware or whatever has opened up now because you left your options open. Yeah. So independent developability and deployability, horizontal layers make it easier for teams to be organized based on what makes sense for the business. So you can have your teams

organized around features, say customer service, payment, like all those things touch the database, all of them have user interfaces. Alternatively, having these things divided into layers also obviously makes it easier to organize the teams around layer. So you can have a middleware team, a database team. The horizontal layers don't dictate how your team should be organized. It's just kind of a good thing to do. It buys you deployment flexibility and it buys you the ability to separate things either way. It's funny. The more that I've thought about this one,

I like the idea of you know we talked about you had your horizontal layers right and then if you think about drawing lines through those so you're slicing it up right like now you got a tic-tac-toe board i like that because especially as being a full stack developer typically you're a full stack developer because you want to be, right? Meaning that you like to touch the database and you like to touch the middleware and you like to touch the UI. You like playing in all those different playgrounds. And by drawing those vertical slices through those horizontal layers, now you can have the best of both worlds, right? So that you're not stuck on a middleware team or you're not stuck on a database So that you're not stuck on a middleware team, or you're not stuck on a database team, or you're not stuck on the UI team. You can now, you can compartmentalize some of those

pieces, right? So if you're working on an order management system, right? That doesn't necessarily mean that, oh, well, you're only going to be working on the backend portion of this. Like, you could work on the backend portion of this, you know, with a team of people, right? And then if there's somebody working on the front end portion of that, maybe you work on that part or maybe you don't, but that's bundled as part of a component as well, right? So I like it because you almost have like these, I don't want to call them quadrants because, you know, there could be more than four, but if you did picture that, like you could be working on the top left and the bottom right, you know, it doesn't have to be that you're working on the entire vertical section completely,

although it might make sense, right? Like if you're working on the back end order management stuff, maybe it makes sense for you to work on the front end portion as well, but those things should be bundled separately, right? Like that's their own component. That back end piece is a component. The front end piece is a component. They shouldn't be treated. And I'm curious what you guys think about this. I almost feel like sometimes working on the entire vertical thing, you almost have tunnel vision. And so you might make bad decisions along the way simply because you're like, well, I know that this has to hit this and this has to go to this database table, right? It was almost like the PayPal exam. Say what?

You could have tunnel vision the other way. You could. You totally could. So it's almost nice to have teams of people that, like maybe having somebody that didn't work on the back end one also work on the front end one and vice versa, right? And then that way you have people thinking about the problem differently along the way. But you still compartmentalize some of those

things. Yeah, I think the reason why technologies like ColdFusion and the way we used to do like ASBNet Classic and, you know, the old school PHP, it was very common to have all your work in basically an HTML file. So you kind of threw your tags in there, code mingled stuff. But what that meant is that every single person who works on that was a full-stack developer because there's sql code over here there's loops over here there's html and css over here and so there was no way to subdivide that everyone was organized around features because there was no flexibility you know you didn't have like a middleware tier that was responsible for lines 20 through 40 and 117 through 200 and it just it didn't really make sense because it was so easy for somebody to uh you know enter a character that was invalid or something and break the break the asp or whatever

which happened all the time if you did pound symbol in the cold vision file you know like your your designers had to be aware of that sort of thing and i think that's why those have kind of fallen out of favor so horizontal layers doesn't take away full stack. It's very easy to still be a full stack developer. It just buys you that flexibility to say, hey, we could also have a designer who gets to focus on CSS and HTML full time without having to worry about, you know, their pound symbols. Right. Yeah. I mean, this was, you know, know yet again another part of the book where

the teams were discussed right and and how that might be structured you know he's whether it be feature or component or layer teams and i know that for me that's been something i've kind of like struggled with like just trying to think about like okay what's the appropriate structure or organization for teams right like what what does make sense because at some point some part of me is like okay if you're talking about like a a large enterprise then yeah i could see where you have highly specialized people who only ever focus on the database, for example. That's all they care about is the database. They're really good at it. It doesn't matter how that database is being used for, they can walk in and in a matter of minutes, they can just totally own that thing, right?

And find performance tweaks that you didn't even know about, right? Versus smaller organizations where everyone has to wear many hats, right? So, you know, I mean, you know, another way that you said that was as a full stack developer, but I mean, it's more than just being a full stack developers, the two, right? In terms of wearing many hats. So then it's like, how do you structure a situation like that where it's like, well, you know, on the flip side, the enterprise example, where you have the highly specialized people, then that's where I think that the layer teams make sense, right? Because you could have people who are only focused on like, you know, AIX, for example, like they know how to build those systems out, how to configure them properly. They're, you know, that that's their wheelhouse.

Right. And then somebody else is going to come down on top of it and lay down, you know, a database like a DB2 or something like that. Right. Who use a DB2? People do use it. But then in that smaller organization, that's not going to make sense. So does it make sense to have those layer teams in a smaller organization? Where do you draw the line? When do you decide that it's appropriate to have those layer teams or it's not appropriate to have those layer teams or maybe um maybe it's just a matter of scale so like in the enterprise that layer team for um just the database uh the

size of that team is relative to the size of the enterprise but when you get to a smaller team that quote team might just be a single person you know this is a, I think, and there's no right or wrong answer to this one, I don't believe. But I think that you have to look at, at what point are you experiencing pains, right? The real pains. And then from there, how do we how do we fix some of those pains? And I think that's really how you have to approach it. Because it's like, like we said, at the beginning of this, you know, a project starts out with five people and you work fine. Right. And then at some point there there's that inflection point where it's like, OK, this is no longer easy. Right. Like everything we do is is negatively impacting something that had been previously done. And I think that's where you have to start thinking

about, okay, now we've hit this part. What can we do to take a step back from this and restructure some things so that we can work in ways? And it may not be as granular as what we were talking about with the various different slices and all the pieces. Maybe it's a little bit bigger chunks at that point, but at least you start breaking them out. And I think that's really the answer. And again, it's still not an easy thing to do because especially like you said on a smaller company, like everybody wears many hats because smaller companies have to be more agile and they have to respond to the market and all that kind of stuff it's just it's a hard hard question to answer is a frustrating question to answer too and that's like i said uh you know i i struggle with trying to think of like what what is the right shape of that what is it what does the right size look like yeah and yeah go ahead

just thinking like we need to start organizing teams based around the single responsibility theorem and the whatever, the CCP, you know, so the things that change together should stay together and trying to draw cleaner lines between teams because you can't have 20 people talking to 20 people. It's like having a method with, you know,

10,000 lines in it. You've got to be able to break stuff up, have clean lines to minimize that overhead. Otherwise, you just end up spending all your time in communicating. And just like anything else, I think the more communication and the more complicated the communication is can often lead to negative results. Yep. But even single responsibility teams, though, the things that change together, stay together, right? That could be interpreted multiple ways, too, there, right? Like, initially, I was thinking like, okay, well, that would just be a together, right? That could be interpreted multiple ways too there, right?

Like initially I was thinking like, okay, well that would just be a feature, right? Like if the team that is responsible for say order fulfillment, right? They would all work together and that's the feature that they're delivering. But you could also say, well, then there's the layer, which is the, you know, going back to the database is our canonical reference. You know, that that is the thing that changes together. That, yeah, I don't know.

I still struggle with that. But I do like the idea of trying to think of teams as like single responsibility teams, though, that's interesting. I like it almost on a per project basis. It depends, right? Like if you have different departments, like if you have teams working in an accounting department, then that's

easier, right? But when you have teams that are all broken apart, but they all work on the same product, you know what I'm saying? That's when things get a little bit murkier, but I almost like the idea of, of like you said, a feature or a project based type thing. And then that way, everybody's focused on the one and they can bundle that, but then it doesn't take in the overall architecture of the system. It's such a hard thing, man. Yeah.

Well, let's move on to the next section, which I really enjoyed this section, duplication. And he says that architects will often fall into the trap of the fear of duplication. And I thought, that's a really very true statement, right? Like it was, it kind of hit home. Yeah, I definitely have had that. Like, well, if you break up things into different silos,

then everybody's going to be writing the same code. Yeah, and that's the thing. We've absolutely had this conversation before in past episodes. So he says, you know, generally duplication is a bad thing, right? And when we find that duplication as professionals, we are honor bound to reduce it, right? But he points out that there are different kinds of duplication. And I think this is what we tried to discuss in previous episodes, where there's true duplication versus

accidental duplication. And true duplication is, have you ever seen that code where you'll go to change something and above it, there'll be a comment section that says, hey, any changes to this portion of the code, you got to go change these other five files, right? That is true duplication, right? That is code that, you know, should probably, as painful as it might be, figure out a way to eliminate that duplication and break it down into one component, right? But then there's accidental duplication, which is what you were just alluding to, Alan, where it, you know, yeah, there might be code that is duplicated or seems duplicated, but it could have just been, it could have been written totally by accident or maybe it

wasn't written by accident and it you know originally was just a copy and paste of something else but the point is is that it's accidental because those two things change at different rates and or for different reasons yep and that that's really the part right there that sort of hits home is yeah okay so they look similar but they're different enough to where they should be separate and you shouldn't worry about the fact that some of that code's duplicated right and that's that's sort of hard to internalize especially when you see it right you're like well like, well, everything could use this. But then he even goes on to point out that, okay, he says, resist the urge to eliminate this duplication until you know that it's true duplication, because what if they look like they're similar, but they really serve slightly different use cases. And then you'll find yourself in a situation where you

tried to unify that code. And now when something needs to go in one direction for one, then the other one does. Now you're going to, you're almost going to be wanting to just put a hack in, right? Because, oh, well, I need to support those use cases. So now you're going to have this branch of SLFL stuff in there. And that's not true duplication now you've actually probably introduced some some some technical debt just by the fact that you tried to cram them all into the same thing right yeah i got two things that are the same but they're both special cased like well they're they're not the same but that doesn't mean that there isn't you know that like there could be two things that are special case that are also the same.

So you have to be careful of whether it's the same by coincidence or by design. Like should these things really move together or are these totally separate notions? So, yeah, I'm going to do the same thing. Like I see the same three lines in two places. I'm like, oh, this should be a thing somehow. And if it's not a thing, I feel like I'm, you know, dirty and doing things wrong. Somehow. Yeah. Somehow. Yeah.

Somehow. I mean, I wish I could remember the examples that we've talked about in the past. Because I remember I used Microsoft as an example where it was like something along the lines of, of course, there's going to be some piece of code that somebody else wrote that was the same, just coincidentally. But that doesn't mean that it was a bad thing that it exists. Right. Or that you have to go in and cut it out to dedupe it uh that it was okay to like split that split that code out and um i think maybe it was related to the domain driven design conversations it probably was so it's funny because they even say here and it it's so easy to do, is don't get lazy.

L-A-Z-Y. Don't get lazy. No, Lassie. Don't get Lassie. Don't get Lassie. And simply pass an entire row from the database directly to your UI. Right? Doing that, you've now circumvented the layers that were in place

to help you abstract those things. And it might seem completely innocent and not harmful at all to do it, but it will cause you a problem. At some point in time, trying to skip going through the proper channels, you're going to miss something, right? Yeah. And it's so tempting to do that too because it's so easy. And it's so nice to be able to say, hey, you just changed it over here and it just flows through and everything's magical and dynamic. But what kind of inevitably happens is like,

someone says, well, we have to do this one special thing with the column. So, like, okay, so now I've got my view model and things are still dynamic. Except I also kind of dynamically append this thing and format this thing and remove this thing. then i have to do it for export and it just um if you're not careful with that and you don't uh abstract and break it away at the proper time then you end up just you know setting landmines for yourself yeah you start bolting on and hacking things into place to make them work the way that they would have already if you had

just gone through the proper layers right right yeah i was curious alan because when we were putting the notes together for for this portion of the show like it i don't remember exactly what you said but it was something along the lines of like uh it was almost like you had some kind of aha moment or something when do you remember what i'm talking about because i was really curious for you to expand on it man we were talking about it before the show they were like this is good for the show and i was like okay yeah yeah i totally forgot about it i wish i could remember to help you but there was something you said i don't remember about it but all right we'll move on yeah it's gone so so we previously talked about decoupling mode which again was operation and so he revisits this portion

of the this topic again in this chapter and says that we can decouple at many levels so there's the source code level there's the deployment level and there's the execution level and previously when we talked about decoupling. We were talking about the different layers. But now we're talking about like, well, what does that look like in more detail? And source control means packages. So that changes in one thing doesn't necessarily require another because we can set that dependency at a higher level. Well, it doesn't force a recompile is what he says.

It doesn't force a recompile. Now, I got a question about that. How does that work? level well it doesn't force a recompile is what he says right force a recompile right now i got a question about that how does that work because immediately i was like wait a minute if if if you're all right so the note that i wrote here and maybe i interpreted it wrong because it sounds like you're talking about packages but he's saying source control not packages so i'm like well if you're accessing the raw source control you know you're accessing the raw source control, you know, you're accessing the raw source as part of your application, you're using someone else's raw source and there's changed. How do you not, how do you avoid a recompile of yours? Or did I interpret that portion wrong?

I think, I think it was more along the package, right? So if you have a NuGet or you have a JAR or you you have a dll then it doesn't have to recompile those and so i think it did blur the lines but i believe that's where it was supposed to be headed i mean i don't because he definitely gets into dlls and packages later in the deployment level right and but even if it was a dll how you know you would still have to recompile right well and what am i thinking i kind of thought about it was like DLL, you know, you would still have to recompile, right? And what am I thinking? The way I kind of thought about it was like, more like, say, if you have a library packet or a logging package and you make some updates to it, I don't have to go and do anything, right? I'm still depending on, you know, whatever older version of it. And that's not a big deal.

Yeah. And it's not recompiling the source. So if you think about it, right? Like if you have a solution that has 50 projects in it and it's all the raw source code, it has to recompile those, right? Like if you do a clean and build, it's going to recompile everything. Whereas if it's just dependencies in there, it's not recompiling those dependencies. It's just recompiling the source that leverages those dependencies. So it'll be faster, right? And less prone to risk and break and change and all that. Yeah, I think in.NET world, it doesn't make as much sense because you kind of have to explicitly update your NuGet packages. But in something like a Ruby or a JavaScript, you can say like, you know, npm install Express, and you don't even know what version you're specifically on. And so when I NPM start or NPM install, like the version of Express that I get may be different from the versions of Express

that you guys are getting. I don't treat that as source code modules then. What am I missing here? He says that we can control the dependencies between source code modules. So the changes to one module do not force changes or recompilation to others. If you're talking about you're accessing the source code, then you're not using a package manager to get that source. Is my interpretation. I guess so. But I mean, you could think like if you've got like a front end project, a middleware project, a database project, if somebody changes a store procedure, I don't have to recompile. Somebody changes the CSS, like I don't need to recompile. I guess it depends on the type of changes they make, though, right?

Yeah. If they change columns, that's a different story. Yeah, I mean, yeah, we can move on but that that that one definitely confused me um but i did find it interesting though he brought up the monolithic structure in this section yep um you know where you just he i think maybe we've even talked about like monolithic repos um things things along that lines but you know keeping everything into a single executable or a single address space as he sometimes refers to it in the in the book um and refers to that as a monolithic structure

yep um the second layer was the deployment layer which is similar but independently deployed and i think it gives examples here of like jars or dlls um i don't typically deploy those kind of things separately though so i guess if you had like a you know like a plug-in architecture or something then that would make sense that you could just drop the dlls that actually changed those plugins but yeah overall um i guess you're right like i'm not feeling really too strongly about what the distinction is between those okay now i'm glad you said plugin because that because because i actually had a note here about the dll ones because i was like wait a minute have you ever like added a new dll to your project without recompiling right to like

make sure that it still works or things like that. But, you know, the example that you gave with the plugin architecture actually makes a lot of sense, because then if you're, say, notepad plus plus, right, or a sublime, and you've you have a well established plugin architecture, just because somebody deploys a new JSON formatter plugin for that works with your UI doesn't mean that you got to recompile your UI. So now I kind of get that example better. That makes a little bit more sense. And the Java world, the Java world that I when I used to work in a little bit, you'd have like a server container. And then in that case, it would be very common sometimes to go and drop a jar or a war or a car or your you know

whatever in order to update that and it was very common to do you know do something like just redeploy a part of your whole i don't want to say application but part of your whole system like you might update your cold fusion server independently of your code or vice versa yeah it's like a hot swap almost right yeah so if I think of deployment level as like plug-in architecture, then I think I can get that one. Yep. And then we have the service level, which is separated by network and it's completely independent deployment.

Okay, yeah, we get into that in a minute. So I'll skip on that. Yeah. And so I can get that. Like if we've got two services that talk to each other and then that makes sense, like even though they may end up on the same box together, I'm still kind of communicating between those two, like with HTTP or some other, you know, protocol buffer or something like that. see a buzzword coming yeah uh which is best uh hard to know during the early phases of a project so um we'll get into a recommendation here in a minute but um yeah you know deciding if something is going to be a service or not up front uh it's kind of just tough decision especially as those use cases are really taking shape yeah so microservices uh are or were all the rave

for some period but that service level decoupling is expensive both in terms of the time of the developers and the system resources that it would take to do that did you just say all the rave well weren't they i mean wasn't there a period of time like i feel like it's kind of gone back now like the wave has crashed on it to where it's not so much now but it definitely felt like there was a period of time where it was like microservice all the things and now it's like don't oh yeah but you said all the rave rage i always thought it was all the rage but i just googled it and apparently this is quite contentious on the internet like there are things called all the ray there's uh all the rage um

yeah okay so urban dictionary rabbit hole someone saved me no we need to know where this ends okay so yes you don't let me rephrase this microservices are all the rage against the machine um but actually that's probably pretty accurate yeah no matter what we're still just rats and cages right yes you know what was interesting though and this is what i really liked so you know he wasn't trying to say that microservices are horrible or anything like that, but he did say push the decoupling to the point to where a service could be formed. Right. Should it is a different question, right? But could be. And so if you make your applications architecture in a way to where that thing could be leveraged and deployed as a service

later, awesome, right? But that thing could be leveraged and deployed as a service later. Awesome. Right. But that shouldn't be where you start. Yeah. Cause you know, that, and that's really the point that he's making now. It's like, Hey, if you tried to start with that, um, microservice before you even realize that you need it, it's really expensive. So why would you spend the time and money on that, um, beforehand? So defer that decision. Yeah. So again, it kind of comes back to drawing hard lines and pushing your dependencies out to the edges. Yep. And this was a pretty good one too. I thought good architecture will allow systems start as a monolith, then grow independently to multiple deployable units. And then if it

needs to come back into a monolith at some point in time, it can. So it's interesting when you think about that, if you build it in a way to where you can chunk out things over time, then you've won, right? You didn't lose anything by doing it up front, and you probably made it more readable and easier for people to maintain and add to over time. But you've also set yourself up for future expansion if need be so i actually had a note here in the book about that part because i was like wait a minute you start as a monolithic repository and application you decide to break it apart into independently deployable parts and developed independently and whatnot they version independently and then you're like okay decide to break it apart into independently deployable parts and

developed independently and whatnot, they version independently and then you're like, okay, let's just bring this all back down into one monolithic application, repository, whatever, right? Has that ever happened? I doubt it. And like, what might be an example? Wait, did you say monolith to microservices

or the other way monolith i don't want to say microservice but let's just say monolithic to micro something micro units back to monolithic yeah i don't know i know twitter was kind of famous for you know taking their quote of a monolith to microservices that was the first was kind of famous for, you know, taking their quote-unquote monolith to microservices. That was the first I kind of heard about it. But I don't know. I feel like I heard something recently about them bringing things back together. But I don't know if I made that up or not. I thought of some examples that might be.

And two that, well, I only really had one before. But then two just came to mind as I was talking, which was we've talked about in the past, we've referenced both Google and Microsoft with the scale of their repositories, right? And so if I recall correctly, before those things were not in, they were, I think they were individual repositories and whatnot, but then they ended up getting pulled together over time because they found that it was easier to do the development to avoid like dependency diamonds and things like that. Right. If I, if I'm remembering those stories, correct. But another example, if I could take this to, uh, back to gaming is that maybe in like, um, say the, uh World War II comes out, and it's wildly popular.

And so in the beginning of that thing, the application started out as like, okay, let's just get the application working. So it's monolithic. Let's get the infrastructure for everything in place. It's monolithic. And then, okay, it's release time. So now, you know, leading up to the release time, they start breaking things apart so that it can scale. But then after the game has been out for a few years, the popularity declines, there's less of a need to have all that scale. So they start to like, okay, we can bring it all back in together so that, yeah, we'll,

we'll still put out updates or we'll still support the service, but it can be a much smaller entity now. Right. Maybe. I don't know. Yeah, that's possible. That makes sense.

I mean, I don't know of any real ones off the top of my head, but, but that does make sense. All right. So that wraps up. I mean, we just talked about a lot more about architecture in terms of how do you do this and what are the right balances as you're going through and figuring out the way to break up your application so that it becomes more maintainable over time. Yeah, we really had a big focus on what the architect is responsible for and how they,

you know, how they affect those things. Yep. And so now there's some resources we like, obviously, clean architecture, as we mentioned up here at the beginning. You know, if you want to go leave a comment on coding blocks.net slash episode 73, you know, you'll be entered for your chance to win a copy of the book. And also, so recently I'd been, I don't know how I came across this one, but there there's a plural site video or course called feature toggles and package deployment and versioning. And this is by Marcel DeFries, I think is his name. Uh, man, I can't remember anyways. Yeah. Marcel DeFries,

the dude's really good. He did, he did another, uh, another course on using Docker with visual studio so that you can do, um do your entire Visual Studio application in Docker, both the database and your application. He does an excellent job. Well, this one kind of fit into our talk today because he also gets to talking about package management and versioning, at least for Microsoft and VSTS. So it's kind of interesting, like a topic that's come up is, you know, how do you break things out into packages so that they can be deployable and be part of your code in a way that's not a pain? So I left a link for that one here. And you do see feature toggles being used in the wild, too. apart the latest version of say an ios um and they'll start finding hints of like oh hey here's

the hints of what the next uh iphone is going to look like or the support the specs that it's going to support for example yep because they'll decompile the stuff yep yeah and there's there's actually in this video they have nu-git packages for feature toggle libraries. So I wouldn't say that there's a ton baked in to make it happen, but it does force you through a standardized way of doing things. So anyway, really, really good video. I'm about halfway through it and hopefully finish it up here pretty soon. But with that, now it's time for my favorite part of the show, and it's the tip of the week. So Outlaw, what you got all right so

uh for my tip of the week i will give you a get tip uh so have you ever found yourself where you have um changed multiple parts of the same file and you're ready to stage portions of that file but not you don't want to give up the other stuff just yet uh, but not, you don't want to give up the other stuff just yet. So you don't, you don't want to remove those changes, but you also don't want to commit them or even stage them, right? So Git will allow you to interactively stage portions or chunks, as it calls it, of a file or a path. So you can say, get add minus P, and then whatever your file is, or the path spec, and it will prompt you for the parts. And it'll give you like, you know, hey, do you want to do you want to stage this part? Do you want not or

whatever. And it's basically a short for dash P would be short for like a dash dash interactive effectively. That's pretty cool. There have been times that I've wanted to do things like that. And I didn't even know that existed. Yep. It's super awesome. Excellent. All right. So I've got a couple of this time only because as my mind goes, as I get older, I didn't want to forget one of them. So here's, here's two, one is SQL operation studio. So if you work on a Mac and you've been annoyed by the fact that there's no SQL management studio for Mac to work with SQL server, uh, you know, fear no more. You can download SQL operation studio, which is sort of like your

SQL server management studio on windows. And you can work directly with SQL server. And they just released, um, the January version of this thing. And I think it might still be in beta, but really cool stuff. You know, the lines are getting blurred even more now with Microsoft where you can sort of work on just about any platform you want. So that one's really cool. Love that. The next one is, so we've talked about TypeScript a little bit on the show. I mean, we definitely do in Slack channels and various places. I'd never heard of this one. There's one called Flow and it is a way to strongly type your JavaScript or it's a static type checker for JavaScript. And so we'll have a link for that as well. It's flow.org. And this came up in our JavaScript Slack channel the other

day, never heard of it, thought it was pretty cool. So, um, you know, go check it out. I don't know that I'd use it over TypeScript, but it's nice to know that there's different options out there. Awesome. Um, so for my tip, I wanted to mention a new show that actually they don't have a feed yet, but probably by the time that you are hearing this episode, that we'll have an independent feed. And that's Application Security Weekly. And you can listen to it now. It's part of Paul's Security Weekly network, which has a bunch of different shows in the security space. But this one is actually focused on coders. And it's hosted by Keith Hudlitt, who's a super sharp guy, really knows his stuff, and is coming from a space that I understand, right? He's speaking from the coder perspective. So I'm really loving the show. They'll

probably have an independent feed right soon, and you can get it right now via Paul's feed. But I will be updating the show notes whenever there is an independent feed there just to make things a little bit easier for you now in the meantime you can listen to the first two episodes up now and we'll have a link in the show notes but it's a really good show and if you are interested in application security weekly like this week they just talked about the new OWASP changes in 2017 and just have some great recommendations so So you should check it out. Excellent. And apparently I jumped the gun with the show summary earlier.

So yeah, we already did that. Yeah. All good. The responsibilities and techniques for isolation. Sorry, I'm still like I have passed peak caffeine. Like this was just too much for me. I've been like jittering the whole time. So sorry, guys.

Good thing you're standing up. Yeah, it's awesome. Yeah, my feet, it doesn't look like it, but I've actually been running the whole time underneath. Meet me. All right. Hula hooping. So with that, subscribe to us on iTunes, Stitcher, and more using your favorite podcast app. Be sure to leave us a review. You can head to www.codingblocks.net

slash review to find links to all your favorite podcast sources. Oh, yes. Sorry. My bad. I totally... We always forget if you want stickers or some swag, hit us up at codingblocks.net

slash swag and send us a self-addressed stamped envelope. While you're up there, check out all our show notes, examples, discussions, and more. My favorite is our show notes. Show notes. Those are good ones. We have good ones. Have you had too much caffeine?

I have had no caffeine. And if you are curious or confused about how to send a self address stamp envelope or what kind of swag options we have you can always send a feedback question or rant to us on twitter or over at the slack channel codingblocks.slack.com you can actually send yourself an invite and come on in and lurk

or participate as you like make sure to follow us on twitter at codingblocks or head over to the website codingblocks.net where we have amazing show notes and other random stuff. So you'll find all our social links at the top of the page. You can find our YouTube, you know, our other blog articles, all sorts of stuff that we're up to. Check it out.