Two's Complement - Iter-Mental Development

Episode Date: November 19, 2023

Ben and Matt compare iterative and incremental approaches to software development. To everyone's astonishment, they turn out to be different. Then they decide we need better names for these things, but it turns out naming things is hard.

I'm Matt Godbolt, and I'm Ben Rady, and this is Two's Compliment, a programming podcast. Hey listener, you're expecting me to say, hey Ben then, I'm sure. This episode is a bit unusual because we didn't get the audio settings right at all. So unfortunately, Ben's microphone was recording from his room mic. And so you can hear all the noise in the background. And I've done my best to edit out all of the worst of the noises, but there's still some there and it's very echoey. And on my side, my wife and kids came in halfway towards the end.

And again, I've edited it as best as I can but there's a lot of noise so hopefully you'll forgive us this one off uh terrible audio quality episode but uh if not then maybe just skip to the next one it's still an interesting conversation I think so I hope you enjoy it hey Ben hey. How are you doing today? I'm doing all right. I'm a bit croaky as you can hear. I'm at the tail end of one of the many colds which thankfully was not COVID but in a family where folks have just gone back to school there's this zoo of microorganisms that get reintroduced to you after a summer break and one of those was the the common cold and left me without a voice which is like the second worst thing ever if you could stop me from typing that would be you know the end of my life i think right

there it'll be you know can't talk can't type what's the point of it of it all anymore but um yeah so um we discussed this before before we started recording that you know we're going to try and pick a topic that would let you talk and here we are now one minute into this recording and i'm the only one who's talked so far other than so i'm not doing very well it's going perfectly exactly as we designed so what do you want to talk about? I thought we could talk a little bit about the differences between and the implications of iterative and incremental development. OK, now, see, those sound very similar to me. They both start with an I, which as we all know, all synonyms start with the same letter. So they are immediately the same word.

But they feel like they should be the same. Yes. So can you define them for me? imagine i didn't know what they were already it's easy to do because it's true uh yes and and and in fairness i think pretty much everybody that uses these terms and thinks about these concepts we'll mix them up from time to time they are very related but they are not the same thing and it is sometimes very helpful to be like, no, no, no, no, we're not going to do this incrementally. We're going to do this iteratively. And if you haven't had a discussion about what those words mean, then it sounds like, no, no, no, we're not going to do this.

We're going to do this. Right. Yeah. Okay. Well, what did you just say? There's a subtle distinction in those two words, but they are lost upon me. So tell me.

Right, right, right. So the best analogy that i've heard for this is like imagine you want to paint a painting and you want to paint you know uh you know you have some sort of vague vision for the painting that you want to paint but you want to paint a painting so the uh the incremental way to do it would be to paint exactly the painting that you want one small piece at a time. So if it's a portrait, maybe you'd paint the face and then you'd paint the hair and then you'd paint the body and then you'd paint the background. Right.

The iterative way to do that would be maybe to start with a drawing and then you do like a drawing with some color. Right. You throw out the drawing and you use the drawing with some color. Or maybe you do what a lot of famous artists do and you actually paint over top of your drawing right right but you do drawing and then you add some color and then you add more stuff on top of that and then you sort of refine the the lines and make it more clear or or you know maybe even if you're uh an impressionist maybe you intentionally make it more blurry or whatever it is you're trying to do to achieve the outcome of your painting right okay um and. And that is, that is the difference.

That was, I think a good example of the difference between an iterative approach where you're sort of doing the same thing over and over again and making it better every time versus an incremental approach where you're building big things by building lots of little small things. Got it. That makes perfect sense. And it maps now you've said it i know we discussed this literally for 10 seconds before we started recording that really strikes a chord with exactly what i'm trying to do in my day job right now which is like i am definitely going for an iterative approach over an incremental because i really really really want to see the sketch of the whole system in some very vague sense before I commit to saying this is the right way to do it.

And then go back over and like color in between the lines and maybe replace little parts of it. As opposed to saying, here's my six month plan. And week two of month two, we'll be doing this. This is the next incremental chunk of the work and i can't predict that right now but what i can do is do everything in six days and then try doing it and everything over six weeks and then maybe six months that kind of feel yeah and it's and it's tricky and i think it makes it even more confusing when people talk about this because quite often people work uh doing kind of both of these things

