Innovating Along the FreightTech Journey

Jon: Are we good? Tim say you love Ruby.

Tim: I love Ruby.

Jon: It's recorded!

Chris: That's the episode. All right, we're done here. Good work, everyone.

Jon: Trying to channel my best MKBHD intro. We'll talk about it. We'll get there. Welcome.

Hey everybody. Welcome to Even Keeled. I'm your host, Jon Kinney. And today we're joined by Tim Greenmore,

Tim: Hello everybody.

Jon: Chris Held,

Chris: Hey everyone.

Jon: and Dan Diemer.

Dan: Hey there.

Jon: So today we wanted to talk a little bit about system architecture, some of the evolution of hosted environments, the ability for people to deploy entire solutions to the cloud, whether that be cloud native or dockerized servers behind kubernetes clusters, all the different ways that we can structure a system and build it.

To some extent, the way that we deploy that system into environments and how that's impacted the evolution of systems, design of organizational structures. And what that means to us at Headway and to some of our clients and just some observations we've seen in the industry, as well as perhaps some personal preferences, some suggestions, and likely a little bit of debate around. Things we've seen work well and things that maybe haven't been quite our cup of tea. So, Yeah, guys what do you think would be the best place to start? I know I brought up this concept of Conway's law. Should we dig in and maybe just start the episode around the definition of Conway's law and things that we've seen in terms of working with some of our clients around that phenomena. So, Conway's Law, coined in 1967 by Melvin Conway, states organizations whose design systems are constrained to produce designs which are copies of the communication structures of these organizations. So, that maybe is a little bit Hard to understand stated as such, but this, concept gained popularity when the book, the mythical man month came out. And I think really what it boils down to is you're going to design your systems to mirror the structures of your organization and perhaps even unconsciously. So if you have one team that's responsible for the API and one team that's responsible for the front end, they might have. Entirely different team members.

They might have entirely different managers and all of a sudden now you have these two silos in your company of folks that need to try to figure out how to work with one another. And you could argue that, well, that allows the API team to move on their own and it allows the front end team to move on their own. And they can go faster without having to integrate and rely on one another. And I think there are times when that is true. When you're, when your organization is. Like as large as an Amazon or a Google or a Facebook, one of, one of the sort of web scale type companies. But I think there are also times when that's overkill, especially if you're a startup or even just a corporate innovation team bringing a new product to market. Maybe there's some. Of your existing infrastructure that you need to deal with in that latter case. But it's, I think, unwise to design a brand new system that doesn't even have users yet to mirror something like a Facebook or an Amazon. So anyway, just to state that what have any of you seen in terms of that concept, or do you think that concept is something you. I think it's a good thing or perhaps problematic,

Chris: Yeah. One other little wrinkle, I think especially that we have to manage as being an agency that consults with other companies when you're doing like a corporate innovation type project. The, a lot of times the backend team is internal and the front end team is external. And it's like a very clear line there because they don't want contractors using like the legacy systems.

They don't want them dealing with that. So that's another reason for that sort of. Like hard division there. But I will say that sometimes it feels as though if, we were just given access to the database, we could just write the thing ourselves and it would be a little faster and it would be less of a communication gap. between that, but that's all organizational stuff. And that comes down to how you manage and run your teams and you can solve all those with good communication.

Jon: right? I agree, Chris, that I think that's probably where the rub is though, right? Is it requires thoughtful organization and good communication. There's and there's this concept that there's the exponential communication challenge in software development teams. And this is like that the number of people in a team require Exponentially more nodes of communication, the larger the team gets.

So with three people, you have three connections, but with four people, you have six connections, right? In terms of everyone being aware of everything that the other person said or needs to be aware of in order to build what they need to build. And then at five people, it's 10 connections, six people, 15. And if you get up to, I don't know we do a lot of, development at Headway with eight person teams, maybe five of our team members and three of our client, there are 28 connection points between eight people. And that's a lot to manage in terms of making sure everyone's on the same page.

It requires, I think, really good project management, good user stories, the contracts between not only the members, Two different organizations like Headway and our clients needs to be very well managed. But also if we are working, let's say with a back end API team, and we're the front end team with some designers as well. Now we got three groups of people right and all those different things that need to be passed around and so it's I think there is definitely a point of diminishing returns and that's the whole concept of the mythical man month right they say that hey if it takes four people two months To build a system. If we need that system in one month, we just need to have eight people, right? That's the whole concept of the mythical man month, but we all know that's not exactly how it works. You can, of course, gain some speed by adding people, but the division of labor and the overhead required in order to facilitate that is definitely not something to be discounted.

