Crafting Code Podcast

[00:00:16] Allan Stewart: Welcome to the Crafting Code Podcast, where we discuss the importance of doing the right thing at the right time with the right tools. I'm Allan Stewart, a software architect, and lately I've been thinking about the disparity in preparation between players and their game master.

[00:00:32] Dave Adsit: I'm Dave Adsit, a VP of engineering, and recently I've been thinking a lot about designing systems for efficiency versus efficacy. In other words, resource efficiency versus flow efficiency.

[00:00:45] Allan Stewart: Our topic for this episode is context is king. We're going to explore the idea that context matters, that it's important. It informs everything we do in software. And a little bit about why that can be difficult.

[00:01:01] Dave Adsit: Yeah. So I think that one of the things that makes this interesting is that it's so obvious in the physical world, right? When we talk about physical things, like I have the suburban standard collection of automobiles, right? I've got a pickup truck and an SUV and a car, and they are all good at different things. The car is the fastest. The SUV holds the most people. The truck tows the most things and is the most comfortable in the Home Depot parking lot, right? And that is obvious. You would never take my little sports car to go buy lumber at the lumber yard. You would never try to tow a trailer with it either. But likewise, you would not want to try to haul eight. So each of these things is fit for purpose and the purpose is different. And the context of the problem you're trying to solve determines which of these is a good solution. None of them is general purpose for all solutions or all problems. In software though, that is not always as obvious. We talk a lot about best practices or patterns or things like that. And we'll dive into all of those in more detail. But in software, there's always this idea that there is one answer to rule them all. In fact, I've actually been asked, why can't you just tell me what the perfect architecture for this system is? I'm like, well, it depends on what the system is going to be doing. It depends what the system is going to be doing now and later, and how we plan to get there. And people who are not well-versed in software or don't have experience building systems or different types of systems may not find that particular answer very palatable. I've gotten a lot of pushback from time to time when people want to have the one right answer. You know, if we're in math, if we're doing arithmetic, there's one right answer. Software, there isn't really one right answer. And you have to know a lot about the context in order to know what kind of a system you're going to be building and how you're going to be building it and delivering it and what it's going to do.

[00:03:25] Allan Stewart: Right. There's not silver bullets. Or conversely, maybe there are. But if you're not fighting vampires and werewolves, then maybe silver bullets aren't the right kind of bullet you should be using in the first place.

[00:03:38] Dave Adsit: Right. That is actually one of the problems.

[00:03:41] Allan Stewart: Yeah. And with software, like you're saying, there are a lot of things that go into it. Right. Like in your example, what's the best architecture for this system? Well, it depends. And it's not just about what you want it to do, but also how are you planning on building it? How many developers are you planning to hire? At what skill levels? And there's a host of things in the socio-technical sphere that you have to think about beyond just how does it work? You know, what? What languages are you going to use? What technologies are you going to use? What architectural patterns are you going to use? And all of those have pros and cons depending on what's going on. And that's where context really comes into play to help you to know what you're going to do. And the business might not even be the same. Right. It's really easy to imagine a great software architecture for a system where you're imagining a future state where in the future, we will have all of these customers and we will have all of this money and we will have whatever. But getting from here to there is the challenge.

[00:04:55] Dave Adsit: Yeah. So one example that immediately springs to mind is you and I have a friend who worked at a small software company that was a spinoff, a startup that spun out of a much larger software company. The original company had grown over years and had several hundred, engineers supporting a very complex system. And the startup, when it spun out, had 10 people, but their product was built on the same infrastructure and architecture and patterns as the original software, because it was a tool built within that context. Right. So what you can support with 300 engineers versus what you can support with 10 engineers is wildly different from the perspective, uh, of operating this system. They had very skilled engineers on either case and they had, but they had very vastly different contexts that they were operating in. And the number of engineers running the system was a huge factor. They were almost two orders of magnitude, fewer engineers trying to operate this system. And so they had to do a lot of work very quickly to simplify and reduce the system to a point where it could be supported by, the 10 engineers who went to the startup from the 300 plus person company that was, that had built this big complex system over time and, and had more than 10 people in the operations department just to run it, let alone, you know, the entire engineering staff that had to build a new product within this complex microservices system.

