Agile vs Waterfall

About this Episode

On this episode of the Acima Development podcast, Mike hosts a conversation about software development life cycle methodologies, opening with the line usually attributed to Mike Tyson: everybody has a plan until they get punched in the mouth. He illustrates it with a day from about 20 years ago in the suburbs of Chicago, when he and his wife planned to collect a free piano from an elementary school and a bunk bed with a slide from a seller farther south. The U-Haul turned out to be an hour away through traffic, the truck had no ramp, the movers he had hired gave up waiting, and the piano sat at the top of two flights of stone stairs. His wife's idea rescued it. They offered the movers' money to a construction crew working down the street, and the crew carried the piano out. Mike got home around 11 that night. From there he lays out the history, from the linear process Herbert D. Bennington documented in 1956 and nobody called Waterfall until the mid-1970s, to the 2001 Agile Manifesto, which he points out is four stated preferences rather than a process.

The group resists the idea that Waterfall is simply obsolete. Justin notes that it got NASA to the moon on a budget worth several percent of GDP, and Kyle adds that it made sense when software shipped on CDs you burned and mailed, because there was no pivoting after the discs left the building. Dave recounts building the REALImage 3000 graphics card at Evans & Sutherland, where the chip spent six months in the fab and came back with two leads soldered backwards. Red and green were swapped, and the team had to write a very fast post filter to correct every pixel of every frame. He connects that to lean's idea of inventory, where the assumptions you have not verified bite harder the longer you carry them. Vivian questions whether Apollo was really Waterfall at all and argues the only genuine difference between the methodologies is the size of the planning scope. Will keeps pulling the conversation toward the business side, since engineering tends to love Agile while the people committing to quarterly numbers tend to hate it. Eddy floats a hybrid, Kyle calls it Wagilefall, and Mike credits Will with naming the version that fuses the worst of both: Whirlpool, because you circle the drain.

The last stretch is about trust. Mike argues that iterative work only happens when leadership is genuinely willing to say go build something, which he compares to commissioning a Renaissance artist to paint a ceiling. Vivian asks whether psychological safety runs both directions, since managers also need confidence in their engineers, and wonders how an engineer earns that upward. Matt answers with communication and honesty about what might not work, and takes the position that a bad hire is the hiring manager's failure rather than the hire's. Thomas describes trust as a currency that compounds as you show progress. Mike closes with his friend's dairy farm, where the manure is unavoidable but gets washed into a reservoir, fermented, and spread on the fields. Software works the same way. You will not avoid the mess, but you can build a process that deals with it as you go rather than leaving one enormous pile to land in at the end.

Transcript:

MIKE: Hello and welcome to the Acima Development Podcast. I am Mike, and I am hosting again today. A little side note: Acima has a parent company, Upbound, and we're fusing more. Like, we're more of a family or a team or something. Like [laughs], somehow we're getting closer together. So, we may be putting Upbound in the title in the near future, so don't be taken by surprise if you're listening regularly. That's it.

And with that, as usual, let's...Oh, I should introduce people who are here. We've got Dave; we've got Thomas; we've got Ramses; we've got Justin, Kyle, Eddy, and Vivian. I think we've all been here before, so we'll jump right in.

I'm going to first reference a quote by Mike Tyson. Actually, it probably isn't by Mike Tyson, but it's attributed to him. I looked this up, and I guess there's no, like, clear connection, but he may have said it. And the quote says, "Everybody has a plan till they get punched in the mouth [laughs]." Whether or not he said it, he probably had the same idea. He probably had the idea at some point. And, you know, there's this idea plans don't last very long once you get into, you know, sparring.

I was thinking of plans that I've had in the past that have failed. I had, like, a simple one. My family and I were going on vacation. As we went in the garage, literally in the garage, we were grabbing something out of the fridge before we left and noticed that the fridge wasn't running. Like, "Oh, that's not going to go very well for everything sitting in the fridge," and, you know, I had to redo the plan.

But I got a better one that was further back. About 20 years ago-ish—it was a little less than that, but approximately 20 years ago—I determined there was a few things that I needed. My wife and I decided, oh, we need to get a couple...two things. There's two primary things we needed to get in the suburbs of Chicago. One, we found out that there was an elementary school that was giving away all of their pianos. They didn't think they needed pianos anymore. We thought, "Oh, great, we'll get a free piano and bring it home, and then we'll have a piano," because we didn't have one. So, we thought, "Oh, that'd be great. We'll get the free piano. We'll just have to pay to get U-Haul to bring it home."

We also found that there was somebody farther south in the suburbs that was selling a cool bunk bed that had a slide, and it came down at the top bunk so you could take a slide, you know, it was cool. And we thought, "Okay, this is what our son needs." Came up with plans. So, I took work off that day, and I called U-Haul and asked them to find a location near where the piano was where I could pick up the truck, so I wasn't driving the truck through, you know, Chicago traffic. I'd pick up the truck, drive over to the school.

I called some movers, and I was going to pay them to meet me at the elementary school, load up the piano, put it in the truck. And then we were going to drive down and pick up the dismantled bed from the house of the woman who was selling it; drive home, roll the piano down the ramp because, you know, you're going down. We could do that when we got home and pull everything off. Made all the plans.

I got up, drove to the U-Haul facility, and found out that the U-Haul people had no idea what they were doing. And it was at least an hour away through dense traffic and neighborhoods over [chuckles] to the elementary school. You know, this was 20 years ago. This was before...You know, technology has advanced a lot. In those [laughs] years, they didn't have anything, and thus began the series of [chuckles] things that went wrong. We, like, "Well, this is the U-Haul we get."

Turns out the lift haul that they had gotten for us also didn't have a ramp in the back. It just had a low bed. So, anything that went in and out had to be lifted in and out. Remember, this is just my wife and I and my, like, three-year-old son [laughs], and a very heavy piano. Like, "Well, this is what we get, I guess."

And it took a lot longer to get there because of the traffic than I expected. I call ahead to the movers and asked if they could wait a little bit, but in the traffic, it was going to be, like, two hours. We weren't going to get there until hours after the movers were supposed to meet us. And, in fact, it took us so long to get to the elementary school that by the time we got there, they were just about to close. So, there was, like, one lady who was there who showed us where the piano was. There was one left. The others had all been taken. Like, okay.

