How Do You Break Up a Product Request Into Work?

About this Episode

Today we talk about how we break down work and what breaking work down means?

Transcript:

DAVID: Hello and welcome to the Acima Development Podcast. I'm your host, David Brady. And today we have an exciting panel. We have Eric Martinez, Ramses Bateman, Eddy Lopez, Mike Challis, and Jonathan Greiner. And we have one of our product managers sitting in the back. He says he doesn't want to join the call, but we might drag him into it. Because today we're going to talk about how we break down work. I'm kind of excited about this. I've got some ideas that I want to throw out, but I want to hear what you guys have to say. Just a cold start, how do you break down work, or what does breaking work down mean?

MIKE: I can say that if you don't do it, then you break down. [laughter] You can break down the work, or it'll break down you. Several years ago, I worked on a project. We started as a group project. It was a special project day. We took a day...let's go work on something we want to work on. We extracted something. We made a lot of progress. And we wanted to keep on continuing with the project. I'm not going to go into details of the project; they're not important.

But somebody was left to continue the work, and this developer who was working on it had this huge project. And they said, "Okay, well, I've got this huge body of work to do. So I'm going to work on a little bit over here and a little bit over there. And I'm going to come back over here and do a little bit, and then maybe over in the middle somewhere." And they just kind of touched a little bit here and there as they felt like it.

And I watched that project, and two months later, very little progressed versus what it had been two months previous because all the complexity of trying to think about the entire project had to be held by the developer in their head. They're trying to think about the entire project. And so that lack of focus on individual pieces meant that it didn't ever get done. And this developer was capable and just hadn't taken the time to break down the work.

So we then took the project. We said, "Well, let's do this differently." And that actually was a turning point in my career where I noticed just how important it is to break down every project into manageable pieces. I kind of take my own blame here because this was a less experienced developer. I should have stepped in [laughs] and been like, "Let me help you." And yes, this is me not really realizing how much this was needed as well, and so it was a self-realization.

And I realized, you know what? Every time I've got a project, if I don't break it down into small pieces I can think about, then I'm not treating myself like I'm a human. I'm treating myself like I'm something else, and I will fail. I need to break it down into pieces that can fit in my head. Me and the team I've worked with have taken the time tried to encourage this that when we see a project, to break it down into those human-sized pieces.

And unless it's in a piece that you think that you can say, oh yeah, that's easy, you know, if I were to number this through 1 to 10...usually in development, we use a Fibonacci sequence so 1,2,3,5,8, 13. And the team, several teams that I've worked with have said, "You know what? If it's above a three, it's not broken down enough." It means we haven't thought through it enough to break it down into a piece that I can fit in my head.

And the teams that I've seen do this have been wildly enthusiastic about the results because you're looking at a mountain and saying, "Okay, here's your spoon. Go dig it." It's completely impossible. It's so daunting you don't know where to begin. But if somebody instead says, "Here's a molehill, and here's a shovel," you're like, okay, I can handle that. And there may be a million molehills, [laughs] but you can handle that. You can keep on shoveling those molehills all day, and it's very satisfying.

DAVID: As always, Mike, you've thrown about five things onto the table that are sparkly and shiny, and I want to chase after them. There's a topic that's near and dear to my heart called cognitive load. And that's just...I like fancy words because I'm that way. [laughs] But cognitive load is a fancy technical term. The load is how much weight is resting on your brain if your brain was a muscle.

And what breaking a project down does is it reduces the amount of cognitive load that any one piece takes up. And hopefully, you end up in a place where the cognitive load of each sub-task that you work on fits in your brain. You can pick up that task. You can hold the whole thing in your brain. You can lift it. You can carry it. You can get it done, and you can move on to the next one.

And when we make the mistake of going over cognitive load, we often don't know that we've done it. The fun thing about the human brain, like, a microscope cannot look at itself. And most of the brain's ways of detecting problems about itself don't work. Like, the brain can't think; I mean, you can think roughly about yourself, but you can't actively perceive your perception. You can't perceive what's going on inside your head.

So I have had to learn tricks to tell externally what symptoms are happening in my life right now that might indicate that I am overloaded at some level in a way that I can't feel. When your judgment is impaired, the first thing that gets impaired is your ability to determine if your judgment is impaired, which is how we get ourselves into trouble.

So side tangent to this, I'm curious if you guys have had that experience of knowing when you're overloaded. And how do you get around it? Do you just go, oh, this is too hard to think about? Or are there specific things that happen in your day-to-day job that tell you, oh, I need to break something down, or I need to do something different? How do you tell if you're overloaded or if your task is too big?