Chris: Yeah. Yeah. A good example of that is when like developers listening to this, when you have a side project and you finish it in four hours versus like client work where everything seems to take two or three times as long, there's a lot of overhead built in there when you're working with other people, but you can accomplish a lot more.

So there's a trade off there.

Jon: Yeah, I know it's interesting. We do a lot of Ruby on rails development at headway and the Framework was born out of a company called 37 signals, and they famously use a tech technique called shape up that they designed. And I just saw a tweet the other day from Jason Freid the CEO there. And he says nearly all new product work is done by teams of three people at 37 signals two programmers and one designer. And if it's not three, it's two or one, not four or five. He's, he goes on to say, we don't throw more people at problems. We chisel problems down until they can be tackled by three people at most. Thoughts on that.

Tim: I think we've experienced that with Dan and I on an over a year long engagement when it was three at one point there might have been four headway devs full time, but for the majority of that year plus engagement, it was Dan and I, and our ability to do work. Compared to the partner teams that were overseas teams of 5, 1 team was at least 5.

The other team was 4 somewhere in that range. Our ability to do work together far exceeded. Those teams, even though they had two, three times the number of engineers contributing to the effort. And I think a big part of that is just because we're close to one other. We know one another, we understand the technology from front to back and we're able to we're able to support one another in a very efficient way.

So Dan, do you have anything you'd add to

experience

Dan: Yeah. No, I think it's dead on. And I think the reason when I reflect on why that works so well, I think that three person team is like the sweet spot for what you could think about is like a context failover, right? when when one person's heavily engaged in whatever the problem is, they're solving. There's enough context between those other two people. Yeah. To plan for and move forward the next thing and you can keep that kind of rolling and build momentum with that. The more people you get involved the less efficient that becomes the fewer people you get involved doesn't get more efficient because now you're really bottlenecked with each other.

Right? If person a. Is heavily engaged with maybe planning some work person B might be at a stopping point. They can't do anything. So we found with that 3 person set up. It it seemed to really work. Well, because even though two of us might be developers and one person might be a product person. There was enough context about what the next step was that we can always keep something moving forward.

We can always keep that momentum and that fly will spinning.

Jon: Yeah. And all that to say that it's not always possible for a single person end-to-end design and develop a system, especially when they're complex, like mobile applications that need to span multiple. Deployment environments. And I guess by that, I mean, multiple operating systems, at least the two biggest ones right now, iOS and Android. It's difficult for a single person to be able to understand all of the various nuances of both. Certainly it's possible if that's your main focus, but as consultants, we have to build systems for lots of different environments. And so we do have some specialists that all need to come together in order to be able to effectively build.

products. So for example, a react native developer might not be the best person to build a scalable backend system. And I think that's a fine division of labor when that makes sense, but we wouldn't put, say like one of our clients recently came to us asking how we would approach helping bring their organization Through somewhat of a digital transformation where they're, they were already digital, but they were on prem and they had 40 consultants from a top five firm and they were unhappy with the speed. They were unhappy with the quality and The tech was relatively old, and so they asked us, how many people would it take for us to go on this journey of building a mobile application in React Native, as well as some new capabilities for our web application in React? And we're still putting that quote together. But what I mentioned while we were in this discovery call was we would likely have two people on the react native application one person To focus on the ios nuances and ios deployment and app store needs payments can be a little bit different from time to time and then one person to focus on the android side of things now Those two people's focus would be on those specific platforms, maybe only 20 percent of the overall work. 80 percent of the work would be both of them working in parallel on the shared code base in React Native. But it's still useful to have two people to move things forward with some nuance and understanding of their specialty of their platform, especially if that's that person's daily driver For their own phone they just have more familiarity with it, right? So two for the mobile app, and then we said two for the web app. And we've tried to build web apps in React Native Web before, and I do believe that it's getting better. We've talked with the developers there at conferences before and, They have plans, things are moving, but right now in 2024, here in May, we suggested, or I did on that call that we still build two clients, that we build a React Native app and separately, although there may be some shared. Code, perhaps in a monorepo that we build a separate react web client. And so that would be a four person team two focused on web two focused on mobile. And then in, like you mentioned, Chris, they had their own backend existing Java spring infrastructure, and we're likely to put a GraphQL system in front of that. I don't know if it'll need to be federated or not yet at this point, but then that way, our team can call into this relatively new, maybe call it an experiential API that's designed to help facilitate these new experiences that we're bringing to life. And then one of our team members, a fifth person can interface with the existing client's team, and they're trying to hire some internal folks as well. And then that backend team with our bridge person can help facilitate that work. So it does work when done thoughtfully. It's just that when done accidentally, And without the proper setup for communication and the proper setup for planning, if you just say, Oh, well, we've got these two teams and they've got managers and go build some stuff.