[00:06:39] Allan Stewart: Right. And so we can't just tell you how to do it right in the, in the, in that case, if they have a question, if they have a question on the startup side and they go back to their parent company and ask, well, how do you manage this particular problem? The answer to that question might not be suitable for the spinoff company because the context is no longer, is no longer the same, even though they started from, you know, the, the shared origin. Yeah.

[00:07:08] Dave Adsit: And that's, that's why every time you ask an experienced software engineer, you get the infuriating response. It depends. And so what it depends on is your context, right? It depends on the context of the problem set and the context of the solution set and the context of the people and tools available, the, the timeframe available. All of these things go into the context and affect what makes a, an appropriate solution for this software problem.

[00:07:43] Allan Stewart: And it always applies when you're getting, when you're giving advice or consulting, you can't just tell somebody how to do it. And I think again, like in the physical, like you were saying before in the physical world, that's sometimes more obvious, right? If, if you were asked to give advice, like personal advice to a stranger, you would hopefully know that that's not appropriate. It doesn't make sense because you don't have any of the context. You don't know about them. You don't know what they're like. So, people may speak. They may speak. They may speak. They may speak. They may speak. They may speak. They may speak. They may speak. They may speak. They may speak. They may speak. They may speak. They may speak. They may speak. They may speak. They may speak. They may speak. They may speak. They may speak. professional consulting a couple of times. And the first few times I did it, I was really amazed at how much of the effort was spent in coming up to speed on context. I knew about this principle previously. And so I, I tried to prepare myself for it, but even then it was more difficult than I had imagined just because there are so many little details and so many things that have to be uncovered. And sometimes they were really curious. Why do you want to know about that? Like we're asking you for this architectural thing. And why are you asking us about how work enters the system and how it goes through a software development lifecycle? Like, well, it's kind of really important to the options that you're going to have to fix the problems that you have

[00:09:37] Dave Adsit: because context is king. Right. This is one of the things that over time you start to develop a toolbox. Of different strategies that you can apply in different, different contexts, different places, different problems. And it really can start to evolve into kind of a pattern language, right? We talk about software patterns and we talk about speaking in patterns. When you've worked together with somebody and you know, similar patterns, then you can very quickly communicate. But if you don't have that shared vocabulary, you can't communicate nearly so quickly, right? You have to describe what you mean by that pattern. And I think one of the interesting things about patterns is that when you look at software patterns, they, they all start with a description of the context of applicability. And that is often ignored because sometimes I just want to apply a pattern because I like it. I really want to have a microservices architecture on my resume. So microservices must be the solution to this problem. I know we only have three engineers and none of us is very good at DevOps. But if I'm going to get microservices on my resume, we're going to have to start breaking this monolith into a whole bunch of services really quickly, right? So that being an example of when the, a pattern or the solution is not necessarily fit for purpose. But I, one of the, I, I really like that the, the patterns come with a context and they describe a context where this is potentially a good solution. I read at one point, that when the first patterns book came out, the Gang of Four Patterns book, before it came out, hardly anybody ever used a singleton pattern because it just was, it's not applicable to very many things. And most things in software, we want to have more than one and we want them to operate in parallel, et cetera. But you know, sometimes you have a single physical device that must be operated on in a, in a one, in a one at a time serialized type of way. And so using a singleton is a good way of ensuring that you don't have two threads sending data to the com port at the same time. Right? So once the patterns book was published, everybody suddenly had heard of singletons and a lot of software systems grew singletons and a lot of things became singletons. And a lot of those things should never have been singletons, but it was a pattern that was easy to