So, okay, so that's kind of a scary question. It's like, how do we know this? It's invisible. I'm going to leave that for us to think on. I have some ideas. The one that Mike...that you said was two months went by, and nothing happened on the project. I've been that guy, and I've done that amount of nothing. And it was a lot of work to achieve that much nothing at the end of two months.

MIKE: Absolutely. It's a ton of work to get there, yeah.

DAVID: So when I see a long period of time go by, and there's nothing to deliver to the client or to my employer, and it is coupled with me having very high amounts of stress, especially if I start feeling impostor syndrome where I'm like, I shouldn't even be programming a computer; I got no business doing this, these are all signals to me that I'm trying to run it way too high of a gear, that I need to gear down. I need to cut my tasks into smaller and smaller pieces. I need to get more leverage on this because I'm just not grinding enough hamburger to feed the family. I'm trying to do too much.

I'm going to be all over the floor with metaphors today. Good luck, guys. [laughs] But you're not getting enough done. And so when a long period of time with no progress and very high stress, but importantly, during that entire time, I have this belief that I should be making progress. If you drop me into a brand new project, greenfield go build this thing from scratch; I'm kind of okay if some lead time doesn't produce anything. I expect it, then. But if the project is underway and has momentum and we kind of know generally what happens next, and then I get nothing done for a day, or 3, or 20, that's one of my big tells.

MIKE: I think what you're saying is practically true.

DAVID: Oooh.

MIKE: Like, it's true at the large scale. You get two months in, like, wow, this project is going slow. My team has been working on this huge project or my team of teams. Our company has been working on this project for a year, and it's not making any progress. What have we done wrong? Or I have been working on this for three months, and I'm not making any progress. What have I done wrong? Or I've been working on this for two hours. What have I done wrong? And I'm not making any progress. What have I done wrong?

I think that the scale is somewhat insignificant, but you call that something vitally important. When you notice that you're not making progress, you're generally doing some sort of loop. You're wandering through the woods, and you're like, wait, haven't I been here before? Well, you probably have because people aren't very good at walking straight, [laughs] and so we tend to just walk in circles. Well, the same thing happens in your code, in your cognitive work, whatever it is, I think.

If you find yourself not making any progress, you're probably in a loop where you're just kind of banging away on something, stepping away, and you're banging away on the same thing and not making any progress. And that suggests that it's time to rethink your assumptions and your process.

DAVID: I like that you scaled that all the way down to some tiny thing that you thought was going to take five minutes. It's two hours later, and you've gotten nowhere with it. We talk about things that block tickets, like, when do we run into a blocker? And the original idea for stand-up meetings was this idea that you say what I did yesterday, what I'm working on today, and you raise visibility on anything that's blocking you from completing what you have to get done.

And the funny thing that I learned there is that the blocker is almost never something that you anticipated because if you anticipated it, then you say, "Well, what I'm working on today is this thing that has to be done before..." it's not a blocker. I know it's on my to-do list. And blockers, at least for me, they tend to blindside me. It's not like, oh, I need to write this database code, but I don't know the syntax for this new version of the database. It's never that.

It's, oh, I need to write this database code, but there's a person in the chain that I have to physically have a meeting with and talk to them face to face. And I have no idea who this person is. I don't know where they..., and so I spend like two hours trying to chase down this weird side task.

Or it could be in software, but it's, you know, oh, I have to track down this device driver for Linux so that I can even talk to the network towards the database because it's got some weird security protocol or something like that. And you end up just going down this rabbit hole chasing weird side things that you keep getting blindsided, and you keep getting rolled over by this and that for me is another big time.

So when I get blindsided, I often don't know I've been blindsided. I think, oh, I'm just chasing the next prerequisite to finish this ticket. And then yeah, two hours go by, and you're like, wait a minute, I bid zero points on this ticket. I thought it was going to be a five-minute chore with essentially no impact to the schedule. But here it is; I've burned most of my morning. What's going on? And like, oh, hey, everybody, did you know we need this TLS driver on Linux to talk to the database? Uh, no. Now you can raise some visibility and say, "This is what's going on."

MIKE: There's so much there that's valuable. I saw an article once that I think made a bit of a splash on Hacker News or something, but I'd have to go track down the reference. I don't have it in front of me. The article made this...I think it was just a blog post. But they made an assertion that the way that our work as developers...it probably applies to other cognitive work as well and probably even real physical world work. The way that the size of a project scales is nowhere near linear. And the trick is complexity.