And this is this...It was an old school in this fancy, old building with, like, two flights of stone stairs being the only way out, and a really heavy piano, and my wife and I [laughs], and a truck with no ramp in the back. Like, oh, okay. It turns out we actually...There actually was an answer here. And my wife says, "You know, when we were driving down the street, I saw construction sky...There was a crew of people working there, crew of guys there building. How about...You had the money that you're going to pay the movers," you know, because they'd left hours ago. There's no way they were going to wait for us. "How about you offer them the money to come in and haul the piano down the stairs and into the truck?" Like, that's a good idea.

Drove over there, and they were willing. They're like, "Yeah, sure," because we had, like, 100 bucks or something. Like, "Yeah, I'll do it. Sure. Free money." Well, not quite free, but close enough, because it was a big crew of burly guys. So, they picked up the piano, took it down the two flights of stone stairs into the truck. Okay, yay, we're that far.

Next, we had to go pick up the bed, and the lady there had an appointment that night, and we had to...In order to get there ahead of that, we had to get there in, like, 30 minutes, and, by this point, it was rush hour. About two hours later [laughs], we arrived at her house. Luckily, she was really nice, and she had gone to her appointment or skipped her appointment just so she could get us the bed. I was so thankful [laughs]. There was no way. We were just driving through, you know, stop-and-go traffic for hours waiting to get to that place. And so, I was incredibly grateful.

Finally, so now we've got the piano; we got the bed, and started driving toward home. And there was no way to get the piano out of the truck when we arrived there. And I had to have the truck dropped off that night, or I'd pay for an extra day. So, I called somebody. I called a friend. He ended up calling somebody else who had, like, three or four teenage boys [laughs] who were available. They ended up meeting us when we got home, and they came in, loaded up the piano, got it off the truck, and even into the house, which was fantastic.

I drove the truck to the drop-off point and, like, you know, my wife following in the car. Got back and it was, like, 11 o'clock at night, completely exhausted, completely emotionally run through the wringer because there were so many steps in this [laughs] day that had gone horribly wrong and had managed to get out of. And I was just incredibly thankful and relieved [laughs] that I got the pieces together. Like, it was amazing. Like, I probably couldn't have pulled it off twice because so many things had to line up to make [laughs] any of that to work, because it was such an epic failure.

You've probably had plans like this. Everybody's had a bad day where the plans didn't work out, which leads us to our topic for today. We're going to talk about Software Development Life Cycle Methodologies, which is a fancy way of saying, you know, how do you plan for your work?

There is a style of planning projects that's been around since the 1950s called Waterfall. Did some background reading on this. It wasn't referred to as Waterfall until the mid-'70s, but the idea was documented as early as 1956 by Herbert D. Bennington at the Symposium on Advanced Programming Methods.

And what he presented was a series of stages. You do, like, your pre-planning, and once that's done, you move into your planning. There's a lot of different variations on what these steps are, but they...You can look...One possible, well, path through these steps is preliminary analysis, systems analysis, requirements design, systems design, and development.

So, you know, you start your development, like, stage four, then integration and testing, acceptance, installation, deployment, maintenance, evaluation, and disposal. It's a linear path. You start with your plans; you execute your plans; you test it; deploy it; you do your maintenance. It's all good, right? It's not right, but I'll say that [laughs].

This methodology took off in the ensuing decades because there was nothing better. And it's sort of better to have a plan than not to have one. So, people say, "Well, yeah, I mean, at some point, you got to plan, sometime you got to build it, and then sometimes you've got to, you know, move on from there." There's a lot of gaps in this process.

There was a famous event that happened in 2001. A group of 17 software practitioners got together and wrote a document called the Manifesto for Agile Software Development, and it was actually pretty revolutionary. You get some people together and write about the real-world problems they've had, and it has an impact.

It isn't even a process; it's just a list of preferences. If you go and read that Agile manifesto, it's like, "You know, we prefer to do things this way to that way." But following that event, there have been lots of practices that have been built up around, like, getting away from this idea of a linear flow, because it doesn't matter how good your plans are; you're going to get hit in the face, and then everything's going to have to change.

And those well-laid plans, it doesn't matter how well-laid they are; they're going to be wrong. And so, the world has largely moved on from this, that linear approach and come into iterative processes, iterative planning processes that we collectively call agile, agile software development. And there's a bunch of them with different names, things like Kanban, Scrum, extreme programming, popular methodologies. They all share in common this idea of getting feedback early and doing planning in a loop rather than a line.

So, lots of background and a long story. That's the background today, is to talk about what you get from these different planning methodologies, you know, the good and the bad. It's not like using agile practices solves all your problems, but it does address some of the chief problems that people have had in Waterfall. Again, bringing with it its own problems.

I'm not going to talk about all the problems because I've been talking for a long time. I'm going to do as I usually do and shut up for a little bit and [chuckles] let other people jump in and give some thoughts, and then I, you know, nudge the conversation forward. So, thoughts?

EDDY: I think on paper, waterfall, I think, sounded good when it was first proposed, right? Like, get this done. Once this is done, get this done. Once this is done, get this done. Once that's done, get this done. It gives you a structure, right? You're like, "Okay, I know exactly what step I'm on. I know exactly how to advance. I know what's next," right? And, you know, you can easily speak to that.

But I think as software development has grown, right, throughout the years, throughout the decades, throughout centuries even...Well, maybe not centuries, but you quickly realize, right, that you can't go structured like that, right? Things are moving at a fast pace, right? And in order for you to be as flexible as possible, you're not just going to wait for the first step to be done, you know, when you can be working on other things and be proactive.

So, I think, like, a major pitfall of waterfall is that you are stuck, and you can't move on until the previous or the current step that you're on is completed. I would expect someone working in waterfall to hand in a product much later than someone who was working agile, for example.

JUSTIN: So, I have a counterpoint to that. Waterfall methodology was what got NASA to the moon in the '60s, and got the U.S. to the moon. And I think it's, like, one of the greatest successes ever shown of the waterfall methodology. So, it's not necessarily a bad thing. It's just very, very difficult. And if you realize how much money was spent by NASA, by the U.S. government, to get us to the moon, it just kind of blows my mind. You know, I think it's something, like, what, 5 or 6% of the GDP or something like that during those years.