[00:12:08] Allan Stewart: understand and recognize. So, yeah, as you were talking about that, it was reminding me that when I was in, in college, I had the good fortune to have a really good professor for a few of my classes who had some industry experience and would talk about some of these things. And he talked to us about software patterns and it was difficult at first for me to really understand what he was talking about. And I think this is one of those language issues, like even just the word pattern, like when I would hear it, I thought I thought about patterns more like a stencil, right? Like, oh, well, you can you just draw, right? You take out your paper and you draw a bunch of patterns. And if you're really good, you can make them, you know, look like they all tile together or whatever. And we want to do the same thing with software, right? Like, write your code in the same way that you would take the pattern brush in your art program and just rush it on there. But, but I don't know, like maybe guide or template or some other word might have helped. You know, it's too late now because we've got we've got patterns and software is just overloaded with overloads. But I think it's really important to come back to that idea and understand, well, what is it that you're trying to do like this? This isn't meant for you to just, you know, lay down this pattern and paint with a like a brush. But instead, the concept of the pattern is, here is something that you can do. And I think that's really important. And I think and like a certain solution for that problem. And when we take it out of that problem, problem space, then it's just not applicable anymore.

[00:13:57] Dave Adsit: Well, and you've got me thinking that another word that might be applicable in this space is recipe. And I like to think about recipes also have a context. For example, in the context of baking, you should follow the recipe very, very precisely. because baking is more of a science than an art. It's more like chemistry than it is like painting. But if we're talking about omelets, well, the recipe for an omelet is really just a good starting point to jump off from and you can do whatever you want from there, right? And so I think that baking versus cooking, if you want to use that distinction, recipes have different meaning. There's actually context even within those recipes. Is this something you should follow point by point, letter by letter? Because if you don't, things are going to get messed up. We have a chart in our kitchen of nine different ways a chocolate chip cookie can be messed up and what you did wrong to get there. Too much butter, too hot, too much flour. And you have to be very precise. And we follow a recipe when we make chocolate chip cookies in my house. But then we've got other things where, like I say, specifically omelets, love to make me some breakfast cereal or some breakfast foods. Omelets, you just put whatever you have available in there. It can be ham, it could be sausage, it could be cheese, it could be vegetables. If it's for my kids, then it's probably just the cheese and not even the eggs. But context applies even in applying a recipe to what you're trying to make. And so for me, this is just further reminder, further reinforces that there are no truly universal practices that have to be used in every situation. You know, we talk a lot about what are the best practices. And the truth is that the follow-up question for that should always be best for what? What is the best practice for managing a team of 300 engineers? Well, that's different than what is the best practice for managing a team of three engineers? What is the best practice for building? A web application? Well, let's ask some follow-up questions. How many concurrent users is it going to have? What is the expected latency for requests? There's so many questions that we have to ask to really get to what is potentially best. And all of those questions are around defining and constraining the context.

[00:16:36] Allan Stewart: Yeah, the whole term best practices is one of those trigger words. It sets me on edge. And I think, why are you asking this? Because too often it's people wanting to apply something without inquiring about the context. Well, this worked before, or I've read this in a book or something. And they're like the, you know, to use your recipe example, they're going around. It's like, well, this is how you make cakes. And sometimes you don't want to make a cake. Sometimes you want to make something else. Yeah.

[00:17:09] Dave Adsit: Well, and I like to think about best practices, Which is also kind of a trigger for me as a way for someone who has not spent time developing a sufficiently broad technical toolkit to make decisions that seem smart enough, right? Sometimes that's an engineer that just doesn't have very many years of experience. They haven't done very many types of systems. They've, you know, whatever. And sometimes it's a non-technical manager who finds themselves leading an engineering team. And they want to know, well, what are the best practices? Because I don't know how to do the thing that we're doing. I don't have training as an engineer to evaluate things. And so I'm operating a little bit from a position of fear and a little bit from a position of ignorance. And between the two, I just want you, I want a reassurance from you as the technical person that you are going to do the right thing. And if you can tell me, oh, this is a best practice I read in the ITR, I read in the EEE magazine, now that is going to make me feel a little bit better. Back in the 80s, there used to be a TV commercial and nobody, or maybe it was just a saying that we had in the industry. No one ever got fired for hiring IBM. And maybe hiring IBM was the worst decision you ever made in your technical career. And maybe it cost the company millions of dollars and never delivered a product. But nobody ever got fired for hiring IBM because IBM was supposed to know everything.