If you look at something and there's a lot of complexity in there, there's a huge amount of unknowns. And then you get into all those tangles. You get in with one tangle after another. And a better measure than trying to say, "Oh, this is going to take five days..." we're actually really terrible at that because there's a difference between ways of calculating the midpoint. If you've got a set of numbers, you can say, well, the mathematical average or the arithmetic average, I should say.

So you add the arithmetic mean. You add them all up together, then divide by the number of things. You get some number in the middle. Well, that's one way of calculating which number is in the middle. And let's hold that for a second. That's one way of calculating the middle, and we call that the mean.

Another way is to line up all the things and pick the one in the middle. That's your median. And usually, if you have kind of a random data set, they're about the same thing. But if you have a highly non-linear scaling, you have one thing that takes 5 minutes, and another one takes 10, and another one takes three weeks; another one takes a year; maybe your median is 2 hours. And your mean is six months. And that wild disparity between your median and mean means that we're really bad at giving estimates because we tend to estimate the median and not the mean. And complexity can throw this huge, enormous wrench in the works that makes things take orders of magnitude longer.

So when you're estimating [laughs], you need to remember that you're almost certainly going to get wrong on the mean. You're probably going to be pretty good on the median. And one way to deal with that is to break the work down into smaller pieces so that on each one, you can kind of define the complexity and eliminate the possibility of some of those gotchas. It makes much better predictions.

DAVID: Wow, there are two big things that I love for that. The first one is that anytime you're trying to do a linear approximation of an exponential curve or a curve that just curves, something that doesn't go in a straight line, you end up with this dip below the center of the line and the ends usually shoot up past the ends of the line, and you end up way off everywhere, except for where the line accidentally crosses your curve.

The best illustration I've heard for this is that if you line up all the humans in the world and order them by the number of appendages that they have, the average human has about 1.99 arms, but the median human has exactly 2. In fact, you can go 80%-90% all the way up the curve, and 80-90% of the population have two arms. But there are people at the end of the curve that are throwing off the mean. If you drew it on a chart, you'd have this long flat bit and then a curve right at the end.

And if you try to draw a line from the top of that curve down to the bottom on the other side where everybody has exactly two, that line is never correct, except for the very, very beginning when you take that very first human, and you go, you have two arms, great. And you're the only one here, so the average is now two; great, carry on. And then, the longer you go, the more your estimate drifts.

MIKE: I found the original reference, by the way. His name is Erik Bernhardsson, and it's definitely worth looking up. If you look up his --

DAVID: Can you spell Bernhardsson? There's like three ways to spell half of the sub-words in the name.

MIKE: Yeah. Erik with a K, E-R-I-K, and it's Bernhardsson, B-E-R-N-H-A-R-D-S-S-O-N.

DAVID: S-S-O-N, okay.

MIKE: S-S-O-N. And I just googled software estimation median mean, and he comes up at the top because, like I said, it made a bit of a splash. Read that blog post, and I think you'll think about estimation differently forever afterwards in a better way because you'll recognize some of the gotchas.

DAVID: The other thing that you said that really hooked my brain there is this notion that as we get further and further away, something gets bigger and bigger. The difference between the curve and the line gets worse and worse and worse. I love the Fibonacci or even the exponential curve. I've gotten good mileage out of just doubling the estimates 1,2,4, 8, 16. And both of these, the Fibonacci curve and the exponent, we look at this as like, oh, the job gets bigger, much bigger, much faster the bigger it gets. And no, it doesn't.

It's just that our ability to be precise falls off exponentially. So if you've got something that's bigger than eight on a Fibonacci, that's what? Five, then 8, so 13 is the next one. On a Fibonacci sequence, if you've got something that's 8, you can't estimate a 9. You just can't. You try to estimate a ten you can't see your yardstick that you're holding up. It's really hard to tell if there are one or two full yardsticks. You're off by a full meter. So estimated down to the inch is an exercise and a folly.

MIKE: Absolutely. It's that, you know, the degrees of precision. The digits of precision are important. Maybe you can take the digits of pi out of 20 significant figures. But most of our measurements are nowhere near that precise. And suggesting that they're more significant figures than you are is actually going to give you bad information. It's suggesting a level of confidence that's wrong.