at the same time where they will do uh an iterative approach where they will you know sketch out sort of little you know the sort of steel thread or the skeleton right trace a bullet yeah you start like all the little pieces and then like we'll sometimes iterate on each of those pieces individually and then also we'll sometimes work through them incrementally right so you'll like build out your skeleton and then once you uh and then once you have the skeleton you'll be like okay now we're actually going to go through and incrementally improve each part of the skeleton until it uh is up to the to the standard that we want or maybe sufficient to deploy or sufficient for some particular use case. And then you come back and

you then refine those things iteratively again. And so the whole iterative and incremental phrase just kind of gets lumped together because people tend to do both of those things. But it is sometimes like very important to make a very clear distinction about like, you know, are we doing this incrementally or are we doing it iteratively? Right. So like in general, in my mind, if you're not really sure what the problem is in the first place, you want to do it iteratively. Right. Like you want to make sure that you actually understand like am

i trying to make a portrait of a woman or am i trying to draw you know a cartoon right like i don't i don't actually even know yet right like i'm not sure um whereas certainly if you're going to try to subdivide the work uh one way to do that is to think about the sort of incremental steps that you can take and can they even be subdivided? So there are certain situations in which they can't, like one increment depends on the next. Right. Yep. Right. So you can't actually subdivide the work, but sometimes there are ways where you can can you can break things down into steps and you can actually do some of those steps ahead of time this is maybe like a little bit like a branch predictor in a way where it's like you have to do all these things in order but we probably are

going to have to do that one so we're going to lead the target a little bit and we're going to start doing that first even though you know technically or because i have resources that i you know my team is for for strong and although we don't have a totally clear idea about what the project as a whole is going to look like i'm 80 sure we need something which looks a bit like x so we might as well start doing x now and maybe that's more like a hybrid approach then when you've broken into pieces that you can then i guess this is what you were saying earlier, you have like the iterative and incremental. You can sort of like iterate on each individual component

having like decided to do them. Yeah. Sorry, I've confused myself. Yeah. And you can do that serially or you can do it in parallel. You can iterate on each increment one at a time through all the increments. You can try to break up the work across multiple increments and hope that they all tie together.

And, you know, sometimes you can get that right. You can iterate on all of the increments, taking a pass over all of them one at a time, which is basically just iterative development. Right. You're just doing a whole pass over the whole thing in each each time um and you can and again and this is why people use this phrase iterative and incremental because you're almost certainly doing some some combination of them right and i suppose without even necessarily realizing i suppose there's sort of a a fractal uh recursive thing here where you might say i'm gonna hack together the worst possible version of this thing and i'm going to say over the weekend that

would you know but like in a way where you'll say like okay one person's going to go off and spend a couple of days spiking genuinely spiking out the whole thing and kind of going like yeah we're going to need a reliable messaging system and so i just use tcp for now but that won't scale because of x we need you know i need to be able to notify people but i'm just using print f right now um you know monitoring was non to notify people but i'm just using print f right now um you know monitoring was non-existent but i'm sort of printing out a heartbeat every two seconds and if it goes down maybe and but i got it working and now i know what the components are and so now i can break it into the four pieces and then we can do take two four at a time agree

roughly on what the the handover parts are and then we're parallelizing four ways and then and it could potentially continue to break down where you're like oh actually our our reliable transport mechanism needs actually it's a it's the size of a whole project it turns out we didn't think it was we were just going to buy in kafka or whatever but um that's not working for us for whatever reason we need to bring in some exotic magical hardware that does something whatever you know that's that's the kind of discovery part of it but that is an increment no that's an iteration see i can see why you get confused right i'm actually having a problem now even though it made sense when you described it right at the beginning i know i know it's almost unfortunate

that that's like the term that people kind of came up with for these sorts of things like you like removing the alliteration would have been nice. Yeah. I guess, you know, in terms of, as soon as you started describing this, I was thinking the different, you know, you used the painting analogy here, which is, which is a good one. And you know, one, one thing that some old school, you remember modem level image formats would, they would send it to you progressively. That's like they would send you