[00:18:38] Allan Stewart: One of the areas of context, that I think about, and maybe it doesn't get enough attention, is the idea of what do you value? As you're looking through and trying to figure out what do you want to do? How do you want to act? A lot of the practices should really come out of principles and those principles can be founded on values. So for an example, there was a point, where me and my coworker stopped pair programming. Now, if you've been listening to this podcast for a while, you'll know how much I've talked about how great I think mob programming is and pair programming in general, because that collaboration is just, it's magical. It's great. And I was working with somebody who had done that a lot already in the past. I had mobbed with him many times in the past for periods of years. But we got to a point, a period of time where because of our context, we didn't think that it made sense anymore. And so I had to go back and look and see, well, why do I value mobbing? I value it because I want to have quality software. I want to have a high level of understanding between the members of the team. We want to have consistent delivery. So those are things that I valued. And it was based on principles, right? Principles like communication, fast feedback loops, redundancy, flow efficiency over resource efficiency. Those are all things that are good, solid principles. But collaborative coding also has its costs. There's there is resource inefficiency. We can't do parallel delivery. Team members must be working at the same time. Social burnout. There are others, other costs. And what we discovered was we were at a point in this small company where those costs were outweighing the benefit. I already knew what to expect from this. Particular developer. I already knew that he would deliver quality software in a way that I would already understand. We, we already used a lot of the same patterns and had similar ways of attacking a code base, but the code, but the general level of the code base was had had terrible quality. And so even though sometimes one of us would make mistakes and we wouldn't do it as good individually as we might do it together. Either. One. Of us is going to do a lot better than the terrible quality of the code that we were in there to restructure. And so we decided that it was better for us to break apart for a while. And then we moved instead of a strict collaborative coding to more of that um, parallel coding kind of style where we were still on zoom, we were still collaborating a lot, still doing a lot of code reviews on demand and it worked. It was great for us because the context. Informed. That decision. And when our context changed and we hired a new person, we started mobbing again, because that was the right thing to do at that point to help bring in a new person and help bring them up to speed. And so I think that context helps us pick those practices that maximize what, what we value and you have to know what it is that you value if you're going to be able to make that decision.

[00:22:08] Dave Adsit: Yeah. And that. Yeah. We. We. We. There's an almost infinite number of these things that we could potentially value. And they're all different in different organizations in different contexts. If I'm working in a financial institution, I'm going to be very much worried about the safety, security, data integrity. If I'm working in... This hopefully never happens. I don't want to work in this stress. But if I'm working in medical hardware devices, medical devices with hardware and software combinations, that to me, I need perfect reliability. I need these systems to have zero errors, zero failures, right? Because they could potentially hurt or kill someone. If I'm working in e-commerce, well, okay. If we're doing thousands of transactions an hour and one transaction goes bad every couple of hours and people can retry... What? What's the big deal? Like maybe I need two and a half or three nines of reliability, but maybe I don't need five nines of reliability. If I'm a cloud provider, well, I sure better have four or five nines of reliability because if I'm planning to sell my services and not have every single customer leave the first time I have a five-hour outage, I need to be able to deliver in a highly reliable way, right? My systems can't go down if other people are building their systems. And so that becomes one of the things that drives how we are delivering as a company. And that is, again, that's reiterating what are the values that we hold and what practices, what principles come out of that. So I think I've mentioned this before, but I read that in the first space shuttle, they were very memorable. They were very memory constrained. And so in the C or C++ that they were probably C that they wrote to fly the shuttle, they unrolled all the loops because a single loop that ran, fell into an infinite recursion or infinite loop could cause that space shuttle to no longer be responsive and then crash and kill people. That is too high of a cost. And so that code becomes less efficient or less effective to read. It's harder to read because... You've unwound all the loops, but it's safer. And so I wouldn't recommend that people do that generally in the e-commerce software that we build. I would like people to use the tools that are available to them, including loops. Because if one of our web servers runs out of memory or, I don't know, whatever, we can spin up more of them. We have the ability to get more servers very quickly because we're cloud deployed, right? It's different. If you are physically located in a cloud and disconnected physically from the earth that you have left.