Usually, we're much closer to those polls that say, "Oh, plus or minus five percentage points." [laughs] It could be, you know, I'm going to give no decimal points at all, and I'm still probably off by 5%, you know, within about a 10% range. I felt like I did pretty good at that. That's far more likely, and honestly, our error bar is usually a lot bigger than that.

DAVID: Exactly. There's a fun thing that you run into if you're trying to put information out of the United States against scientific data coming from anywhere else in the world. And you will often find...especially if it's meant to be consumed by the average person rather than by scientists because if it's by scientists, it's all going to be a metric. And if it's going to be by the average person, you're going to see something like, oh, we heated this water to exactly 39.214 degrees centigrade. And you're like, wow, that's really precise. No, it's not really precise. That was just 99 degrees Fahrenheit. And don't quote me on that. I didn't actually check those numbers.

But you end up with, like, oh yeah, no, we were just rounding to 100 degrees Fahrenheit, plus or minus 10 degrees. But somebody just slavishly copied over 100 degrees Fahrenheit is exactly 38 point dot, dot, dot, and however many decimal places. And they copied up to five decimal places. And you're like, wow, that's super precise. No, no, it isn't. It's terrible.

MIKE: Which goes to this idea of breaking down work that you got to estimate loosely. I will make an observation here. A lot of times, we look at that and say, well, then estimation is stupid. [laughs] Why should I do any estimation at all? I've probably had times in my life when I thought that, but I've changed my perception on this because I do think that project estimation is useful, but not always for the reasons that you'd expect.

DAVID: There's an entire school of thought called no estimates, and it's a sub-genre or a sub-flavor of the agile movement. And there are some people that I really, really love and respect that really champion this idea, and I have not extracted that information from their brain. I just want to put a pin in that, Mike, because I think we ought to circle around to this in a future episode, maybe even trick one of those experts to come on and talk to us about no estimates, about why they think it's good and what problems that solves.

Sorry for interrupting you. I want to put that pin in there and then say what you and I have certainly found is that, no, estimates are good. They help us achieve what we...or we think they help us achieve what we want.

MIKE: Well, let me say that I think that they are terrible in general for telling whoever wants to know when it's going to be done that it's going to be done. But they're pretty good at telling us the scale of complexity of the work. If we look at it, and we can say it was, oh, that's pretty big. I'd say that's five. Well, then, we know that it's beyond what we understand at the moment. It doesn't fit in our head.

TYSON: And I think the other value of estimates is it helps planning. This is taking it to a more larger sense of a business scale. But if we can give the estimates, it lets us plan for the future of what's most valuable based on the estimate.

MIKE: Well, and what it does, it might not give you an exact date. But if we went to a project and we say, "That's kind of big," that gives you one thing, but if you go in and you say, "Well, I have these size two pieces, and there's 50 of them," well, that's far more precise. It doesn't give you a number of days, but it gives you a very good sense of the scale of the project. And actually, if you get in the habit of doing this as a team, of making these estimates, then you can actually sometimes map it to days not too badly if you've broken it down to that level.

It's a ton of work, and you don't do that until you're ready to work on it. But at that point, you can get actually...I've seen teams come within a couple of days, like two or three months out, when they estimated this way. It took over a week to come up with the estimation. So it's very expensive if you're going to plan out very far. You don't ever want to do this unless you're committed.

DAVID: I would also wager that the team that did those estimates has been working together for months and months or years.

MIKE: Years.

DAVID: And they can reliably...years, exactly. You can reliably say, "This is going to take Mike two days. And this is going to take Dave two weeks." You can literally go through things and say, "Yeah, we know as a team we have a collective sense for how long this is going to take."

TYSON: I think it's also important to remember these are estimates. And so you have to be pretty flexible to say, you know, if we're going to put a date on it, like, oh, it's going to be two weeks, but then also realize we gave an estimate. And if you go past that, okay, that's fine, and we can re-adjust and plan accordingly. There's so much value on an estimate, and you can use it as kind of a guiding light, but also, you can go off trail, and you're okay with it.

DAVID: There's a planning tool called Pivotal Tracker that some of our listeners are probably going to be familiar with. My favorite thing about Tracker is that it is continuously giving you an estimate. Basically, it says if you keep moving at the rate you're moving, then you're going to finish exactly on this day because you've put all the tickets into the system, which we can talk about why that's a bad idea. [laughs] But Pivotal always knows; Tracker always knows how long it's going to be until you finish. And it's important to not go...by the way, to the listeners, that's Tyson Novakovich. That's the product manager that I was hoping to get to talk on this call. So I'm very, very happy. Welcome, Tyson.