every fourth line of the image so that you could kind of fill in the gaps on the client side while you were waiting for your 14k4 modem to download the rest of the png right but you could see something and it was a blurry version of it and then it would refine as time went on and that was referred to as progressive like a progressive download of the the image and so that kind of feels to me a little bit like again um iterating on the image and continuing to progressively refine it over and over again similarly like you know fractal rendering systems typically do this thing where they would like do a big pass over the whole screen to generate your mandelbrot and then they would go back in and fill in where all the detail was because i mean that was different reasons but meant you got like a pretty picture straight away and then you know you left it longer and then you could print

it out and see some really high resolution thing and that's a similar deal so it would be nice to have used as you say not an alliterative or even similar sounding word yes yes exactly exactly um but yeah i mean i think all of these these things get uh even if you can't keep the words straight in your head, and as I said before, I mix them up all the time too. Keeping the concepts straight in your head is important. And it's important when you're kind of in the stage, which I think you are right now, where you're planning out a whole bunch of work. And trying to figure out like, okay, how are we going to do things like discover the unknown unknowns, the Rumsfeldian unknowns, right? Yes. The things that we don't know, we don't know, right? Because, you know, whenever you're building any sort of, you know, reasonably sized system, there are going to be those things, right?

There's going to probably be a lot of those things and especially in the early stages like your goals are in many cases to kind of use your development process as a catalyst for discovering them right like you want to find forcing functions where it's like well if we can make this thing talk to that thing, then we'll know that this part, there's no more unknown unknowns there, right? And so like, if you were doing things purely incrementally, right, you might not do it in that order, right? You may not work on that piece first because it like doesn't deliver any value by itself, right? But because you're trying to do it, you're trying to discover this thing, you wind up building this out and it becomes this sort of literal little iterative slice where you're sort of like, okay, we're going to talk to each other. What if we try this? What if we try that?

What if we try this? What if we try that? And then you finally get something that works. And now you've kind of like knocked out all of the unknown unknowns from that section of the problem. Right. Right. of the unknown unknowns from that section of the problem right right um so i mean you know like some of this stuff if you are the type of programmer who you know just wants to be handed a list of things to do and doesn't really want to think about how they all fit together uh and

doesn't it's really responsible for you know coming up with up with an architecture or a large-scale plan for projects, you might not think about very frequently, and you might not care. It's like incremental, iterative, I don't know. I just write code. Why are you making this so complicated? But if you're trying to organize the work of many people or if you're trying to build systems that are kind of inherently risky,

like no one knows that you can actually accomplish what it is that you're trying to do, then you can save a lot of time and money by thinking about like the order in which and the sort of progressive quality of which you are going to organize your work. Yeah, that makes an awful lot of sense to me. Yeah, and as you say,

it couldn't be more apropos for my current situation where I am exactly doing that right now. And people are asking me left, right, and center, you know, what do we do? What needs to be done? And my sort of ostriching of it is like, we're just going to build something first and then we can argue about whether or not

X or Y is possible or not. Let's do the minimum, you know, this is a minimum viable product style approach, which again, same feeling it's like can this be accomplished and in doing so what do we learn about what the things that we need to uh to to continue doing are or what things we need to um work on subsequently sorry this is gonna be a fun to edit one i've got a whole bunch of footsteps that are showing up on my audio i don't even know what to tell you at this point right we might we might there might be so listener if you hear anything weird going on in the background there that was uh this is my bad attempt at editing as much as we can the noisy world that we live in i feel like i should apologize to editing that oh

yeah yeah well that's right editing matt would be fine he's he's he's off in the future he's he's having a great time he's probably on the train actually i started editing these on the train and it's been a quite a good experience although it has put in sharp relief the uh so i wear my my um bluetooth headphones for for doing it on my laptop and i run audacity this is a complete non-secret from what we're talking about before but maybe it's interesting to people i don't know this whole this whole podcast is a nonsense it is isn't it um so i put my headphones in and you get exposed to the lag between your laptop and the headphones you forget there's so much buffering going on you don't notice it on your phone when you hit play and you put your phone away in your pocket and you know music starts playing and you know or your