Like we've even been put in situations where we have to mock out and Chris, you're on a project right now where this is the case. And I think it's going to turn out okay, but it's a little bit like walking on eggshells. We don't have the backend all the way spun up yet. We're building components and have been for weeks and weeks, if not months in isolation with Storybook.

And now things are starting to come together with full pages, but we don't have a backend API to query into. So we're having to mock out what we think that'll be. And there's probably going to be some churn.

Chris: Yeah, for sure. Yeah, I think about it, it's you have the front end layer, and the furthest edge of the front end layer is pretty solid, and then as you go up, it starts to get a little soft, and the back end layer, their furthest edge is really solid, but as you start to get towards the middle, it gets a little squishy. So, as that stuff hardens we're just gonna have to write some, there's gonna be a little bit of rework. So there is some inefficiency there. That we're going to have to deal with. But that's, yeah, that's common in these sorts of scenarios, like the one you just described, where you have separate teams and they're both working on separate priorities.

It takes a lot of communication, a lot of documentation to keep everybody on the same page there.

Tim: John One One alternative approach to what Chris and Noah are working on, I know that you were You're working with another, a different client in considering was was to leverage live view or if you wanted to replace live view with hotwire in a way that would allow you to interface with that existing aged hardened API and begin to write fresh UI.

On top of that existing infrastructure. And that, that to me is very intriguing, very appealing. Not only because I love to write Elixir, but but I think it allows you to get the speed, of writing separate UI, while be, while not not wrestling with the existing infrastructure, but instead migrating towards something more more modern.

So I don't know if. If you wanted to add anything to that, but I think that's a very interesting pitch that you gave

Jon: Yeah, in this particular case, what's most interesting about it is it's an intentional decision for them to be able to outsource various aspects of their next phase of their business. And so they're a NET company, and they have an existing back end API. They're going to be moving towards React for a front end. And Yet they need partners to come in and be able to build slices of their system, largely in isolation, which is tricky. But if their NET API is documented well enough, and if we're able to help influence what we may need to be extended about that NET API, which f well enough.

rom my discussions with this client, that would be the case they aren't, it's an industry where it's in the financial space. And so they're leery, they're remiss. What's the word I want to use there in the financial industry. So they're cautious about giving too much access to their backend systems to external parties that are not FTEs. And So in this case, we decided rather I pitched that it would be good for us to build a full stack Elixir application, leveraging live view on the front end with the ability then through WebSockets to get real time updates based on our backend's query into one or multiple of their systems. And I thought it would make The most sense and would be the most scalable and efficient to have those queries happen from our backend to their backend, rather than having to try and manage all of that on the client itself. It, it seems like because we also needed our own persistence layer for some intermediary functionality that we would be building that we would need to calculate Various states on there, there would be a state machine of a progression of the user through this application process. And so we needed our own full stack system, really, and why build a totally separate react app in a totally separate repo with our own API and the complexities that are required in maintaining those two code bases, that handshake and all of the nuance that's required there. Why not just build a full stack system that can still act very much A spa for the client and yet gain more control by making those calls from our back end. So that was my proposal. We're still in the process of working through what that's going to look like to get started, but I'm optimistic that's going to help them achieve their goals and allow us to work in a way that's most effective for our team. So, I mean, super leaning into Conway's law there. And and yet at the same time, I. Frequently view Conway's law as a negative. So I suppose it's all a matter of context really.

Tim: could Jon Can you explain that a little bit more? So how that's leaning into Conway's law?