Tracker will tell you you're going to finish on March 23rd of, 2025. And you do not walk out of there going, oh yeah, we are totally going to finish this. Because every time you complete a job, Tracker goes, oh, you said that was going to take eight hours, and it took you seven. And your estimate moves from March 23rd of 2025 to February 15th of, 2025. And you're like, whoa, I just jumped the schedule by two weeks. And well, yeah, because when you estimate an eight, it takes you seven, and Tracker keeps track of that.

And it's always giving (I learned a term just yesterday.) a good faith estimate. And what this is is you're basically telling management, this is when I think I will be done, but please, please, please remember, every single day, I find out something new. I find out things that I thought were solved that we're going to have to figure out how to do. I found this piece. We've got this entire chunk of time dedicated to figuring out how we're going to talk to the Postgres database, but halfway through the project, somebody came in and said, "Oh no, we're going to throw it straight into the data lake. I want you to talk to Amazon Redshift instead."

And now this entire sub-module of put it into Postgres, which, by the way, everyone on the team is fluent in, now it's put it in this data lake. It's going to be way more powerful. There are all these problems that we were anticipating with Postgres that just go away because we're throwing this entire cluster of cloud databases at it. But also, nobody's familiar with it. And so we've removed this big known problem and, oh, look, our estimate goes way down. Look at that; we're going to finish in 2022. No. No, you're not because we just threw this big thing in there, this gigantic unknown.

So every single day, my point is, every single day, we're going to management and saying, "This is the good faith estimate. Don't buy ad space for the shipping date on that day unless you're willing to cut features. Because every time we take a step forward, we find new problems, and you guys add new features." Hey, wouldn't it be great if...Can we add this? Sure, sure, you can. Drop it into the system. And here's your new good-faith estimate.

And it's never a promise of when we're going to finish. It is a calculation of if everything stays the same; this is about when we'll finish. And unless you've been on a team like the one Mike was describing, where you've worked together for years, and you collectively know about how big the work that team can wrestle to the ground in how much time, you're going to be way, way, way, way, way off.

MIKE: We could easily dive deep into this estimation. I think we should probably save that for a different...We're talking about recognizing how to break down projects.

DAVID: Yes. But in theory, the topic for today is how to break stuff down, and we haven't gotten to the how. We're just talking about the why. And are you sure you need to? How do you know when you've missed it? [laughs]

MIKE: It is a huge deal because it is a part. Because if you start by developing this ability to estimate some...how big is this for me? Then you can get a sense of the scale of the problem. And I think that that's actually one of the first steps. Until you get a sense of the scale of the problem, it's really hard to break it down.

If you have something that really is going to take you five minutes, if you spend two weeks breaking that down into the sub-components, well, you've wasted some time. But if you have errors and you take five minutes on it, say, oh yeah, we'll get that done, well, then you have not spent nearly enough time. [laughs] So, some assessment of the scale of the problem, I think, is an excellent starting point.

DAVID: I like that. Very importantly, revisit that scale. So many projects I've worked on, I've said, "Oh, we're going to build this over six months. We've got these really big unknowns. But let's assume that these unknowns are going to shake out this way, this way, and that way." And then you go into Jira or whatever case management system you've got, and you enter in great big epics for all of those big things. And the problem is three of those epics end up never happening. And there are three hidden epics that never got put into the system.

And you will go four, five months in...I've seen teams slavishly build those three epics that we originally predicted on day one because we never circled back. We had this great, big meeting where we tried to break everything down in advance. And the problem is we broke things down. We were breaking things into ones and twos, but they were four months out where we had no business breaking anything smaller than an eight because we don't even know if we're going to do this. This might be a zero because it vanishes from the schedule entirely.

My point there, revisit the grand scale of the thing. Don't just have one big meeting. Having a big meeting is fine. That's what I'm saying. But have that meeting again. Don't think that meeting is done and done forever and that you're never going to circle back. You need to circle back and say, okay, our good faith estimate has changed by this much. Why? What's changing, and what do we need to put on here?

And you have another big meeting, and you go through everything that's left to do, and your good faith estimate changes. I'm not a huge proponent of big meetings. But sometimes, they are a bad, bad solution, but they are sometimes the best solution. You might not have a good solution to something, a big meeting for me is that.