And, obviously, as a software engineering company, or most companies aren't getting that kind of budget. And so, you've got to figure out some other way to do that. And also, it seems like these days...I don't know, it's an interesting comparison because, in the '60s, the technology was moving rapidly as well. And so, it's moving rapidly now. It was moving rapidly in the '60s. And so, it's just like, I don't know, it's kind of the same thing. So, I'm not going to shoot down Waterfall because it got us to the moon --

EDDY: But I also wouldn't support it just because one success story is going to define the whole industry either.

JUSTIN: Yeah, that's true.

EDDY: Just because it worked for NASA doesn't necessarily mean it's applicable to us [laughs], you know what I mean?

DAVE: I resist that characterization. NASA isn't a single fluke.

MIKE: Nor has NASA never failed.

DAVE: Yeah, that's true, too. That's true, too.

KYLE: So, Waterfall and Agile, I think there's a reason that Agile's a newer concept, right, because, like Justin's saying, we have adopted. And why has it been around? Well, it was around because you needed the definitive planning. You were delivering on physical media. I think that's a large part of what has made Agile appealing to us today, is yeah, I can release, you know, an executable any time of day.

Well, you know, in the '90s that wasn't the case. You're burning the CDs, and you're shipping out to your customers. You don't develop that way. You, you know, hit your plan, and you iterate on those kind of cycles because you can't waste the money just burning, and that's going to be across the industry. That's part of where, like, your hardware companies, not all of them, but you've got some hardware companies and stuff like that that are still going to be using Waterfall because they have to have that deliverable at a certain date to ship out. They can't just pivot, like, you can with Agile.

MIKE: That's a really good point. If you get one shot on your deliverable, whether it's your moonshot or your box of disks that you're mailing to somebody when they buy the software, that very much changes how you have to do things.

EDDY: So, you're basically saying waterfall is probably a really good methodology when you don't have a retry mechanism, right, like, when it's all or be done, right? Like, if you screw up, you're done, right? Like, there's no retry [laughs]. So, like, maybe in that scenario, I think it makes sense, right? Like, if you're shooting someone up, you know, to the moon, you can't be like, "Ah, no, that failed. We'll try again later," like, no [laughs]. Like, you're dealing with people's lives, right? So, maybe in that scenario where stakes are different, you know, maybe it does make sense, you know, have a waterfall.

DAVE: Absolutely. Absolutely. Agile has the idea of tracer bullets, where you get something out there, you build...You know, it's like, you want to build a vehicle. Instead of building the entire train, you build a skateboard, and you verify that the transit works at all. And that's your thin vertical slice that you end up getting something that can get you from here to there, but it's just a skateboard; it's not the full thing. And then you scale that up, and that's tracer bullets. And yeah, if every bullet is a billion dollars and 6 astronauts' lives, you're not firing, you know, 73 of these things and just hoping to get closer to the moon each time or closer to Mars each time, right? It's like, you want to nail it.

The comment I was going to make earlier is that, in software, waterfall works if you have built it three times, is kind of where the tipping point seems to be. I can't cite that reference; it might be urban legend. But I heard it at Evans & Sutherland, where we were working on the REALImage 3000 graphics card, and it was our fourth graphics card that we were building. And they're like, "We're just going to mostly do it waterfall." And we had a chip in the fab that was taking six months to build. So, getting everything done and designed all the way up front, including the device drivers that would run on the hardware when it shipped, had to be designed, and then we sent the chip off to the fab.

And then we went and we wrote the software, and we found bugs in it, and yeah, it...The SDLC, the bugaboo of the SDLC is when that chip is finished and in people's hands, and you find out that two of the solder leads, or two of the leads, have been soldered backwards, that's a very expensive fix, right? And that literally happened with our chip. We had one line that the red and green lines were reversed, and it made some of the most beautiful bugs you've ever seen. It was just, like, this psychedelic coloring on this one channel. And we had to stay up late figuring out a very, very fast way to swap two portions of a single pixel on every pixel on the screen at scale, at speed, right? It's like we were running a post filter on every single frame on it.

The thing that I take from this, and this goes back to tracer bullets, is that lean software methodology talks about not carrying inventory. Your inventory is the number of tickets that you currently have open, and it's also the number of assumptions that you have not verified. The longer you carry those, the harder they bite if you get them wrong.

And the thing I love about Agile is that you build that skateboard, and you get down there and you find out that, no, we can't cross this chasm at all right here. Let's not spend six months to build half of a suspension bridge only to find out we cannot cross here. Or let's build it and see if any customers are even driving past this point. Then, oh, yes they are, and they want it. Let's build fast. Let's go in a fast way.

Yeah, low inventory, and yeah, don't fire astronauts at the sun just to...That's a terrible idea.

WILL: So just came in, right? But...

DAVE: Welcome, Will.

WILL: Yeah. Well, it's always good to...So, my question has always been with Agile, right? I get Agile. And I understand from an engineering organization and management perspective, like, why it's good, right, like, why it's good. Because essentially, like, it's all about, like, not bullshitting yourself about your planning horizon and what you know, right? But in the end, when we are all sitting here working in the businesses that make money, and take investment, and have stakeholders, and shareholders, and planning and managers whose planning horizon is even worse, I would argue, because I can deliver a website, you know, quarterly numbers, it's a little bit more voodoo-y.

But they're consistently accountable for these sort of forward projections and forward things. And so, they require these sort of, like, impact-driven planning things to justify keeping us employed on this project, right? Like, they have to go to your boss, and your boss's boss, and your boss's boss's boss. And they have to say, "All right, over the next six months, I'm going to do these things. And you're going to get these wonderful results as a result of all the wonderful engineering that we're going to do," right? And which is the essential friction between, like, Agile and Waterfall, right? Because, like, the way that everybody gets paid is by projecting and promising, you know, significant, meaningful results.

There's a duality between sort of Agile, where it's like, I'm going to build an MVP, and then I'm going to build it a little bit bigger, a little bit bigger, a little bit bigger, a little bit bigger, and incrementally. And, you know, we're going to add all these two-week Lego pieces up and, you know, and we'll have this beautiful project which is going to make us lots and lots and lots of money, right?

EDDY: So, I personally like Agile. That's where I learned to work initially, and I've seen the success stories of Agile, right? Like, I like the idea of simultaneous incremental work, you know, from different teams, right? Amazing. You can be super productive as long as you're very communicative, right, and you're very transparent, right? It can be very successful. And I'd argue that you can hand things in thrice the speed that a Waterfall project wouldn't, right? So, speaking from a success story personally working at Upbound, I have seen it. It works marvelously, right?