alarm goes off and you pull out the phone you're like oh yeah whatever um but when you're like staring at a um a waveform of what you said and you're trying to line up things and kind of go, all right, when does the um start? Is it here or here? Although that's usually pretty obvious to see. It's really obvious that there's a gap between where the thing says it's playing and what you can hear. And you kind of like stop it and the music carries on the music. The sound carries on a bit longer. So that was an interesting discovery.

But it doesn't materially affect the editing system, editing setup. Yeah. One other point I could probably make about this is that I think one of the dangers of working in this way, which I think is how most modern software development happens, but as opposed to a non-incremental and non-iterative approach where you would basically be like, we're going to plan out all the software that we're going to write and then we're going to write it.

Right. And that certainly is very, if you want to optimize for breaking the work apart into lots of, you know, independent groups and doing it in parallel, assuming you get the first part right, that makes that incredibly easy, right? Like you just say, this is all the software we're going to write and team or person A is going to write this part and you write this part, you write this part. And then you integrate them all together at the end

and it works great, right? Never been a problem. But assuming, yes, exactly. So assuming that you're not building software in 1983 and you're not doing that, then one of the traps that you can fall into is thinking of, and I think this is more a problem with iterative development than it is incremental development. And I'm going to tax the brains of our listeners to recall what those things mean again very very briefly here but i think this is more of a problem with iterative development where you can fall into a trap of basically just writing terrible code right because you're just like oh this is just the first iteration and we're going

to come back we're going to clean this up and one of the things that i have learned working iteratively on many different projects many different, is that you will be very well served by operating under the assumption that this will be the last iteration you will ever get to do. Wow. Right. So whatever capabilities and whatever quality and whatever level of sophistication you decide that you want to achieve in this iteration, you should figure out what that is and you should stick to it. And you should not fool yourself into thinking that, oh, we'll fix this later, right? So if you build the capabilities into the software that are sufficient to meet some need, your expectation should be that it will

immediately be used to fulfill that need and that there's not going to be some other period of time where you can come back and you know document all the things or refactor the code or write the tests or fix all the corner cases that are going to show up every once in a while. That's just not how this stuff works, right? As soon as it's good enough, it will end up in production. As soon as it's, like, you're working iteratively, and you're making it better and better and better, and there's going to come a point where it's like, oh, this is good enough now, and that's the production system.

And you might get another chance to do more iterative improvements to it but you might not and so you have to treat it seriously you know although it's a you don't be thinking it's a prototype that's perhaps one thing you could do where you sort of put everything together and go well I just hack it together treat it as if it's like a cut down but so as you say something you'd be okay going to production yeah and i mean i think this it really informs like how you spend your time in those iterative steps like again it kind of gets back to like what are you doing with these iterative steps are you trying to like find those Roman Sveltean unknowns because if you are don't spend the time to like integrate it with the other thing that's not

particularly relevant that won't give you that run spell the unknown or like write the you know main function that'll actually like deploy it or anything like that or or things like that um because two reasons one is that's not what you're trying to figure out right now and two is if you make it too productiony it might actually accidentally go into production. So spend your time on the things that you're actually trying to prove out and make sure, I mean, there's sort of a gray area-ish way to say this

where you sort of like, don't make it too good, I guess is sort of almost how I would say it. Be careful, yeah. Be careful how good you make it. Be careful you don't make it too good too guess it's sort of almost how it would be careful yeah be careful how good you carefully you don't make it too good too quickly in the wrong dimensions accidentally right it's kind of how i would say that right like yeah be very intentional about what your iterations are and what it is that you're trying to figure out and don't spend your time on things and you might have people that are telling you it's like yeah can you can you deploy that to

our server and say no i'm not going to work on that yet we we know we can deploy it that's not what we're going to do now i generally the person who says deploy first and that's a process that i like to follow but you got to think about the environment that you're in and sort of like what you're actually trying to achieve with these with these no exactly right you you kind of have to go into this or at least my philosophy at this point is you have to go into this with this idea that when you finish with one of those iterative steps, that might be the last. And you have to be able to walk away from that code and be like, yep, this is going into production like this, or this is never going to be touched again for six months because we've discovered that there are unknowns here that we can't deal with, and we're just not going to do this project