[00:25:42] Allan Stewart: And I think that as you're considering what you value, there might be multiple ways to get at that value, which is another reason why I just, I don't like best practice because like you said, there's the question of best for what, but also is it, is it really, really the best in every circumstance? There may be different ways to get at the same bit of value. So for example, going off of the example I was using before, mobbing is a great way to build shared understanding. If one of the things that you value is, you know, collective code ownership, well, then that's a great way to go about it, but it's not the only way to go about it. There are other ways that you can facilitate knowledge transfer between your humans. And maybe one of those ways is better for your context. As we communicate, there are lots of different ways. There are ways that we can interact. Personally, I don't like code comments because I feel like they lie to me more often than they're useful and they just clutter up the screen and I'd rather get rid of them and make my code self-documenting. But there are times when that is the appropriate way to communicate. And so if we're too draconian in applying our practices or we might, we might have a practice. Don't, don't use comments. And then you don't use a comment when it would have just made a lot of sense. Well, then now you're hurting yourself. You're not actually reach realizing that value that you're looking for because you were too hung up on the practice rather than what you're getting out of that practice.

[00:27:18] Dave Adsit: Well, and the absolute reverse is also true, right? The idea that you should have one of the early best practices commonly still used probably is heavily documented code document, every public method, all the inputs, all the outputs, all the response of what it's expected to do. You know, describe the method. And how to use it in a comment adjacent to the method. And that works really, really, really well. If you are building the base class library for a language, if you are building an API that is expected to be reused by tens of thousands of engineers in toolkits that can read and display those comments as a, as they are using those methods and functions and classes. So, you know, that is very good advice. If you are Microsoft building. A C sharp API. But that doesn't mean that it applies to a team of three. That is working on internal code only. Right. Right. And that's one of the best practices that often trips us up. Is, you know, what is the context? Well, this is the best practice in the context of I'm building an API for tens of thousands of engineers worldwide. And they need to understand every method, every public method in our base class library. Well, okay, great. You should document. It. The only people who are ever going to call this method are two people who sit next to me and have access to the source and the unit tests. Maybe the source and the unit tests themselves can be sufficient or more than adequate documentation of what the thing is. And if not, well, I'm sitting right here. Right. So again, that goes down to what is best. Well, best in what context best for what purpose, what are we trying to do and how can we do it? You know, I've often been asked by. Executive. Yeah. Team members, CEOs in particular, how many engineers do you need? And my response to that is always to do what and by when. Those are two very critical components of context to determine how many engineers I need. If you expect me to build a competitor to Google, I need a lot of them. If you expect me to, you know, ship a single component, a single react component for use by another team inside of my organization. Well, I don't need very many, especially if it's not very timely. You know, if we have sufficient time to build the thing, it's a different, it's a different, different context, right? It's a different set of constraints that drive me to a specific need.

[00:29:49] Allan Stewart: Right. And if you have a specific deadline in mind, then you maybe need less people or at least not adding more new people who need to be onboarded and learn what's going on because that slows you down. Yeah. Instead of speeding you up.