KYLE: It depends on management, but yes.

MIKE: There you go. It depends on management, as Kyle said. And back to what Will said, what if you don't have a plan? What if there is nobody saying, "Oh, this is what we want to have in the next six months, the next year, the next two years? This is what actually matters to our customers." What if somebody's like, "Eh, I don't care. Just work on whatever you feel like next," and they haven't thought any strategy? You can get yourself in a lot of trouble. You can build lots of wonderful, little features that don't accomplish anything, and there's a real risk there.

There is no magic bullet, and so Agile is not one. Yes, it can solve problems, but sometimes it's perceived as a substitute for planning. Like, "Oh, you know, we're not going to have a plan." "We'll just be agile as we go." No, that's not being agile. That's making it up as you go, and that's likely to go just as bad [laughs] with Agile methodologies than it ever would with Waterfall.

WILL: It's not so much that as, like, sort of, like, trying to reconcile the necessary business planning and projecting that drives sort of, like, quarterly budgeting, quarterly conversations, shareholder reports, if you, you know, are fortunate enough to work for, like, a publicly traded company. Like, everything goes downhill from, like, all right...Like, it's incumbent on us to, like, come up with these quarterly, if not, like, yearly projections and plans so that everybody can be like, "All right, give us lots of money [laughter]."

JUSTIN: We got to get paid at the end of the day [laughs].

WILL: Yeah. I mean, we don't...You don't have to get paid every day. You can go full [inaudible 22:47], right, and just, you know, sit in your tower with your wizard beard, but [inaudible 22:54]

JUSTIN: Yeah. So, a couple comments on this. One is you do have to have a plan, and you've got to decide how deep you want to go in that plan. And that's all...That's kind of, like, the difference between...well, one of the major differences between Waterfall and Agile it's like, you know, the distance you're planning out and everything, and the direction you're going. But if you are like, "Hey, I want to do this," and then, "How do I get there? I do this, and this, and this, and this. How do I get there? I do this and this and this and this and this," and all of a sudden, you find yourself in a Waterfall situation. And it all depends on how enthusiastic your planning is and how, you know, how deep you plan.

And I think you can slide into a Waterfall type of situation because you promised these deadlines, you know, these items at these deadlines. And you're like, "I promise these things at these deadlines, and you will give me money because I promised these things. And if I don't make these dates, it could be a death march." And so that, I think, is kind of, like, the bad side of Waterfall.

One of the things that was interesting—I think that, you know, I brought back my NASA example, but also all my good examples of Agile—they all had, on both sides of that, they had a very clearly defined set of goals and testing, and things like that they were able to understand what success was. And, success, if you can define that beforehand, I think that is a key to good planning no matter what methodology you go with. And that could involve testing; it could involve, you know, specific things that work, but you got to have an idea of where you're going. And I think that's really, really key to both methodologies.

MIKE: I'm thinking about what you touched on a little bit, Justin, what Will was saying, that there's a lot downstream of that quarterly or annual planning and goals. Because once you start talking about dates like that, then saying, "Oh yeah, I'm going to give you an MVP with incremental value. "Like, well, how much is that worth?" "Well, probably not worth much of anything, but it's the right, you know, it's the first step." They don't translate well.

And this works if you...you have to have some level of buy-in, some sort of, like, suspension of disbelief or of reporting where management says, "Okay, I believe you know what you're talking about. Go and prove this out." And I don't know if I'm going to get what I'm asking for. Now, there's some honesty there because you never do, but, you know, you can have some hopes. In some situations, maybe you do. Like, you know if I do some more marketing, history says I'm going to get more customers. You know, so, there are some places where you know you can pull this lever and get something out.

Building stuff is harder, and you have to tell people, "I'm going to go be this artist. I'm going to go work on my statue, and yeah, you're not going to get anything for a while." And they're like, "Okay." There's a real level of trust that's required for that, and if you have a trust deficit, you're not going to be able to pull it off.

WILL: I mean, that's the thing. I mean, isn't it...I mean, I hate to put it in these terms, but isn't it with Agile you're sort of, like, telling everybody the lies up front versus, you know, in Waterfall [laughter] you never...I mean, like, the level of certainty with Waterfall isn't higher. It's not higher. It's not like, "Oh, well, we're going to get these features." It's not like you've never pushed a deadline or dropped a feature when you're Waterfall planning. It's like, it's the table stakes for software development.

But, like, when you get into a Waterfall situation, you're handing them the bitter truth, like, without wrapping it in the piece of cheese, you know? At the end of a Waterfall, it's just like, "Ah, well, everybody tried their best, and we just didn't make it," understandable and forgivable and, you know, probably shouldn't be surprising if whoever is managing this project has been doing it for more than a month [laughter] you know? More than a month or two.

But with Agile, you're sort of, like, you kind of you're pulling the curtain back and just being like, "Okay, we're going to do something small that works, and we're going to expand upon it, and we're going to take it as far as we can go that makes sense." That's all anybody could ever, will ever do, you know, in terms of, like, your product development. But you're just pulling the Band-Aid off quickly.

MIKE: Right. Which can save you a great deal of money if you find out, yeah, you can't [crosstalk 27:29] [laughter]. But, like, waiting until the end, that's incredibly expensive, right? If you wait to the end to get your failures. If you can put them up...But, like, I agree with you, Will. I totally agree with you. Waterfall's not less risky. It makes everybody feel like, "Oh, I've got a process. I've got a plan. I've got a goal. Everything's going to be okay." It's not [laughs].

WILL: And it gives upper management deniability, you know, not for nothing. It's a lot easier conversation for your VP to have with the CEO to be like, "Ah, you know, we have everybody, like, everybody's working overtime, nights and weekends, and we got to push the deadline out six weeks," you know? That's an easy conversation to have versus, like, "Hey, okay, so, listen, I'm going to let you...I want you to...Let me...We're going to borrow your engineering organization for a quarter, and we're going to make some stuff, and it's going to be cool [laughter]. But I don't know exactly what. We're just going to try some stuff out, you know? But, like, trust me, shareholder meeting is going to be sick [laughter]," you know?

MIKE: Absolutely.

VIVIAN: Okay, this is a bit of a break, but I'm...I have two questions/comments that I wanted to make. One, I wanted to question whether or not NASA actually used Waterfall to get us to the moon. I don't think they did.