Jon: Right. So the organizational structure is literally two organizations in this particular case, right? So our client and their team, and then Headway and our team of developers. And so even within the context of those two organizations, there are more. silos. And that's the whole concept is that this system that is going to evolve from the humans involved from the humans that are creating it will mirror those communication and organizational structures.

And so we're literally saying one of the organizations is going to build a system in isolation that will then talk to another organization system through. API calls and that contract will then need to be negotiated between the two of our organizations.

Chris: So it was the API call. Is that like the scrum master in this scenario? It's the project manager.

Jon: Could be. Does that make sense, Tim? Any, anything else you were wondering about that?

Tim: Yeah. Yeah. That helps clarify. So that's not necessarily inherent in this systems approach that you described from a technical perspective, because that same that also exists, whether it's react or any other technology with a separate API talking to that existing backend. I think the appeal to me in what you pitched Is that it eliminates the need to manage to really to introduce two new disparate systems, a react spa, a separate API, which then talks to the back end.

Instead, it introduces a single full stack solution and in that way, I think it minimizes Conway's law so I just wanted to clarify

Jon: Yes,

it does. Right. Yeah. It minimizes it while still allowing the overall engagement to benefit from that concept.

Tim: Yeah. Yeah, that's great. Thanks for clarifying.

Jon: But yeah, I

guess it minimizes it on the headway side specifically, I think is your point, right? So it's less of a burden for our team because we can work unified in a full stack scenario. And then by nature of the engagement's requirements, but that were two separate teams helping them build something that's just that bridge that we have to cross between our two organizations.

Chris: and with with react server components, now you can actually do full stack react dev You don't actually need to make a separate API and a separate spa anymore. So I guess technology agnostic, like that does make a lot of sense to just have one single app, especially when you're keeping team sizes small. I think that's a, that's an approach that, we usually recommend.

Jon: And I know a lot of the argument in the prior decade for using JavaScript in the first place on the. on the server was that you could have the same language on your client as you did on the server. And so now with the ability to do full-stack JavaScript development with React server components yeah, whether or not you like JavaScript, I do like that better than having to have two entirely separate systems. Not that I hate spas they really helped push the state of the art forward in the web. I just think that and they solved a very Real problem when they first came about right Full stack server rendered development was quote unquote the golden age. I've heard people say back in like 2004 to 2009 or so, where it was, easier so to speak, to just build something and it would work, and the user would wait until the whole page was ready and then it would load and they would do the next thing and they would wait until the whole page was ready and it would load. But. Our appetite increased for what it meant to have an application live in the browser. And we wanted them to feel more like desktop apps. And that's where SPAs really helped bridge that gap until technology was able to catch up. And as Chris and Tim have mentioned it, it is a moving target. And I just think that I don't want us to get stuck as an industry in thinking that. The only way to achieve real time capabilities or the best developer experience is to have those two separate instances within your system. So that's a little bit about architecture of systems, a little bit about Conway's Law with regard to how organizations in their own walls Work between teams, how headway as a consultancy works with some of our clients but let's talk a little bit deeper about some of the technology and this concept of migrating from on prem to the cloud.

Of course, we've also talked about the fact that some companies, again, 37 signals championing this are going back and taking control from the cloud to their local on prem situation so that they can own their servers they can. Do things without having to pay the metered experience and that technology once again has helped make that so much easier. But at the same time, there is still a good place for the cloud to exist. There, there's a place where it makes sense. And I think there's still a place for microservices and various aspects of that architecture. To help things scale more effectively, Tim, what do you see in today's technology that is helping either on the cloud side of things or bringing stuff back to on prem or something in between where the tooling is perhaps solving a problem in a unique way.

Tim: Yeah, it's good. It's a good question. I've been very intrigued with what Chris McCord had announced known as the flame pattern. He announced this a few months back and he recently presented on the pattern at ElixirConf EU Oh, that video is. The video is just published this week, and so we can share a link to it if folks are interested in seeing what the flame pattern does in action.

There's a lot, there's a lot that could be said about it. 1 One thing that sort of undergirds Chris's, inspiration for flame was he wanted to not just solve a problem, but he wanted to remove the problem. And I think that's a very pertinent goal, a very pertinent observation on his part, because we often, we get focused on solving problems, and that's what we have to do as engineers.