MIKE: Okay. So you get the people together. You get an assessment of the size of it. And then what comes next? I read a book. This was in "Team Topologies." Well, I listened to it somewhat recently. And it talks about how teams ought to be structured, and they give this great idea. If you look at particularly sedimentary rock, it has these natural layers, these strata. And so there are natural fracture lines. This is true of other kinds of rock too. There are seams within the rock. And a skilled stonemason, and times have passed, but probably still today knows how to exploit those seams to split the rock in the way that they want.

They're not going to go and just start banging on the rock and hope that it breaks into half. Instead, they're going to study the rock. What are the seams here? Where are the natural lines that it would split? And let's look for one of those just splitting the rock because then it's going to split cleanly. Well, I think that we need to look for those natural fracture lines in the work. So we say, oh, we got this huge project. Well, what are some natural components here that we can start to break it down on? What do you think of that idea?

RAMSES: I think those are interesting points. I often think about how important it is to understand the requirements before even starting a project. And then, if you're working with a sub-team, we're finding those requirements so each member of the sub-team understands those requirements. And what often happens or has happened is requirements change mid-project. And as long as those new requirements are discussed, just having clear communication and refining those requirements, like, constantly refining those requirements, helps to move a project forward, I think. And it makes it easy to break down a project and think about a specific component of that requirement.

DAVID: I like that. Try not to lose track of what is it exactly that we're trying to build. Don't get so laser-focused on what you are building and say, oh, I'm building the database adapter. And then you peel off for six months trying to write a general-purpose universal database adapter when it turns out we just needed to be able to do two queries and an insert. We didn't need to do anything else.

MIKE: It's interesting that you focus so much on understanding and shared understanding as well. Developing that shared understanding you said was critical to breaking it down because if you haven't gotten some understanding first, it's not going to work so well.

RAMSES: Yeah, it's hard to solve a problem if you don't understand it, like, why it needs to be solved. Because the product or the business can say, "Oh, solve this," and if you don't know the intention or how the end user is going to be impacted...

MIKE: So every product manager out there listening or in the call, [laughs] if we don't understand the problem, we can't build it. So your work is invaluable, and it's about helping us understand the problem. You can bring the engineers a description of the problem. We don't really need to know how to solve the problem; that's what we do. But if you can bring us a description of what the problem is, a succinct and actionable description of a problem, here's the goal, here's the problem, here's what we want to solve, we'll know it's solved because of this, that is what engineers live on, a problem that's well-described that we can go start working on.

TYSON: I wanted to...I think one thing you said, Mike, about the stonemasons looking for the key part of the stone to aim for, is when I hear that, I think of, well, that's how we aim for MVPs. If we have a big massive problem or project that we're trying to do, what's the MVP or the minimum amount of work that we can do to get to solving the problem? And then, from there, breaking out smaller parts of the project to improve upon the MVP. But MVPs are super valuable, and it may not be the most polished thing ever, but we're going get something out that solves the problem that we're trying to solve for.

DAVID: I love that. I've got MVP in my notes here, the minimum viable product. And I was hoping somebody would bring this up because at the very top of the call, when we said how do we break down work, the two things that my brain immediately jumped to are, let's treat this like a rope and slice the rope into pieces just from one end...We'll treat it like a loaf of bread and slice each slice up from one end to the other, working your way from one side to the other.

Where MVP, the minimum viable product, you sit down, and you go, what is the first thing the system needs to do to be considered not complete and feature complete but like, what's the very first thing the system needs to do to tell us our idea could ever possibly work? So it's like, I don't need to insert and delete from a database. I just need to connect to the database. That's arguably not a viable product. It's certainly not for the 1.0 of the thing we're trying to build.

But the first time I do this, I need to connect, and the second time, I need to hand a query to the database where I can just gin up this entire long string and just shove it at the database. Eventually, I'm going to have to build this whole adapter layer that can take these objects and spread them out and turn them into that query.

But I like the MVP because you kind of like take one corner of the...like, if the project is this great, big rectangle, you take one corner of it, and you just slice a little circle, you know, slice one corner of it out and you say, "This is my product." And then you slice another piece and another piece, and you just keep sticking them onto the thing that you've built.

And from the get-go, you have something that doesn't do everything you need, but it does something. And you can test it, and you can verify to yourself from now until the project is finished; everything we've done up till now still works. I can still connect to the database when I put this piece. I really, really like that. It gives me a lot of safety and security to know that something I just built didn't ruin everything we've built up.

MIKE: Do you remember when the iPod came out?

DAVID: Mm-hmm.

MIKE: How well was it critically received?