WILL: Oh yeah. Oh hell yeah. You can't incrementally go to the moon, you know [laughter]? It's a monumental engineering project. A rocket launch is, like, the essence of Waterfall. Absolutely. Like, did they all do it in one go? No.

MIKE: Except they first built rockets. First, you know, like, in World War II, they built a lot of rockets for military, and they used some of those rocket experts to start trying orbit, right? And then they put animals in orbit, and they put people in orbit, and people died.

This wasn't some unbroken series of successes. And, you know, eventually, after going through all of these steps, they got to the point where they sent people to the moon. So, I think they're both true. It's about as Waterfall as they get, being that, yeah, you get one chance to send that rocket up; and that had vast amounts of planning and an unfathomable expense that went into building that rocket. But it's also true that, where they could, they did something more akin to what we'd call Agile today.

VIVIAN: That goes into my next kind of question/comment is, from everything that I have ever learned about Agile and Waterfall and all of the different sub-processes, the only fundamental difference between Agile and Waterfall that I can find is the size of the planning scope. Agile is just Waterfall smaller and faster. And you re-iterate. And there are details about it, about basically back-propagating the information so that once you've done the implementation process and you realize all the ways that your planning fails, you can revise the plan, and update the plan, and move on to establishing, like, what are the next actual steps to fixing everything? But it's just about the size.

And that's why I made the comment about the NASA moon landing being Agile, because they didn't build an engine in one go. They had experience building engines; they built a new engine, and then when that one failed and blew up, they built another engine, and they iterated and iterated and iterated. And yes, they iterated each of these individual pieces in more of what I would call an Agile process. But then the integration test of putting it all together, that needed more of a Waterfall approach. But, again, that's just the scale of what they could do. You can't iterate on launching a rocket when there's human lives on the line very much. You can do it, but it costs a lot. And I'm not talking financially, but it does cost a lot financially as well.

And so, I'm kind of curious if there's any specific kind of clear delineated difference between a Waterfall process and an Agile process other than the size of the scope of the planned work.

MIKE: I just dropped...If you read the Agile Manifesto, you know, I said that there's some values. It's four lines. Individuals and interactions over processes and tools. Working software over comprehensive documentation. Customer collaboration over contract negotiation. And responding to change over following a plan. So, yes, what is it? Well, it's those four things. That's what the Agile idea is.

So, you could say, well, it's just the scope, and, to some degree, that's true. That's more of the responding to change, right? The short feedback loop. But there's a...there are some, I think, key pieces there in that instead of focusing on the documentation as your source of truth, you focus on the prototype, you know, here's the thing that we're building. This is the source of truth. So, it's more important to build something than to document something. And you communicate to your customer regularly rather than all up front.

So, I think there's a lot of truth to what you're saying. I think there is a little bit of nuance beyond that, in that there's also a de-emphasis on documentation and an increased emphasis on continuous communication rather than communication upfront.

EDDY: So, which one would you say is more expensive financially upfront, and how does that contrast?

JUSTIN: So, it all depends on, like, if you are trying to get return for the money you invest, theoretically, I'd like to bring on the second point there, the working software over comprehensive documentation. The working software that is providing value, that is ideally what will give you your money back and, you know, continue the money roll. But other than that, I think they're both ways that you could just spend gobs of money and, you know, not get anything back.

WILL: I mean, for me, I feel like on an objective level, Agile is a pretty definitively superior solution. I've seen it work. I've seen it, like, the big Agile versus Waterfall, like, on an industrial scale that I've seen personally is...I used to work on a lot of smartphone stuff. And I remember, in the initial days when the iPhone came out, when the iPhone came out, it blew everything completely out of the water. And the number one competitor was Android, and Android caught up at an absolutely breakneck pace, and arguably today is an equivalent experience.

The apps still suck, but Android's just as good as iOS and leads it in many capacities. There's a lot of stuff that you'll get on Android first. And I think the new iPhones, when they launch, are going to highlight that, especially this year. And so, it's just this sort of classic, you know, move fast and break things kind of methodology. And the reason I ask questions, like, sort of like, "Okay, well, how do you reconcile this with, like, business planning and the business cycle and the nature of getting buy-in from people who are investing in you over a long period of time?" is because, like, how do we sell it? How do we sell it? How do we make it work?

Because I'll tell you honestly, like, nearly every place I've ever worked, engineering has always loved Agile, and the business has always hated Agile. And if I want to be able to work in the way that I want to work and the way that I think is best, I need to make sure that the people who are writing my check buy in. And for them to buy in, I have to be aware, and empathetic, and cognitive and supportive of their needs, you know what I mean? To me, that's the productive conversation to have. How can I sell it? How can I not leave my boss or my boss's boss with their butt in the wind? Just saying, "Trust me, bro, it's going to work out for you," you know?

THOMAS: I think, like, the Android market, too, is very pliable. Like, they're willing to push innovation and see how they can change the phone and everything, where you see, like, iOS, a lot of the new iterations of an iPhone, right, are very similar. They're not much different. But then, like, you look at Samsung, you know, they have all the fold options. They have all these different camera options, all these different, you know, screen options and everything. And I think that's really remarkable that they push that boundary.

Even though they think, you know, something is crazy as a folding screen, they're willing to push that boundary into the market just to see how well it works. And it's done well because they're making new iterations of those foldables. And now they're starting to make foldable screens. Like, Samsung has a foldable monitor...not a foldable monitor, but a monitor that you can curve and bend. And it's just cool because the science they apply to one market they're applying to other markets based off the information they got just from success they got on their one product. So, it's really unique.

WILL: But I just...I remember both of the...Like, I mean, I remember when the iPhone kind of sucked, honestly. It didn't suck. It was really cool. The iPhone was super, super cool, but I remember, like, the initial, like, what was it? Nexus, right? The Google Nexus One, that first Android phone. That was dog water, man. That was so bad. It was so bad, and they caught up so fast, and it was...I thought it was remarkable.

And anyway, I mean, I was trying to segue the conversation, you know, out of, like, sort of, like, tech things and more into, like, okay, like, what are the countervailing forces that, if we want Agile, we want to do Agile, if we want buy-in from Agile, that we can make this sale? And we can...and these are the ways it's going to come unglued. And how do we fix it? How do we keep this thing healthy and stable so that people aren't freaking out, or working nights and weekends, or, you know, all these things? And is it coming unglued on us?