But it's good to stop sometimes and say do I need to solve this problem or can I remove it altogether? And so what the flame pattern does is it's a pattern, and so it's not specific to any particular language, although Chris is presenting it in the context of Ruby. Using the flame elixir, excuse me.

So the flame pattern is not specific to any language. It's a pattern, although Chris is presenting it in the context of elixir. And there's an elixir library with an adapter for fly and for Kubernetes. And so if you're using https://fly io, it's very. Easy to test out the flame pattern using Kubernetes.

There's an adapter for it and it should work on on other platforms. And so, so what is it? So the beauty of flame is that I could take. A specific block of code in my app, and all I need to do is wrap that block of code in a flame block, and what that gives me is that block of code now will be offloaded to a different node in my system.

Invisibly, I don't need to do anything more. I simply need to wrap that code in a flame block and it will scale elastically based on how I may have configured flame up front. And so I might say scale flame from zero machines, which would imply that there would be a cold start involved. When that block of code is executed or make it a minimum of one or two, whatever your minimum is up to a specific number of machines.

And so the beauty of being able to wrap a block of code, or if we wanted to put it differently, a specific function within your app. And so what Chris often uses as his example is transcribing video, generating thumbnails from images. And so historically what we would do is. If we're, if that's a function of our app, we would offload the responsibility of transcribing, transcoding video or generating thumbnails from an image to a separate machine.

And in order to do that, we're passing state from our main application to that separate node, and then somehow we're getting notification when that work is complete, we're getting notification if there's an error in that code. If it failed, like what's the status of it, right? We're having to track state for for that piece of work that we've handed to a separate node and then getting it back again into our main application and flame removes that all of that management of state without losing the elasticity that we.

We need and the scalability that ultimately that we need when doing something like, something that's very work CPU intensive, like, transcoding video.

So,

Jon: That's super

interesting because in the past,

Tim: but

Jon: it says your network is struggling, Tim. I don't know if you're getting those notices as well.

Tim: I, I have been, but I, hopefully it's recording. Okay. I can hear you guys coming through. Okay.

Jon: it's recording locally, so you should be good. I just didn't know if I was delayed in my in my chatting with you. But I'll try and jump in again. That. That's super interesting, Tim, because in the past, we may have thought, Hey, there's this aspect of work, this heavy workload, we need to go create a lambda function on AWS, and write all of that code and deploy it there, which, historically, or rather, in a naive way, you might think you need to write all of that code literally in the browser within the AWS console.

And some people probably do that. I think there are, I know there are. There are ways that you don't have to do that interaction just within the browser. You can write the code locally and push it up, but it still requires you to have to think at a more granular level and somewhat in the context of that cloud vendors capabilities. Whereas you're saying this is all a part of the stack that you're already building in and it handles it on the backend. So I think that's. amazing that requires no additional work or thought from the engineer outside of the context of their full stack solution to be able to deploy that in an effective and scalable way that's wonderful

Tim: Yeah. And I think that's the other main, one of the main benefits is the deployment, the DevOps aspect. I don't need to stand up another node that has all the dependencies. Needed for video transcoding or for image processing. I don't need to manage now two separate nodes. I just have my full stack solution that gets deployed.

And that's it. I just don't need to manage different things from a DevOps perspective. And there's a significant gain to be realized in that scenario.

Dan: I think what's

cool about that example that Chris has put together with flame is the level of DevOps knowledge you have to ramp up on to be able to use it is very, the very like shallow grade versus all the things that would be required maybe to stand up something over in a cloud. On a Lambda. If you're coming in from like a zero, like I'm just doing programming, I'm just doing web development, but I know that I need to do this thing over here. I need to run this Lambda. There's a pretty steep curve. I think to that, to get it set up in a really scalable functional way, like DevOps knowledge that you need to learn. And here in this paradigm, it's a little bit. More straightforward. It's more bite sized and it's like just a little bit of a chunk that you can add to your existing knowledge and then you've got it. And it's all you need to know. And I think that's really compelling.

Jon: yeah it's great that's baked in like we said to the full stack framework but for people who aren't using elixir or maybe don't have their what's the word Aren't using Elixir or their community isn't leaning into that flame pattern. I think there are some existing capabilities in. This is you, right? Chris, the super base for cell Netlify thing.