DAVID: Oh, that part, I don't remember.

MIKE: It was widely --

DAVID: Actually, I do. Penny Arcade is a webcomic that I used to read. And the way that I loved it was you could buy...at that time; you could buy a Discman, which is a CD, portable CD player. You could buy one of these for $29. And the iPod was $300, if I recall correctly. And people were like, "Oh, but when you listen to music in digital format, it never skips." And the Penny Arcade strip that I remember, he says, "My Discman doesn't skip either because I padded it with $270 of cash to keep it from bouncing around. [laughter] I'm using dollar bills as packing material." Yeah, it was a terrible idea.

MIKE: Everybody thought, like, critics said, "It doesn't have nearly the features of its competitors. All it really has going for it is it looks nice, and it's got an easy-to-use interface. But who actually goes out and buys and listens to music?" Well, it's like teenage kids who don't want to go and figure out a complicated nerdy interface to listen to their music. If they can press some buttons and easily get to where they are and play it, that's all they care about.

And that product was probably embarrassing to a lot of engineers who built it because it did almost nothing. You'd put a few songs on it, and you'd press play. Well, they iterated on that. They came out with a consumer product. Apple was not when that thing came out, the behemoth they are today. They were trying to recover. And they came out with this consumer product that was kind of outside of the normal things they'd been doing. And they just sold these kinds of weird computers. And they came up with a smaller consumer product to test out the market. Well, it worked.

They put out this minimal product that was good enough for some people to buy it. They didn't put out a massive smartphone that had three cameras on the back. They put out a thing that would play some songs. And you could press kind of like play and pause, and that's about it. And then they made it a little bit better, and then made it a little bit better.

And a few years later, they said, you know what? What if we take the same idea and we apply it to phones? And they birthed a whole industry and have come to dominate it and become what? At least at this time, the most valuable company on earth. Because they started with that incredibly simple minimum viable product, I think that should be a strong lesson to all of us.

DAVID: There was a lovely sea change that happened in the world, not just in the industry but in the world where prior to the iPod coming out, we generally consumed our music in albums. You would go buy a cassette or a CD, and you would throw that chunk of physical media into your player. And those were the tracks that you had available. So you listened to the album in the way that the producer layered the tracks. Like, bands used to stack their songs in an order that we're going to come out of this song and into the next one. What DJs do now bands had to do with their own music and present it to you in that format.

But all of a sudden, people are now doing...they're arranging their music into a thing called a playlist. And I had never done that prior to this. I was a stick in the CD; oh, I'm going to do this work today. ELO "Time" is going to be a good album to listen to today. And all of a sudden, I'm sitting at my computer, and I'm dragging all the tracks out in order that are all 170 beats per minute because I've got to really knuckle down and work really hard, really fast, really intense, and I need some really fast music.

And all of a sudden, I'm throwing in classical music, and I'm throwing in heavy...it's like when you come out of Vivaldi's "Four Seasons" and run straight into Rob Zombie. It's a little bit of a whiplash. But it worked because they were the same BPM which no producer has ever put together. Well, I'm certain that's wrong because now people can go buy an album that's just running music, and you literally buy the album at the BPM that you want.

But the playlist, the idea of you're going to sit down and figure out what you want to listen to in advance. And now you strap the iPod on, and you just push the big red play button, and that's the only button you need. And that was a sea change. Prior to that, we needed the seven different controls because I love this album, but I can't stand this track. I've got to be able to skip over it whenever I want.

MIKE: A fundamental change in the industry was sparked by people just simplifying, by the engineers saying, "What's the bare minimum we can do?" And it forced a rethink of the interfaces and the way we even think about the problem. Well, we're talking about how to break down a problem, and if we don't start there, we're probably doing it wrong. We have to start, like, what is the bare minimum we can actually do? And it may force us to challenge our assumptions to say, "Well, what can we really get away with here? What can we really cut?" And maybe there's a lot more than we thought that we could.

And if you're not being uncomfortable with the cutting, then you're probably leaving the project too big. You need to truly make it minimal, or else there's some of that complexity that's going to kill you. That non-linear complexity is going to make it take way longer than you expected. You need to shave as much of that as you possibly can to get something really tiny because if you get that really tiny goal, it's achievable.

And once you have something that works, well, now you've got something where before you had nothing. So that jump from nothing to something is the hardest part. And then you repeat and say, "What's the next minimum thing I can add to this that actually provides value?" And you aim for that. And you just put it on repeat. [laughs] You put that, and you do that in a cycle.