JUSTIN: I'm curious for people who have been in college recently: what are they teaching the kids these days? [laughter]

VIVIAN: They told us that they were going to teach us Agile and then had us do Waterfall [laughter].

EDDY: So, it's applicable to the real world. Got it.

VIVIAN: They told us we were going to be learning Agile, and then they had us plan for an entire semester, do a prototype for a month, and then the entire second semester was implementing the plan [laughter]. We literally spent as much time planning as we did implementing. It was awful.

WILL: Would you say that they spent as much time teaching you how to come up with a plan as they did teaching you how to implement the plan, as if, like, coming up with a plan for developing software might be directly and intimately related to your work going forward?

VIVIAN: Not even a little bit [laughter]. They didn't spend nearly the amount of time teaching us how to plan as they did teaching us how to actually implement. But they did have us spend about four months planning and prototyping what we were going to be building, and that was the same amount of time that they gave us to actually implement it during our capstone.

WILL: Eh, I don't know. I wasn't there. I wasn't there. But yeah, you couldn't tell me nothing when I was back at school. Like, all these software engineering, team building, you know what I mean, all this sort of stuff, like, no, I had to learn my lessons the hard way. I would've just blown it off and cowboyed it over the weekend. I would've just, you know? Let's get a case of Mountain Dew, maybe a couple of Four Lokos. Let's party. Let's get this thing through.

VIVIAN: I mean --

WILL: We'll sit in here until it's done, and then it'll be done.

VIVIAN: It was an interesting experience because we had to form a team with people that we did not know, potentially, starting at the beginning of the semester, and then make a plan for an application that we had never built before, using technologies that we had not necessarily used at all before, building a scope of an application that we had never built before. And we had to do all of this planning under the assumption that we would be able to make an accurate enough plan that we could then follow it for multiple months with a fairly fresh team while we were finishing school.

JUSTIN: This is, like, every startup ever [laughter].

VIVIAN: And it was terri...It was great for the first three months of the implementation. We were following the plan; everything was going well. We were, like, adding features. It was all going really well. And then the last month, everything started to fall apart when all of the little things that we didn't realize were missing came crashing down. And that was why, leading up to the capstone presentation, I had two days where I worked, like, 16 to 18 hours each day working on basically reimplementing our entire system to actually work asynchronously and function in a way that actually was demoable.

JUSTN: Every startup [laughter].

WILL: Yeah. Welcome to the rest of your life [laughter].

EDDY: So, I was actually...I was going to mention, so Kyle shared an article that I thought was kind of funny, where it's like, you adopt both philosophies, right? You have Wagile, right? And you can kind of take the best from both and kind of have this hybrid approach. And I first was reading this article I'm like, "Ah, they got to be kidding. This has got to be crap," right?

But no, no, no, like, it's legit, right? Like, you get what best works from Agile; you get what best works from Waterfall, right? Do a hybrid of both, and you get the best of both worlds, right? So, I guess I don't know if that's a recipe for disaster because they're contradicting philosophies. But I'd argue that...so smartphones, because we were just talking about that, are built using a hybrid approach, right? They combine both Agile and Waterfall methods. Why? Because hardware creation requires strict sequential stages like Waterfall, while software apps and user interfaces are flexible, iterative Agile cycles, right?

So, I think that's a prime example where you can have both ideologies kind of coexist, right, and still be very productive, right? In smartphones, you can't just follow one philosophy; you can't just follow one methodology, right, for implementations. I think it's okay to do both. I haven't seen it in practice, but I think the idea is interesting.

KYLE: So, the article that I did post, it was just a Wiki article, for those not able to see the chat, but it was in response to Vivian. That is more akin to what NASA did. You're right; it wasn't full Waterfall. It was more of the Wagilefall or, you know, however you would want to say it, which is not an official methodology, right?

That said, I think you're completely right, Eddy. In hardware, you're going to see more Wagilefall-type things. When it becomes more of a meme—and it is funny—is when you have your glorious startups that start out on Agile, then management gets involved; they need more power; they need more influence; then you're doing Wagilefall. That's when it becomes more of a headache from what I'm seeing.

MIKE: And before the call today, Will was giving some ideas, and I think he nailed it. And maybe he should sell this, but he says, "You take the worst from Agile, the worst from Waterfall." He says he calls it Whirlpool [laughter]. You circle the drain [laughter].

WILL: Yes. Yes. Whirlpool.

MIKE: It happens, you know? You have ceremonies every two weeks that are just soul-crushing because they're so overboard, and you have year-long plans that you have to hit. And so, you're in an endless death march, and no feedback with the customers [laughs]. You can circle the drain for quite a while in misery that way. You can fuse the best; you can also fuse all of the worst.

JUSTIN: Until the money runs out.

MIKE: [laughs] Until the money runs out.

WILL: In this moment, right here, right now, today, sitting in front of you, I could not tell you what release the features I am working on are going in, what release is, like, currently in submission with the App Store, what release has been cut and is taking cherry-picked merges at a furious pace, what release has been cut and has yet to, like, actually be cut or, like, what our schedule is. I have no idea. I've been at the bottom of this whirlpool for a couple of weeks at this point, and I just deal with the ticket that the highest number of people are messaging me about the status of.

MIKE: How do you get the best parts? Like, a story I've been thinking about as we've been talking, because we've been talking so much about aerospace, I think a lot about SpaceX, and there's more than one thing to say about it. One thing that they did do is embrace the idea of iteration: let's not be afraid to blow up the rocket, and if you follow --

EDDY: Without people in it.

MIKE: Without people in it, yeah. Without people in it. Now, that wasn't maybe possible back in the Apollo days, right? So, I mean, we have things today that allow us to have some of these more agile processes. But if you look at the space launch system that NASA recently set up, do you know how much it costs to launch one of those rockets? Each rocket, I looked this up, is approximately two and a half billion dollars per flight, and it's disposable. That is, you don't get to reuse any of that. It goes up; it's gone.

EDDY: So, what attributes to that being so expensive? Is it because of all the salary, all the planning, all the organizations involved? Or is it the equipment, like, the material that encompasses? Like, what exactly is the most verbose expenditure when you're sending a rocket up to the moon?