So I'm going to try and throw it to you here in a second. For people who it's great, full stack, blah, blah, blah. But for people who don't have that capability yet baked into their frameworks of choice or into the libraries that they're developing with, let's say a react application. I think there are some existing similar ideas within some of the hosted environments like supabase So Chris, do you have experience with that?

Chris: Yeah. There's a lot of the more modern, I guess, popular hosting solutions or even the database as a service like Superbase or Netlify or Vercel, like they do a lot of this too. It's really interesting. We were talking before we started recording here how like web development as a whole is converging around like these same ideas. We're realizing that like managing your own cloud functions on GCP or AWS is there's a lot of friction there. And it's also, it's cross domain because you want to just build your cool stuff in your domain. If you're building a, an e commerce site where you're trying to sell some clothes, like you don't want to care about your infrastructure.

You just want it to work and scale up if you get really popular. And there exists now these tools in between AWS and in between GCP and whatever cloud providers that make that even easier for you. So you can just go right, like super base is a good example, like it has cloud functions, but you almost don't know that they're cloud functions Vercel Also, like when you're writing cloud functions in Vercel it's just part of your code base. You have no idea that it's, unless you like specifically look. It's no difference to you as a developer when you're writing a cloud function versus just writing a function that fires on the server. And the same sort of we're getting off topic, I'm getting off topic. Whoa, I'm getting off topic here, but the same same sort of paradigm with live view, hotwire, server components where we're realizing that like everything on the server is bad and also everything on the client is bad. So the best state is serve as much as you can from the server and refresh the client when you need to.

Tim: Yeah, Chris, I think that's well said that convergence that you're describing, it'll be very interesting to see if the flame pattern inspires. Libraries in other languages and other communities. I, Chris has said quite often in his presentations on flame that it's very little code. And so I imagine that somebody creating a flame library in Ruby, for example, wouldn't take a it a whole ton of effort.

And then and then that same pattern And then that same pattern can be realized and taken advantage of across communities not cross communities, not just Elixir.

Dan: Yeah, actually, fly has an article on their blog from the last couple months, um, detailing how you would use that same pattern in JavaScript. There's a lot of caveats with that. It's clearly not as. As developed as it would be on the elixir side, but you can start to see those things forming. And that's pretty exciting because I think what it does is it, when these things are commoditized in a way that developers can just use them without really thinking about it, I think it opens up what what novel things they can build. In different ways, right? So if you look at Chris's example Chris McCord's example on his flame documentation of building something that's, processing video and generating thumbnails when you as a developer know that's the kind of thing that you can build and build pretty easily. I think it broadens your horizons on what potential build can even have, because if you don't know that's a capability you could have, you might not even reach for it. And so having these things be out there and just be so easy to throw to something like Supabase or Netlify or pull in a flame pattern to do this kind of work, I think is going to be a key to unlocking what like that next baseline level of what a web application is.

Jon: And then really nice thing going back to Conway's Law for a moment is historically, if you had perhaps, and I'm not trying to pick on Java, but just that's top of mind here with having mentioned it earlier in the episode, if you had a legacy JavaSpring application and you needed the ability to have a really heavy workload, and let's say you were hosting it on your own premise, your own your own local data center, You would probably have a separate team that was working on that higher throughput section of your application, right?

And they would need to say, all right, well, what are you passing us? We'll process the video. We'll munch it this way. We'll encode it this way and we'll compress it and kick it back to you or something. That would be different people trying to achieve that capability, whereas when it's just part of your full stack and has the ability to scale in the background, you don't need that separate team.

The regular, so to speak, developers can handle that.

Dan: Yeah. And even on I've actually worked on a team who had a video processing feature in some of our applications and it was scattered across, a variety of different Amazon services. And when changes needed to happen, they were heavily bottlenecked by the one person who really understood it, understood where everything was, understood how to deploy it. And so like you're saying when it's then brought into your full stack. That just benefits everybody, right? The context is there for everybody. Junior developers can look at that code and learn and understand and level up instead of having to go, poke around and try and understand all these other concepts just to get to the thing that's actually really business important.

Jon: I was trying to see if it would make sense to mention this new tool that I've recently become aware of called Medify. It's this software that has the ability to plug into your own hardware. And it abstracts the management of that hardware to a higher level where it can talk to the chips on the motherboard and monitor it and all this stuff.

But I don't think it really makes sense for this discussion too much.