[00:30:06] Dave Adsit: Well, and that's the thing, right? You can take a very experienced developer, 15 years in the target language, in the target toolkit, and you can bring them onto a team and they won't necessarily be a productive contributor for several months. And why is that? It's not because they don't know how to program. It's not because they've passed your interview process, right? It's because they don't have the context of your code base. Maybe they've worked on three other code bases that didn't. They've worked on three other code bases that processed financial transactions and recorded them to a database, but they don't know your data model and how you're using it. And so it could take time to bring them up to speed. And so, again, it comes back to the fact that we cannot operate in a context-free manner when it comes to software. There are no, there are no answers that work for every situation. Sometimes the code that you're writing is just a prototype to throw away. And if that's the case, you would use it. If people were to speak up. If people were to speak up. If people were to speak up. If people were to speak up. If people were to speak up. If people were to speak up. If people were to speak up. like rapid application delivery toolkits and frameworks because they don't deliver code that is very maintainable. But if I'm building a prototype to throw away, those things are fantastic because you go zero to 60 quick. It's just that at about 85, you hit a wall and your car explodes. The metaphor went off the rails a little bit, but that's kind of what those, those are good for a certain context and not good for other contexts.

[00:31:59] Allan Stewart: Which just goes back to that whole concept where we say context is king because without it, you don't know what you're doing, right? Or you can't, you can't make good decisions, right? If you, if you don't have any ability to understand the world around you, then if you take an action, you're not going to know what the result of that action was or you won't be able to predict it anyway. And so as you're gaining context, it's, it gives you that ability to start to experiment, start to maneuver within the system and, and see if what you are doing is actually making the difference that you want it to make. If you ignore the context, you're kind of going in blind and just hoping that you get lucky with choosing something and, and it happened to work out.

[00:32:52] Dave Adsit: Well, and I think, I think about when you ignore the context, when you choose to ignore context, it kind of reminds me of that. It's an old quip. I don't know if who said it or how long it's been around, but the idea of this engineering is doing with $1 what any idiot can do with two, right? So if you say, hey, I need, I need cars to go from this side of this, this river to that side of the river. Well, you can have a very elegant engineered bridge solution or you can just keep throwing down material until you've either damned the river, or created a sufficiently robust, like trunk of, you know, wood or metal or whatever. You just keep throwing stuff down, covering it and covering it and covering it until eventually you've used enough material that now you can drive cars back and forth across the river. And that isn't a very effective or efficient way of traversing a river. On the other hand, given the right context, it might be the right answer. If you have to cross the river one time and you have to do it, in a hurry, maybe you knock down a tree or maybe you just swim across. I don't know. You just get going on the other side and get going about your life. But if you need to do something that where the context is, this has to be traversed many, many, many times by heavy vehicles. You know, you, you have to build it a different way.

[00:34:17] Allan Stewart: Yeah. If it's, if it's freezing outside and you're going to have to walk for several miles after you cross that river, then maybe swimming it isn't the best idea.

[00:34:26] Dave Adsit: Right.

[00:34:27] Allan Stewart: It just, it depends on context. Right. Right. There's so many different flavors. How many times are you going to cross the bridge? How hot or cold is it going to be? Are you in a vehicle? Are you out of a vehicle? Right. All of those things, which again, like you, like you mentioned before, in the physical world, it's really easy to come up with all of those things. In the software digital world, you have to really lean on experience to think about, think through them and figure out which ones are actually important for the situation at hand.

[00:34:59] Dave Adsit: When I was in high school, one of my friends used to always quote one of the movies that we watched back then, you know, and he had this, this favorite context-free bit of advice. The, the Mongol general says, Conan, what is best in life? And Conan responds to crush your enemies, to see them driven before you and to hear the lamentations of their women. And I, I've heard that so many times and that is the most generic context-free advice that has literally not once ever applied to my life.

[00:35:28] Allan Stewart: Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. We've said on, on the podcast before that the only thing that we could think of that came close to context-free advice is use source control. It's because it saved us so many times and it's relatively cheap to do it now. You know, you have something like Git, you can use source control even if you don't push it to GitHub or GitLab or GitPlace. And maybe the second one is kind of like onto it is Git. Find out the context of the thing that you're doing. That's the advice that we can give that is just generally applicable because it answers the question of it depends.

[00:36:12] Dave Adsit: Yeah. Odd that the only context free advice we'll give you is to seek context first.