MIKE: Some of that is the cost plus contractors. Like, they've fallen into all the dysfunctions that you can get of development, where they farm it all out to contractors, and the contractors get paid no matter what, and then they get paid additionally for the cost they go over. So, all of the horrible horrors of contract shops, they get all of that. And it's required to be in certain states for the senators who said, "Oh, I want it in my state." And so, it's poorly managed. Sorry, NASA, it's poorly managed [chuckles]. And I think most people see that.

If you look at what SpaceX has done, it is just shocking. They do over 100 rocket launches a year, and you don't even think about it anymore. They've got rockets that they've sent up, like, 40 times, and they're still launching them, right? The difference is so stark that if, you know, 20 years ago, you tried to explain it to somebody, they'd laugh in your face, because they're not even comparable.

SpaceX has sent up, like, I can't remember the numbers. I think it's more than half of the satellites that have ever been launched, and most of that's in the last two or three years. It just...It's a freight train, and there's nothing else like it. You can do it, and you can do it right by, you know, you still have to send up that rocket, right? There's still very much some waterfall aspect to it. But you can do that iterative development, and it works. And not only does it work; it blows everything else out of the water.

Now, there are some competitors; there are some competitors in China that are starting to do reusability now. And so, you know, there will eventually be competitors. And I'm not trying to say that everything about the SpaceX model is good, nor did NASA make personally all those choices, but, you know, it can work when you have a process that really does truly iterate.

MATT: Which you don't get with government bureaucracy.

MIKE: Right. But then again, NASA did get us to the moon. If you put the right people in charge and get it going...and I think that's what I'd like to finish up the discussion today on, and I think Will was pushing on this a little before. How do you get there?

Now, I suggested before that you have to have some level of trust between management and engineering. If you don't have anybody that'll say, "Okay, go build some stuff," then it's not going to work. Because then you're going to be told what to build; you're going to be told the timeline that you're going to build it in, and all those constraints are going to handcuff you to the point you don't get the flexibility that you want to actually be agile. You know, you're going to be agile on paper because you're going to have those ceremonies, but you're not going to be agile in practice.

So, I think it starts with that level of trust. You have to have leadership that's willing to say, "Hey, engineers, go build some stuff. We're going to give you room to build stuff, and we're going to support you on that. We do expect you to actually be working on things and working on deliverables. We're going to be working with you. But, you know, feel free to go through the process that it requires, because we understand that it requires that."

And that's a challenge, right? It happens anytime you tell a creative person to go build something. You know, you go tell your Renaissance artist, "Okay, go paint me a ceiling." There is a level of trust there that I don't know what I'm going to get. I hope it's good. And it can work out really well if you're willing to do it. Get the right people; let them do their thing. But you have to have trust.

So, I don't think that's everything, but I think it's a start. I mean, what do y'all think?

MATT: Trust is imperative.

VIVIAN: I mean, we've talked about it on numerous previous podcasts, but, Mike, you like to always go back to the psychological safety. And, normally, when it's discussed, it's kind of discussed from a top-down perspective where the subordinates, like, just the engineers actually doing the work, need to feel a sense of psychological safety in the work that they're doing.

But on the flip side, do the managers not also need to feel a sense of psychological safety about the confidence in the ability of the engineers and the work of the engineers to actually be effective for the business or the organization? Like, does it not go two ways in order to build that trust? And if it goes that two ways, how do you build, like, managerial trust as an engineer?

WILL: Yeah, I don't know. Like, the things that people will just be, like, they'll just take my word for like, "Okay, boss, I got it. Peace," shocking to me. You'll find out more on that later. But my gosh, I don't know, man, I mean, hmm, I don't know. I have to defer this one. Like, how do you know you're in good hands?

MATT: It's called communication. It's the key to everything.

WILL: Well, sure.

MATT: If you're communicating...it's easy to build trust if you can communicate with the people that you want that trust from. If I'm working on something, I instill trust by informing, being honest and transparent: "Hey, this may or may not work, but this is what I'm doing. And if it doesn't work, then we'll iterate, and we'll learn, and we'll fix those mistakes, and we'll move forward. But we will move," right? That's how you build trust.

And one of the people on this call has reported to me in the past; I feel like I put a lot of trust there. And I just trust the people who have reported to me to get things done. And as someone who hires those people and builds that team, that's on me to be able to do, right? And if I'm hiring the wrong people, then that's me at fault, not the people I'm hiring. That's my failure.

WILL: I always tell my boss it's his fault for hiring me [laughter]. You did this. You did this to yourself. You deserve it.

MIKE: I'm thinking about dating, you know, kind of the quintessential I don't know you, and I'm going to get to know you over time, build that trust. You know, people who are forming a relationship, you know, they meet; they give each other opportunities to meet their needs and see if it works out. Does it work? Oh, it did, so maybe I'm going to give them a little bit bigger chance. And over time, after giving somebody lots of chances, they keep on following through, you believe, "Hey, this is somebody who's consistently going to meet my needs, and I can trust them to do what I need them to do."

And I think that that kind of pattern applies everywhere. I'm going to give you this job. You know, I just hired you. I'm going to give you this task, and it's probably a small task. I'm going to see if you come back in two or three days with it done. Oh, you did? Great. You accomplished something and I, you know, I have a problem solved. Now I'm going to give you a bigger task. If you keep on delivering on those tasks, then you get more and more trust. And I think that you have to develop that over time by following through, like, by bringing the receipts. You know like, "Hey, here, I built this thing, and it works. It's making you money."

And I think that you have to be...Surprisingly, you can get away from that as an engineer and think, "Oh, I want to build my beautiful castle," and not be pragmatic and say, "I want to make my company money," because they're not paying us to build a beautiful castle. I mean, we can try to build a beautiful castle as we go, because then it'll resist the invaders over time. But you better start with some hovel that will let you sleep through the night.

THOMAS: Yeah, I was actually kinda going to say something similar to that, but I feel like trust in itself is a currency, right? With that trust, you get, you know, if you can build progress from that trust and then you get momentum because of that progress, then you get success. And I think the more success, the more progress you can show, the more trust that's going to be added into you, and then you just keep amassing the more trust, the more trust, the more trust to take on bigger projects and produce a more successful project.

VIVIAN: An iterative agile approach seems to require an initial investment of trust in the engineers to be capable of starting, of doing that work. And then from there, that cycle of trust can continue to build and grow until there's enough trust that you can continue that approach without a ton of concern—that you can know that the engineers that you've hired, you know that they're capable, so you can trust them to do the work.