Tim: Well, John, do you think, I wonder if we could do a part two of this topic? Do we have enough material here to keep,

Chris: I don't know.

Jon: Probably not. I don't know. What

do you, what are you covered just about everything.

Tim: did we? Okay.

Chris: I guess we didn't talk about scaling, but that's a, it's a boring solve problem at this

Dan: Yeah. Just these little experiences.

Chris: Well, you either use a bigger server or you use more servers. I don't know if anybody's really interested in talking about that.

Dan: Probably the people that

Tim: I feel like there's,

Dan: we just told aren't necessary. Like all the DevOps people would be interested, but we're just, we just did 40 minutes about why you don't need them anymore.

Chris: Maybe they skipped this one. Maybe they listened to the next episode.

Tim: I feel like there's an, there's content in this episode that John, you could share in a sales call or

Jon: Yeah.

Tim: yeah, I want to take advantage of that, but maybe we've. Maybe we said enough

Jon: Yeah. Let me try and wrap it up here. Well, thanks for the conversation, guys. This has been really good. I think for me, one of the takeaways is that Conway's law isn't necessarily positive or negative. The ability to design systems that mirror your communication structures of your organization can be beneficial but it can also be detrimental if not. taken into account at the if not taken into account on the onset of the project itself. So for example, when we're working with a client and we need to handle one whole slice of what they want to do, it plays into our advantage. When we're all working in the same code base, but we have arbitrary silos because two people Need to be managers because that's where they exist in the organization that can perhaps be detrimental.

And those artificial silos can lead to delays and more complexity than is necessary. So it can be, it's something to be aware of and something to manage to your advantage. I don't know. Can you guys chime in with yeah, this has been great or I agree or I don't know something. Was that a good enough ending?

Tim: math. I think you put a bow on it.

That sounded in me, John. But yeah, we could chime in and affirm that if you want to back up a minute.

Jon: Sure. Blah, blah, blah, blah, blah. To be managed. Any other thoughts before we wrap up, guys?

Tim: Yeah, I mean, this has been really good. I, the questions that we get from clients and the innovations that we all consider when we're trying to help a client or working on something internal, whatever those innovations are that we try to apply to the problem at hand. It's. There's many of them and it's constantly evolving.

So it's really good to pause for a minute, hear from everybody's experience on the call and

and to be able to just identify, are we solving the right problem or is there a way for us to remove the problem altogether and just work smarter, not harder,

maybe that's putting another bow on it, you might've been fine.

Jon: Well, let's get options. Dan?

Dan: I have a dog sitting right next to me doing that. So

Chris: Make that Yeah, the outro.

Dan: me remove him real quick.

Jon: Chris?

Chris: Okay, I'll yeah, I think it was a good conversation. I think that one of the main takeaways that I took from this is your company's communication structure drives whether Conway's law is good or bad for you, which is obvious, but then once you say it out loud, it makes a lot more sense. So

if you have good communication within your office or within your organization Conway's law will really help you. If you don't, or there's some gaps there, then, maybe it's going to hurt you a little bit.

Jon: Love it. Dan?

Dan: Give me a recap real quick of Chris, what Chris said. I had my headphones off.

Chris: Conway's law, good

Jon: And or bad.

Dan: Okay. Yeah, I think it depends. Honestly, I, there, there's going to be times where you have to have it. Right. And so I think it's a tension to be managed. But I think the more and more that we can be aware of it and make sure that we're designing systems in a way that aren't just going to fully implement it, then the better off we're going to be.

And I think that's what we're seeing as a lot of these new techniques are converging things like we've talked about in this episode and things we'll probably find out about more this year as more and more new approaches are coming together from. These battle hardened languages that were pretty deeply entrenched in. So I'm super optimistic about the future of of software development and web applications.

Jon: Yeah, appreciate the conversation, everybody. I'll do a little bit more research as more comes to light around 37 signals migration from the cloud to on prem. And they have a technology called Kamal that they're using to be able to easily deploy Rails applications. Onto your local infrastructure, and I'd be curious to see what capabilities they have for some of that elasticity that we talked about and not just spinning up another server or spinning up a beefier server to begin with, to be able to facilitate some of those higher intensity portions of an application.

So more to come on that we'll do a blog post or some additional content on social to follow up with this episode, but appreciate the time. Everybody

Chris: Thanks.

Dan: Thanks.

‍