DAVID: I worked with project managers 15-20 years ago who told me to my face, "There is no minimum viable product." I must have every single feature down to 100% completion, or the entire project is worthless. And I opened up the project, and there were like two weeks spent polishing the user interface. And I'm like, this is...no, we need to teach you what an MVP is at this point.

I love that you said if you're not feeling uncomfortable while cutting features, you're not cutting enough. You have to remember; you're not saying we're never going to build this; you're just saying I'm not going to build this now. We're not going to sell this to a customer without this piece. But can we stand it up and prove to ourselves that it works right now, is useful?

The phrase that I like that's related to the uncomfortable one. I think it actually used the word ruthless, which is kind of like the mental image of a programmer just head down, looking up at you through the eyebrows with an evil smile and basically saying...the phrase that I loved was every feature must fight for its life, or it does not get to live on the project schedule. That's what you should be asking when you're trying to figure out an MVP. Look at any feature and then say, "Can we just not? How much of this can we not do and still move forward?" I love that idea.

If you're taking the slice of bread analogy and you've got to move data from...okay, this is a terrible mixed metaphor. You got to move data from one end of the loaf to the other, [laughs], but you've got these layers. You've got to move...you got the user interface layer. You got the client layer. Then you got like the middleware, and then you got the back end, and the backplane, and the messaging system, and the data system. You got all these layers.

If you have somebody sit down and say, "We have to build this slice of the project. It has to be 100% complete before we can move on to the next slice," I promise you that person is wrong, and you are looking at the project the wrong way. That's the maximum viable product is to finish that layer 100%. What's so much better is to take one tiny little core sample of that slice of bread, and then build the core underneath in the slice below it, and then build the core of that under the next slice below that.

And eventually, you end up...it doesn't look like a loaf of bread. It looks like a string of beads from one end to the other. And you can't run any useful data through it, but you can run a ping and get a pong back. And that pong came from the database server, which was on the other side of the network, which was through the enterprise backplane, which was through the messaging system, which was through the back-end front-end middleware all the way up to the client. And that first time you get that pong actually coming out of the database server, it's very exciting as a programmer. I love that.

MIKE: It gives you the skeleton that you can start building on.

DAVID: Yes.

MIKE: When they build a house, they don't start with the siding. They build the frame. And that's not how houses have to be built. They can build the kitchen, and they could finish it and put all the flooring, you know, paint the walls, put in the cabinets. You get that done and then move on to the next room. But nobody does do that because it doesn't work out very well for a project.

If you can build out that skeleton, then there's stuff to hang everything, stuff to hang your sheetrock, stuff to hang everything else. You can start to work in parallel once you've got that frame. And you can see it and have an organizing idea. And getting up that skeleton is a huge turning point for the success of the project.

DAVID: Absolutely. You absolutely can paint the wall before you build the wall. I realized that sounds bizarre and weird. But you don't want to just sit down and stretch a tarp over the wall and then paint the tarp. That's not how you want to do that, but you can. There are people who do critical path analysis, and they figured out that you can build a complete house with foundation, and cement, and electrical, and finishing work in like 18 hours of continuous time. We started at this time, and 18 hours later, we were done.

But yeah, the walls were assembled on the ground, and the primer coat was put on the walls while they were still on the ground, and absolutely, you can do that. But it's a really weird way to work. And you have to know exactly every messy, little side tangent, and in software, we often don't have the luxury of that. So it's much, much better if we can just go; let's dig the foundation and find out are there any pipes that we have to work around? And, okay, let's pour the foundation and find out any problems we've got there. And it's much easier to paint the walls once they've been built.

I feel like we now need to do another episode on actually how to break stuff down, [laughs] like how to break something into an MVP and what constitutes an MVP. There are still some open questions here. But Ramses, or Eddy, or Tyson, is there any kind of a coda that you think that we either need to touch on or that you touched on really well?

TYSON: I think it's much of the how, but I think even with the project itself is the why of it. And so really covering all our bases on the why we want to break things down is equally as important as the how. It's a good overarching summary of what we talked about today.

DAVID: Awesome. Gentlemen, thank you. This has been the Acima Development podcast. And, Mike, we'll have to talk about maybe splitting this...maybe changing the title into why break things down and then maybe circle back. I think that would be a fun segue. Or maybe we'll just call this the how and let people extrapolate from what we've said. Thanks, everyone, for joining, and we'll see you next week or in a couple of weeks.