With a waterfall approach, there are times where it might be necessary because, again, there are hard deliverables that you can't really iterate on. But, otherwise, it seems to come down to a lack of trust. There is a lack of trust in the engineers to be able to iterate and continue to actually build progressively better work. And so, you try to avoid trusting your engineers by laying out all of the requirements beforehand with this idea that your engineers will just be able to do it because there's this plan that's laid out, and you can just...They either hit the plan or they don't, and regardless, you have this plan that you've laid out, and so you've done your work. You don't trust your engineers, and so you lay out a plan so that it's impossible to fail.

And this feels very similar to how a lot of AI development is kind of being pushed. You want to not actually write the code, just write the specs for the code, and then have the agent run until all of the specs are satisfied. And that can work, but, again, you're trying to essentially motivate sometimes the wrong problem because sometimes, in the process of writing the specs, you miss portions of what actually needs to be solved. And so, having more trust between managers and engineers and being able to create that iterative business process, it requires a higher level of trust, but it can be more effective, as we've talked about overall in this call.

WILL: You know, as I think about it, on one level, you know, okay, we talk about, like, sort of, like, the agile planning and, like, you know, like, agile planning versus waterfall and stuff like that. But, I mean, I really...One of the cool things about agile is you really don't need, like, company-wide buy-in. You can just do it. Like, your team can just do it. Like, okay, well, I have, like, I have this waterfall plan. Who knows what's going to happen with it?

And just, like, within my team, we can all just be agile and say, "Okay, I've got a two-week sprint. This is what we're going to get done in this two-week sprint. This is the MVP that we're going to get done in this two-week sprint. We're just going to get this...We're going to get this thing done, and we're going to get a demo up," and then, you know, the next two weeks; and the next two weeks; and the next two weeks; and the next two weeks of that. And you can just do it, you know?

MIKE: How else would you do it without taking the initiative and accountability, "Hey, I'm going to do this"? If somebody's going to tell you to do it, maybe you're not agile [laughs], right?

JORDAN: You know, the trust thing from Vivian is a great way to put this, is, like, where do you put your trust—in your developers or in your specs? And, you know, writing good specs is one way of building trust, or at least of forcing trust. But at the end of the day, it's like, if you trust your engineers to make you a great product and to steer you in a good direction and to, you know, do all that, I think that that trust is key to actually being successful. You can be successful the other way, as evidenced by NASA and other examples and things like that.

But I think it was Eddy that put the cartoon in the chat that had the poo at the end or the poo in the middle, but [laughter]...

EDDY: I can't take credit for that. That was Kyle. As much as I want to [laughter].

JUSTIN: Like, both of those actually, I think, are very indicative of, you know, of what can happen. But on the second one with the agile, if you are, like, encountering poop as you go along, hopefully, you can change direction where there is no poop. So [laughs]...and I think that is, you know, that could be, you know, a good guide for life.

EDDY: Or you just live with the poop [laughs]. You live with the poop, and you move on [laughter].

MIKE: You minimize the poop by steering in a tighter feedback loop.

MATT: You know, there's something to be said about that, though, and it goes back to that building castles. And Mike and I discussed this yesterday on a call we were on. There has to be some progress over perfection with things. And when you're building software for a business that needs to generate revenue, it needs to progress. And sometimes we don't get to build things perfectly like we would like to, but we build things that work. And if we're building those things scalably, then they will get some of that perfection over time. But, usually, especially in large enterprises, you end up with a lot of tech debt, you know? And it's things like code smells. But if those code smells aren't harming you, then you leave them be for now. And when you find on high-traffic times of the year that all of a sudden your system's coming down, you know, maybe they should've been addressed.

But you have to find that balance, and there's always going to be a little bit of debt when you're trying to build software to generate revenue for customers.

MIKE: I have a friend who has a dairy farm. If you have a dairy farm, there's going to be poop [laughs]. It's part of the business. But you can make the most of it. They've got a whole set of equipment to wash it down into, like, a reservoir that ferments for a while [laughs], and they spread it on the fields, and it makes everything healthy, and it all works out [laughs].

EDDY: Yeah, but wouldn't you eventually just acclimate to that smell, and then [crosstalk 58:58]

WILL: The pile, the pile doesn't go down.

JUSTIN: I am waiting to see how you relate this to, like, software development, so bring it home, Mike [laughs].

MIKE: The end result is, yeah, there's going to be poop in your software development. It's going to smell. There's going to be smells on the right; there's going to be smells on the left; there's going to be smells. And, you know, where those cows are feeding, it's going to stink. But you can develop some systems to --

EDDY: Who are the cows? Are we the cows?

WILL: [crosstalk 59:33] cow.

JUSTIN: Let him finish. I want to hear this [laughter].

WILL: I make the milk, which is the money [laughter]. Are the users the cows? Maybe the users are the cows. I like that better [laughter].They make money. I milk the cow.

MATT: Well, we're the ones producing, so I think we're the cows [laughter] [crosstalk 59:53]

WILL: I don't feel like a cow anymore. I feel like a farmer.

MIKE: The whole enterprise involves some degree of poop [laughter]. And sometimes you're going to step in it, and it's going to stink, but you can minimize, you can minimize the smell. And sometimes you can even use some of the bad parts to your advantage. I don't think you're ever going to get...

MATT: Sometimes you're the one leaving it.

MIKE: Sometimes you are. I've stopped in a cornfield before on my bicycle; I have to admit [laughs]. There's going to be some of that reality, and it's not going to be perfect. There's no such thing as an ivory tower in dairy farming that doesn't have a smell, and I think the same applies to software. But you can still build some amazing things and make a lot of money, and that's okay.

There's a process here that's going to be okay, even if it's not perfect, even if it smells sometimes. The end result is somebody somewhere gets to pour some milk on their cereal, and they'll pay for it. I visited the farm yesterday, so it's on my mind [laughs].

JUSTIN: Dude, I think that's a great way to end it [laughter].

MIKE: And that's what I think. I think that's the landing. There's going to be some poop, and that's okay. You just need to try to minimize it. And you don't want to have a great, big pile at the end that you have to land in. If you develop a process to deal with it as you go, it's almost certainly going to be better.

And with that, until next time on the Acima Development Podcast.