at all. And so I'm just not gonna do this project at all and so i'm just gonna put this on the shelf and i'm never gonna worry about it again until you know three years later and they're like oh we did that project let's go back to that yeah yeah yeah but i guess you have to be prepared for that right you have to go into that sort of mentally and emotionally ready to say like hey we might discover when we're doing this process that there's actually the kraken sleepers under the under the waves here and oh now we we don't know how to solve this and now we can't do the project as a whole and i feel like that's less of a problem when you're doing things incrementally

right like if you have some system that you're trying to build and you know let's just say four components and you build components one two and three and you haven't built four yet it doesn't work yet right like maybe you've done an incremental and iterative approach and you've got like three very well built sys components and you've got one sort of study prototypy component that maybe if like we don't lean on it too hard it could maybe go into production but generally if you're doing things in a purely uh incremental way you don't have that problem because until you have all of the increments you don't have a running piece of software right right and so like in in in the situated the system that i'm looking at right now the sort of axis that i'm not worrying about is performance

so i'm just like that is a place i can come back and refine later on. But I do need it to be functionally, not necessarily correct, but functionally in the right ballpark and show that the capabilities could be added to. And then once we've got to some point in the system, it's like, well, now it's just expanding out in a different direction. It's like expanding horizontally in terms of the features. Well, you can do add ads and subtracts now. It's like, yeah, but ads and subtracts feel like the same same kind of thing there's no surprises in subtracting as well as adding and multiplying and dividing or whatever you're doing right but showing that you can have something which can do computations of that flavor is good enough to be able to say i can get this to production everything's fine um and now um we can uh refine that by running another uh an iteration over the top of it yep uh one more i think one

last point on this one place where uh incremental development can be especially powerful is when you have an existing system and you're trying to add new capabilities to it, right? So you've got the system, it works, it's in production, whatever you're trying to do. And you're trying to figure out like, okay, we've got 35 different things we could add to this. What should we do next? Well, what you probably don't want to do is an iterative pass across all 35 things, right? What you probably want to do is pick one thing and build that one thing incrementally and add that to the system and get that into production and go back and be like all right we've done one of 35 what's next well actually we came up with another 20 so now there are 64 things

right which are the 64 things should we do now oh we'll do this one okay cool right so so that uh that can be another sort of uh valuable way to think about um organizing that type of work is you could say like in the early days we're maybe going to do more iterative development and then once we've got a working functional system we're going to switch to a more incremental approach and you know that again that's not to say that you don't mix and match, that you don't do iterations on your increments. Right. Of course, when you're when you're sort of looking at the total scope of work, like it can sometimes be useful to sort of think about those things in two different

modes. No, it makes makes a lot of sense. Well, today I learned the difference between those two words that I'm not even going to say out loud because I'm going to get them the wrong way around again. Incremental and iterative or refining and building piecemeal. I don't know if we can come up with better terms than this. Yeah. Okay. Yeah.

So let's think about this. What should we actually call these things? I like progressive. So iterative and progressive to me. I like that substitution. So you can just say progressive and incremental. Yeah. Yeah.

Right? I think that's, I like that better. Progressive and incremental. Progressive has other overtones though. That's the thing. You think of insurance. Yeah. Either that or, yeah.

Or else someone with maybe on the political spectrum. Or politically. Yeah. Which is sometimes going insurance. Yeah, either that or else someone with maybe on the political spectrum. Or politically. Yeah, which is sometimes going to, yeah, so. Progressive enhancement, that's too long, though. Yeah. I mean, anything would be better than iterative and incremental. They're just like, they're basically like the same word. The left and center distance between those two words is not high enough.

Exactly, they're the same. They are very, they're different, but yeah. Well, anyway, I don't think we need to solve the naming problem right now, because, you know, as we know, that's one of the two hardest problems in computer science. You forgot the third one off, I want to hear it. Oh. Yeah, no, that's, I don't think I agree. I think that's probably a good place

to stop this today and we'll catch up next time sounds good you've been listening to Two's Compliment a programming podcast by Ben Rady and Matt Godbold find the show transcript and notes at www.twoscompliment.org

contact us on Mastodon we are at tw.twoscomplement.org. Contact us on Mastodon. We are at twoscomplement at hackyderm.io. Our theme music is by Inverse Phase. Find out more at inversephase.com.