How Is a Big Project Different from a Small One?

About this Episode

In this episode of the Acima Development Podcast, Mike hosts a roundtable with Eddy, Dave, Chloe, Jordan, Ramses, and later Will, to explore the differences between small and large projects. Mike kicks things off with a personal story about industrial dishwashing as a teenager and how that shifted his perspective on “small” problems like doing dishes at home. He ties this to software by noting that scale fundamentally changes how you approach problems, whether that’s navigating your neighborhood versus traveling cross-country, or building a small app versus managing a complex, multi-team system. The theme: what works at one scale may feel trivial or even inadequate at another.

The conversation then moves into real-world engineering trade-offs. Dave contrasts working in application development versus database engineering, where different constraints (compute vs. storage) flip what’s considered efficient. Eddy stresses the importance of incremental, low-risk changes in large systems, while Chloe shares how her internship taught her that upfront design decisions carry far more weight in big projects than in small, flexible ones. Will and others riff on the “temptation of perfection”—the idea that if you just planned enough, you’d get everything right upfront. Instead, they argue for agile approaches: accept mistakes as inevitable, design for change, and value rework as part of progress. Several panelists tie this to the importance of embracing ignorance, asking “stupid” questions, and adopting a growth mindset to avoid paralysis when decisions inevitably prove imperfect.

The group also digs into the human dimension of scale: coordination. Jordan notes that large projects require consensus and approvals, whereas small projects let you move unilaterally. Mike reframes bureaucracy as a natural outcome of needing structured communication and shared understanding, not just red tape. Dave and Will debate decision-making heuristics—how long to defer choices, what counts as “enough information,” and how to balance planning versus execution. They conclude that small projects build the fundamental skills and intuition needed for larger systems, while big projects demand humility, adaptability, and collaboration. Ultimately, the episode emphasizes that success isn’t about perfect planning but about making good-enough decisions, coordinating effectively with others, and being willing to course-correct as conditions change.

Transcript:

MIKE: Hello and welcome to another episode of the Acima Development Podcast. I'm Mike, and I'm hosting again today. With me, I've got Eddy, Jordan, Dave, Chloe, and Ramses. Now, Jordan and Chloe are our interns. You all were on before, right [chuckles]?

CHLOE: Yeah.

MIKE: So, it's not the first time. It's not the first time here. But today is the last day of the internship that we had for this summer. And as a result, we're choosing a topic that I thought would be really relevant, something that we've talked about some with the interns, if they can give us some insight as to what they've learned. And having somebody new on a problem often reveals things that other people don't see. That's why sometimes grad students make good teachers [chuckles]. They're fresh to it, you know, they haven't been so distanced. So, I'm really interested in hearing about this.

Notice I haven't mentioned the topic yet. I'm going to give a little intro to introduce here. And I'm going to talk about a summer in my teen years where I worked at a Mexican restaurant [laughs] washing dishes, not just washing dishes. They also made me a prep cook and I heated up, like, beans [laughs]. But I washed a lot of dishes, and this was, you know, industrial dish washing. You can imagine what the pans looked like after they've been cooking whatever Mexican food they were cooking [laughs]. Just imagine, you're probably right.

EDDY: Did you use a pressure hose? It's probably the best way to clean dishes, especially large dishes.

MIKE: So, we had two things that happened. So, there was the customer dishes that came in, and those we had a big industrial dishwasher that we kind of did a conveyor belt style. You’d load them in, and they’d go in there, and they’d steam, and spray a bunch of water, and that worked pretty well. Except if you have, like, cheeseburgers, you know, cheese would melt onto it and stick to the plates [laughs]. I see Chloe smiling. She may have done this before [laughs].

And on the other side of the area where we did the washing, there was a series of three sinks, and that's where all of the stuff from the cooks, right, that's where that stuff would get cleaned. And that was the gnarly stuff. And a pressure hose...there was nothing that would take gunk off a pan when it first came over. And this wasn't, like, very authentic Mexican food [laughs]. They had, like, I don't know if it was blackened, you know, Cajun, but along those lines kind of fish that they would do. And they’d burn it all on the pan, all the seasoning that they would have around, and then we'd have to clean that off. So, imagine burned on fishy oil with spices and gunk. So, first sink was a soak with lots of soap. Second sink was for rinsing. And third sink was bleach. Soap, rinse, bleach.

And I’d spend hours every night. Well, before I ended up, like, hosing down the floor and stuff. Weird smells come out from behind kitchen equipment when you hose them down at the end of the day [laughs] [vocalization]. It's unrelated, just something I think of sometimes, that smell [laughs].

This is this industrial operation, right? And I would spend hours doing this, you know, the soaking and then you go to scrub the thing and if it wasn't coming off yet, then you’d go back in the soap soak. And, eventually, it was like magic. You’d soak it long enough, even the worst caked on stuff would eventually come off. And you'd rinse it and get it over to the bleach and out, and rotate back around to the cooks. And I got used to this. I'd been doing this for weeks.

And then came my rotation, remember, this is my teens, came my rotation to clean the dishes at my parents' house. And I went to do the dishes, and I just started laughing. It's like, what are these? Toys [laughs]? It's a little scrub brush [laughs] and, like, a sponge. Like, I used to think this was a chore. This is going to take me five minutes. What kind of problem is this [laughs]?

And it totally changed my perspective around doing the dishes. This is an entirely different job. I have different tools. I don't have real tools anymore, like, and I had to, you know, find the scrub brush. Like, okay, the scrub brushes work better at this than the sponge [chuckles], but still, it just all felt like toys. I laughed. Every time I did dishes that summer, I laughed because it was just so much of a different problem than what I was doing at work.

Today, we're going to talk about big projects versus small projects. And we're not washing dishes [chuckles], but maybe somebody's doing software for, like, a microcontroller for a dishwasher or something. So, maybe somebody out there is washing dishes. But a lot of these principles apply. The scale really matters. And this comes up often, actually, in our podcast. And you’re like, oh yeah, scale matters. It came up recently when we were talking about vendors. If you are very differently sized from a contract shop, then you're probably not going to get the right level of service because they don't cater to your needs. And when you're building stuff, scale matters, too.

And I've got a lot of thoughts on this. You know what? I'm hosting, so I'm going to throw one other thought out here: Navigating inside of a neighborhood. In fact, this is something I've seen in my neighborhood. Where I live the most prominent landmark is the village water tower. We've got a big water tower. It's one of the larger ones in the region, and you can see it from almost everywhere in the neighborhood.

We have a daughter of a friend who once got lost because she got into a part of the neighborhood where she couldn't see the water tower. And, you know, there's a little bit of hilliness, and so she got to a low spot. It's like, I don't know where I am [laughs]. And she was lost for a while because she had nowhere to go.

DAVE: GPS is unreachable.

MIKE: Yep [laughs]. And, you know, she may have been, you know, she was probably, like, she may not have had a phone. This was probably 10 years ago, maybe a little bit before everybody had a phone [chuckles]. She didn't have a GPS. But yeah, the water tower is the GPS that that's where you're going --

DAVE: That's what I mean, yeah. That’s what I meant, yeah.

MIKE: The water tower is the GPS. And so, yeah, she didn't know where to go because navigation is different when you've got a small scope versus a large scope. Once you get outside of that, well, you actually have to know which way you're going. You have to know where your cardinal directions are maybe, right? You have to recognize more landmarks than one. And, you know, traveling across the country requires a different set of skills than walking around the block. They both require skills, but one of them is fundamentally different.

And a lot of times it is hierarchical in that some of the skills that you would apply for that navigation of the, you know, of the small scale map may apply to large scale map, but you're going to have to say, “Okay, well, I need to get from Chicago to Des Moines.” And you figure out at a high level where that's going to take. But then when you get down to the actual implementation, you know, you have a detour. And then you switch down to a different level, and then you have a smaller map, a smaller map in your mind that you're dealing with. So, your hierarchy changes. So, you have to break down the bigger problem into smaller problems.

I wanted to throw out a couple more ideas to kind of get the thoughts. Also, Will has just joined us. Will Archer, welcome.

DAVE: Welcome.

MIKE: [inaudible 08:22] So, glad to have him with us. So, I've talked about big problems versus small problems. What are y’all’s thoughts? You know, open discussion.

DAVE: I will throw a weird curveball into this, which is that I just came here from a meeting with our DBA, Bill. And I think I've mentioned this before that, like, when I first went to the data team, it shocked me that on AppDev, we spend all our time...everything has to be small. Don't do big joins because you've got to get to the database, get your thing done, get back out. It's synchronous. It's, like, single threaded. We don't like doing big updates. We like doing small batches, everything.

And then behind the data center wall, compute everything because storage is ridiculously expensive. And when I went to the data team, they were, like, yelling at me, like, “Stop that. Stop that. Stop that,” because storage is free, and compute is vitally expensive because we're spinning up cloud servers [inaudible 09:19] down. And it was mind blowing to me. And we approached everything...I was so excited when they did, like, this 30-table join, and it came back in, like, one and a half seconds. And then, on the flip side, we tried to do select count from this table, and it took one and a half seconds. It's like you could do anything in one and a half seconds, but you couldn't do anything in not that amount of time, and I'm like, that's the difference. The get in, get done, get out is low latency. So, it's very, very orthogonal thinking is how you come to it.

And it was kind of exciting to talk with Bill about, like, “Well, how would you refactor?” And he's coming from a world where they would take the whole system down, like, to rename a column, take the whole system down, rename the table in the database, rename the table in the code, bring the whole system back up. And this would be after, like, a week of testing it in a replica to make sure that the name change was going to work.

And I'm like, yeah, we don't do that. We're coming from, like, finance and healthcare, where it's like, your system cannot ever go down. So, if you want to rename a table, you're looking at five separate deploys, you know, add the column; backfill the copy; add code to shoot to both places and to read from, you know, and to read from the new place. And once you're syncing always, then you start reading from the new location only. And each one of those is a separate deploy. And yeah, he was shaking his head. And he's like, yeah, that's fair. So, instead of big versus small, it's like breadth first versus depth first approach to covering the entire graph.

MIKE: But it requires different tools.

EDDY: Going the slow but sure route, I think, is the one that I've always appreciated the most, meaning don't go destructive; get it done in a day, but rather do it in a five-step process to make sure that everything you're doing is correct so that you don't lose any data, right?

DAVE: Mm-hmm.

MIKE: That's interesting. You're absolutely right, Eddy. You have to do that on a big project. But what if it’s your own personal project that hasn't even gone out yet? Do those same rules apply?

EDDY: If something's not actively being written to production, is that what you're saying?

MIKE: Yeah, that's right.

EDDY: Then go as crazy as you want, I think. You don't have any sort of sensitive data, like, actual factual data from customers or clients, right? So, I'd say you're free to play around.

MIKE: Now, Chloe and Jordan, you have been working on a project most of the summer, and that scale is different than what you do at school. What have you learned about working in a larger project versus a smaller one?

CHLOE: I think something that I've noticed is that the way that you design things and those decisions at the beginning can have a large impact on the project. When something's really small, if you're, like, I'm going to structure it, you know, this certain way, it's halfway through, and you're, like, hmm, maybe that's not the best, it's really easy to change. Versus a large project, those decisions are usually pretty concrete by the time you realize you might want to [chuckles] change it.

And so, I think it puts a lot more emphasis on the front end of thinking through the process of what's the overall game plan of this project? What do we want it to look like? Do we expect it to grow? Do we need to look at tools that can grow with that? Or I think there's just a lot more questions you have to ask yourself before starting versus when it's smaller, you can kind of just hit the ground running and then deal with problems as they arise. But you're not always afforded that luxury with a large project.

WILL: Ooh, so waterfall.

CHLOE: Yes.

WILL: The siren song of the waterfall.

MIKE: [laughs]

WILL: [inaudible 12:52] sensation to just be, like, okay, listen. So, listen, what if we just didn't make any mistakes in the beginning and we knew [laughter] everything that we were going to do? Despite being literal students, right, and this being a learning project, we're going to get it. We're going to nail it. We're going to tie everything [laughter] together. And it’s just going to be like, boom, bullseye right in the very beginning.

I think that is a very natural impulse that will be with you for your entire career. Like, you're always going to be, like, oh, what if we just didn't screw it up, you know, essentially [laughter]. It's a temptation. It's a very fundamental, natural human temptation. And I think, you know, you could get better and better and better on it. Because you go on and you have better instincts. You make better, like, just sort of, like, rules of thumb, you know, kind of stuff.

We talk a lot about, like, carpentry and building houses and, like, physically constructing things. If you’ve ever watched somebody, you can...you can watch people who are really, like, just good and, like, good framing carpenters, and they can just throw up a shed. And they just kind of know where everything's supposed to go. And it all just fits together, and it's right. And it makes me really mad because I'm okay with effort. But you’ll get better at it, but you're never going to be good at it [laughs].

And it isn't, like...the solution isn't, like, don't try because absolutely try. But there's also a feeling of, like, you know, let's just go and learn. If you accept refactoring and rework and reevaluating of your prior preconceived notions as a necessary process, when you hit that point, and you’re dead end, and you need to turn around, turn the car around and drive back, you'll identify it, and you'll do it, and when it's time, as opposed to, like, just, like, okay, I'm just going to muscle through. You know what I mean?

CHLOE: Yeah, I think that makes sense. I think it's inevitable that you're going to make decisions that eventually you might want to change. And so, instead of, you know, having this idea of no, we're going to make this decision now and it's going to be perfect, embrace that things are going to change and kind of learn to work through those things. I agree. I think that's a good point.

MIKE: The agile software paradigm in a nutshell.

DAVE: That actually came up in my chat with Bill that his database thinking is old school. The reason I had the chat with him was because we're migrating phone numbers in our database. And we're literally moving from one table to another. And I had a chat with him of, like, we've been working on this for, like, six months, and, you know, what should we have done?

And I realized when I invited him to the meeting yesterday, I said, “I'm going to ask you what we should do. And I realized that the first thing we need to do is jump in a time machine and go back and not forget to have asked you what we should do before we do it. Because it's so much easier when you get the design right first.”

EDDY: It's so much easier to let someone else do the design that they're really good at to do it for you than [inaudible 15:55] [laughs]. Agreed.

MIKE: But it's inevitable. And we're talking about large projects. It's inevitable that on a large software project, the business domain is going to shift. So, even if you made all of the perfect decisions on day one, which you didn't, the ground is going to shift under you when what you were building --

DAVE: And if it doesn’t, the company you're at is going to go under. Sorry, if the software you're building doesn't shift, the company you're on is going to go under because the world is changing every day.

MIKE: Well put. You build really good horse carts, right [laughs]? You may have it perfect. You've still got a problem.

DAVE: Yep. I make the best abacus in town.

MIKE: [laughs] That necessity of change is going to come up on you. Tech debt can hit you even if you didn't know that you were going into debt in the first place, just because of that change in the world.

So, you know, we've talked a lot about this, Chloe. You talked about, yeah, I want to get things right in front. You do, and then you can't, right [chuckles]? You do all that work, and then you find out that you were given an impossible task. As Will said, you still try, and you do the best you can. You still measure twice, cut once [inaudible 17:22] carpentry [laughs]. It still might be wrong a year from now.

WILL: This is maybe advice that, like, maybe is specific to me, but I think it generalizes, like, at least decently. I've always been smart, and I've always been good at my job. And I've always been known for being smart and for being good at my job. And I think a lot of people in the business self-identify as smart and confident. And it leads me down a dangerous and destructive path when I fail to embrace my own ignorance and stupidity [laughs]. Embrace stupidity. Lean into it. Lean into it.

Like, you get used to being...you can get too comfortable being smart, especially if you're really smart. You know, like, we don't work with...nobody in the office...if you walk down the office, right? There's nobody...nobody is dumb. And there are very, very few people, maybe in sales, I don't know, who are average, you know? There's nobody. And so, you know, yeah, embrace stupidity.

MIKE: I'm going to build on that because I think that is a profound concept. Have you read any of the work of Carol Dweck, a researcher in learning?

WILL: The name is familiar, but I'm ignorant of her work.

MIKE: She’s done a lot of growth...I think I’ve got this right [chuckles]. She's done a lot of research on what she calls a growth mindset. And what she's found is that people who think they're dumb and people who think they're smart end up running into the same dead ends because the kids who think they're dumb, well, they don't try. The kids who think they're smart have their self-image invalidated when they make a mistake. And so, they don't try because they think, oh, I'm actually not smart. I'm not good at this. And they don't like that feeling, and so they stop.

My recollection is that this actually tends to affect girls more than boys because a lot of parents are like, “Oh, you're so pretty. You're so smart.” And they say a lot of “You are this,” rather than “You did this,” and that can harm the girls, right? Like, you think, well, no, there's nothing wrong with being told you're good. But it can actually be counterproductive when you say that you are frozen in this good state rather than saying, “Wow, you are a hard worker.” Now that completely changes the way you see the problem, right? Like, “Wow, you made a lot of mistakes today. You are working hard. Look at those scrapes you've got. You are tough.”

That is a fundamentally different way to approach the problem and is much more healthy. And the kids who think that way, that growth mindset, are the ones who tend to succeed. And that matters a lot when you're in school where you have to grow a lot. But then to Will's point, we're all going to get stuck. And if we don't recognize that, yeah, we're going to have to be dumb sometimes; we're going to have to be uncomfortable and grow, then we've run into exactly that problem.

EDDY: Yeah, the best advice I was given when I first started is, don't be afraid to sound dumb, right, kind of to add to that, right? Everyone has come from that point, right? And the sooner you accept the fact that someone who's been an engineer for 10 years is also dealing with the same thing as you are, things become much easier.

DAVE: There's an easy thing that I...it was probably me who told you that because I'm --

EDDY: Probably.

DAVE: I’m still happy, Eddy. About six months ago, we were standing around talking, and I asked a pretty obvious question. And you looked at me and said, “You are fearless about asking stupid questions.” And then three people in the group said, “I don't know the answer to that either.” And I'm like, not so stupid after all. And Eddy wasn't asserting that. I'm, like, no, that's actually a pretty smart, stupid question.

And so, the hard work versus...sorry, getting it right versus dealing with it, in my opinion, that's the same shape as being told you're perfect and not wanting to risk damaging that, which makes you nonfunctional and less productive and less successful versus being told if you're here, you need to get here. Just take one step up, and then if we come back to you in five years, you're going to be way ahead of the other people because every day you take one step up where the people who were smart to begin with haven't been.

And this is why I wanted to say this is getting the design right the first time is getting the design perfect the first time. When I put the phone number thing in, it's currently running in the most awful way possible. And I'm proud of it, so I don't feel like this is me shaming the company. We currently have data living in two places, and it's ugly, and it's messy. And both Rails models have triggers in them that when I get updated, I'm going to go check the other data location and if it doesn't match me, I'm going to fix it.

Well, first thing I'm going to tell it, “Don't update me back because you have the same code to update me when you save,” right? So, this data is constantly fixing. And basically, anytime you touch one of these things in the database, it settles with the other one. So, literally to backfill the data, you literally can just say, “Load an object, touch it, save it. Load an object, touch it, save it, load an...” And that's literally the backfill because the data can repair itself in motion. And all you have to do to backfill the data is just touch all the data, and that's great because, now going forward, any new data going in the system comes out correctly.

I went on leave for four months. I came back. That code is still there. We are running on that little donut spare tire for this data. And there's a part of me that's going, this design is terrible, and it's inefficient. There were many extra cycles...da da da. And then I'm going, we are one step closer to having the database right, and the website works. We're selling leases. We are giving people the things that they need. We are taking care of business. We have cash flow. And I love that. And, longitudinally, we are headed towards the right data schema, database schema, and I love that.

I would much rather be good at correcting an error than getting it right the first time because getting it right the first time doesn't scale.

EDDY: Well, I'd be surprised if any of you have been part of a large project where you got it right the first time. I mean, I'm happy to be proven wrong.

CHLOE: I certainly have not [laughter].

EDDY: Yeah, no. I'd be happy to be proven wrong. I think that's a very fair assumption.

DAVE: There's a rule that we found in the ‘90s, which is that a waterfall software process works very successfully if you have built it three times already. So, if you're making version 4 of the thing and it's the same thing, you're not reinventing it for a whole new world, right? It's like nobody has built 3 AI embedded products. That's not what I'm talking about.

I worked on a company that was making graphics cards, and we were making the 3K version, which was after the 2K, after the 1K. And we've reused all the same processes because the way you manufacture silicon hadn't changed. And so, waterfall worked really, really good.

Do you know where we ran into trouble? That 10% of extra stuff that was all new. And we ran into all kinds of trouble, some of which broke the silicon. And I stayed up late one night swapping red and green in the software because somebody had made a change upstream that was now using the wrong channels for the colors in the silicon. Couldn't be fixed in the silicon without turning the chip in the fab, which was going to be, like, a $10 million impact. So, they're like, “No, fix it in software. It will be all right.” We got it wrong.

MIKE: To pull this back to where Chloe originally started, well, you have to think about the decisions beforehand. Well, you do. But you need to make a good decision, not a perfect one. And those are different [chuckles]. You do, in a large project, need to make a good decision. But it's infeasible to make a perfect one, so you shouldn't try because you can't. And it is a fool's errand, and you will end up spending all of the resources allocated to your project trying to make it happen in planning up front, and then you'll still be wrong.

EDDY: So, Mike, are you saying that a good decision implies that you can be agile about your design?

MIKE: I am. Because if you head out in a good direction knowing that some parts of it are going to be wrong, then you step in knowing, hey, I'm going to have to change. I'm going to have to take feedback and course correct over and over again. But that means that at any point in your project, from inception to finish, you're continuously pivoting. And you never reach that perfect ivory tower; instead, you make money. You actually bring in value [laughs] to your employer.

DAVE: Have I told you my mantra on...you get told, if you don't have time to do it right, when will you have time to do it over? That is waterfall thinking. Agile thinking is, if you don't secure the cash flow right now, when are you going to have a paycheck to do it right?

WILL: So, the question I've got, right, like, I love the conversation, right? And I feel like, okay, you know, smart, pat on my head. I made a good point. Everybody likes it. So, you know, I'm being applauded in my mind. My therapist would be very proud of me. But, like, I think, okay, let's take it a step further, right? We said, like, don't do this, right? Like, don't plan too much, right?

And balance in all things is, like, the essence of engineering, right? So, we say, don't plan too much, right? And I think everybody [inaudible 27:29] on that, right? But, like, don't not plan, right? And so, like, how do we balance the scales between, like, okay, you know what I mean? Like, I'm not just, like, shooting off half-cocked, but I'm also, like, not analyzing this thing and creating a 100-page PowerPoint before I even break ground, right? How do we balance that?

DAVE: I have a quote from Sandi Metz. Agile means deferring a decision to the point of maximum information and no further. That's the key, right? It's deferred as late as possible because information always goes up over time. But she does say --

WILL: I don't like that at all [laughs]. I hate that. Maximum information?

DAVE: Everyone does --

WILL: Maximum information. Like, that's, like, I don't...I am deeply unsatisfied by that, but I bet you have more to say.

DAVE: So, information increases over time, but at a certain point, you've lost the opportunity to make the decision because things have just been decided for you over time. And so, that's the ideal perfect time because, like, the schema is turning, turning, turning, turning. No, we have to shift, but now you have as much information on what the correct schema to go with is.

You are absolutely right. She's not saying don't make a decision. You do have to make decisions. And a lot of decisions if they're not impactful, just make them, right? It's pushing not all decisions are the same.

MIKE: Procrastinate as long as you can get away with.

DAVE: Procrastinate when it's appropriate, which is probably more than you think.

WILL: I find this deeply unsatisfying, and I'll tell you why. I think the fundamental thesis is right, but I don't like it as a heuristic because I think what I believe will eventually...if you're a perfect person and you're diligently following, like, that thing, what you'll run into, I believe, is the uncertainty around the information that you can get where it's just like, I don't know. How's it going to work? I don't know. What's going to happen here? I don't know. I don’t know.

DAVE: Not all information is equivalent, yeah.

WILL: You know what I mean? Because you don't have enough data. The uncertainty, I guess, the signal-to-noise ratio gets to the point where, like, you're making decisions, you know what I mean? And there's just no way of...there's no way of possibly knowing, not because, like, the information is not out there, but because you don't have it, right? You run afoul of...you just have to have a lot of wisdom and professional judgment.

And, like, you just need to have been around the block a few times. And you need to have, like, very much that beginner's mindset to be able to have, like, both the wisdom to say, like, “I don't know. How would I possibly know that?” And the judgment and the courage and the humility to say, like, “I don't know.”

And, like, to stand up to say, like, “I have no idea what the answer to that question is, Mr. Vice President. I would like several million dollars of your budget so that we could just, like, go off, you know what I mean, and see if this project lands.” And there might be some dumbass in the seat next to you without the wisdom or humility who's just like, “No, I know, and we're going to do it my way.” I think it's blind human nature and the sort of, like, emotional, psychological, social forces that these decisions are going to have to be made in. Does that make sense?

DAVe: I think so.

WILL: You know what I mean? Like, yeah, you're right.

DAVE: I think so.

WILL: We [inaudible 31:16] work.

DAVE: Yeah, I think not all decisions are the same shape. Like, I worked at a company where the CEO wanted us to look really good to the investors, so he splashed for a SQL server. And it was a nightmare. It wasn't easy to match. There was a lot of impedance. And because we went with SQL server, that forced a lot of decisions that were free decisions until he made that one. And five years later, we moved everything to Postgres. And we moved things to Postgres here at Acima. I'm not talking about Acima, just to be clear.

But that's the kind of thing. Like, if you make a decision I'm going to do it this way, and it's going to lock me into 73 other side effects that I haven't even considered, that maybe was a decision that could have been deferred and studied a little bit better. I'm not saying push everything out. But I would say, by default, I tend to push decisions back unless there is, like, no, this has to be made, or I can see that the decision has very little cascading downstream effects, if that makes sense.

You could probably use some sort of heuristics or some sort of rule of thumb around, like, percentages. Well, this project is, well, this project's got a $500 million budget. So, you have something outrageous, you know, some big government contract. You probably want to spend more than five minutes making that decision. If something’s got a $2000 budget, you probably don’t want to spend more than a few minutes making that decision.

DAVE: Absolutely. I wrote a script to keep track of what branch I'm on in Git. And the very first version of it, I used YAML store, which is literally just a YAML file as my database, and that worked great for about six months. And I eventually had to upgrade to SQLite. I didn't want to go all the way to put a database server on my thing. So, I was like, yeah, let’s just install SQLite. I can do that. And that's enough SQL to do the things that I'm keeping track of.

But what I needed out of that decision was for the decision to be made quickly and to not slow the little project down. And that could have, like, if I was running a production business and I had made that decision, we might run into all kinds of scaling problems. Because pretty soon it's, like, well, we don't want to change databases, so we're going to write all this stuff to deal with the fact that we got this wrong. And welcome to the rest of your career. It's going to be solving your solutions is so much more painful than solving your problems.

MIKE: Going back to what I was saying about the different scales, you can say it in percent. What is it, 5%, 10% of your time should be spent up front making some decisions. And I don't know exactly what that number is. It shouldn't be 50% in general [crosstalk 33:56].

DAVE: I would be tempted to think the number changes, but yeah.

WILL: I mean, I would say, like, rather than, like, sort of, like, a percentage, right? Like, I would say I want a story for, like, a thing. Like, this is a thing, and this is going to happen. And somebody is going to open thing up, and they're going to go on a journey, right? They're going to go on a journey. And, like, I'm going to, like, I want to make a web app. Like, okay, well, what's the first thing I'm going to do? I'm going to log in, right? And then I'm going to see, like, a to-do list, right? Something dumb. I'm going to make a to-do list. I'm going to make, like, a photo, whatever you're going to do.

Like, make a story for, like, this is the person, and they're going to do the thing. And then what are they going to see, and what are they going to do, right? Like, that's...like, it's a school project, and I'm going to write, like, a database. And I'm going to enter data, and I'm going to have a row. And it's going to be a thing. Just have a story of, like, just what this is in plain, simple language.

And then, the story gets more or less detailed when you're in a big organization where it's, like, okay, well, I'm going to go in here on the website. And it’s going to be this team, and it's going to be this page. And this is what we're going to do. And then I'm going to talk to this service. I'm going to talk to this thing. And this isn't...it sounds like, oh, this is a waterfall, but it's a simple algorithm, like, the planning that you're going to need to do in a big organization versus a little organization.

Write out the steps. Don't have a lick of code. Like, I'm talking about plain English and napkin drawings. Like, you can do all this stuff on a whiteboard. Write it out. No code. Nothing. You’re just like, I'm going to talk to the Prometheus service to get a user log in because you got to do that. And you know where you have to go, or you should know before you're building it, right?

DAVE: We might be in violent agreement, Will. When you say push the design out and do it on a napkin, that's what I mean. You have just avoided choosing a tech stack and a server host. And that's the decision I'm talking about pushing out.

WILL: Yeah. I mean, but just a story, like a story, you know what I mean, like, yeah, nothing. No keyboards. Write it out with your fingers, those little [inaudible 36:16] popsicles, and, like, write it out. Go ahead.

MIKE: Are you suggesting, Will, that if you can tell the story, then you're at the point where you can make a suitable decision?

WILL: I believe, like, you'll write out the story, and then, like, somebody in your team will be, like, well, what about that, right? And you'll flesh out the story. Well, what about that? And you'll flesh out the story. And eventually, and this is, like, woo-woo and vague, and, like, okay, it is a craft that you learn, you know what I mean? You’ll get to a fixed point. Like, you’ll get to a fixed point where, like, you’re going to know what you're doing, you know what I mean?

And then, I think, some of it, unfortunately, I hate to like [inaudible 36:58] vibes out there, vibes. But you're going to start feeling some vibes, you know. And you will also blow it because it's just a story. It's a napkin drawing. And you'll be, like, oh, well, what do we think of that? Like, yeah, it's a story, you know.

MIKE: Emotions are sometimes looked down on, but they're there for a reason. You have those vibes because it's telling you something. So, I don't think we should be ignoring them. We should be using them to their maximum potential. And if you reach the point, like, hey, this feels good; this story resonates, that's probably telling you something.

DAVE: What you're saying, Will, matches very strongly with my view of, like, top down versus bottom up. When you build bottom up, you start with, like, the write me an adding machine. Now write the multiplier. And at every step, you can prove that what you have built works. When you start top down, you might get to the bottom and find out you can't actually do it. You made an assumption about the latency of some system or other. But you do know from the very beginning that you're building the right thing.

And we've all had that thing where you build top down and you find out that, oh no, the database literally doesn't have enough latency to support this entire approach. We've also built bottom up and then found out that we climbed all the way up the ladder and found out the ladder was on the wrong wall.

MIKE: We’ve really run with Chloe's idea [laughs] about planning ahead of time and how that really is dramatically affected by scale. I'm curious, Jordan, what thoughts you have about the difference between large and small projects?

JORDAN: Yeah. So, I would say that the biggest thing I face, well, not face, but experience, and maybe this is just, like, the difference between working, like, by myself versus working in a business, was the need to get approval on many ideas and, like, changes to move in a certain direction, I think. So, like, similar to, like, the architecture and design, like, if I'm working on my own small project, I'm allowed to do, like, any change I want, like, willy-nilly compared to, like, here. Like, if I want to do something, I need to, like, propose it, like, architect out, and then, like, talk to people and get approvals there.

And so, I guess that's, like, I can have a radical idea, and then I present it to people, and then it's more, like, normalized into something that might work better for everyone, I guess. So, I guess that is the biggest thing I've experienced.

MIKE: You know, as I was preparing to host today [chuckles], I wrote down some notes. And one thing that occurred to me is that on a large project, you deal with coordination, which is a challenging human endeavor. And, you know, solo project, you're not coordinating with anybody but yourself. But when you get to a certain scale, you can't do it yourself. And now you have to add in another layer of complexity, which is how do I make this work with other people [chuckles]? Maybe I need version control so I can share this with somebody else, so we don't step on each other's toes. Maybe we need an API contract that we agree on so that [chuckles] when I send a message, they can actually receive it.

And working together is hard because you have to get shared understanding, and that takes a lot of work. It's the only way we can build big things. And the more big and complex, the more work that requires because the things have to be precise, right? And you have to have an interface that actually aligns.

I think that sometimes we think, well, there's all this bureaucracy. And, I mean, bureaucracy can be heavy handed. It can also be a representation of the natural work involved in coordinating across groups. You're going to have to have hierarchies of information that travel upward and then are coordinated between each other, which sounds a whole lot like bureaucracy. And it exists for a reason. Now, it can be misused like any tool, but it's going to have to exist because the alternative is anarchy, and then you can't coordinate anything at all. And that's not our goal.

And Will made the point about balance being so fundamental. I agree on that in many ways. I think finding a balance is tremendously important. But my key idea here is that you're going to have to do some coordination. And the bigger the project, the more coordination you're going to have to do.

EDDY: Well, you have more hands in the pot, right? So, you've got to satisfy more people.

MIKE: And that's not free. So, yeah, big project, you're going to have to get signed off. You're going to have to get people to agree with you. You might have to find a consensus or at least get somebody to make a decision [laughs].

DAVE: Jean-Paul Sartre, "Hell is other people," or in our case, hell is other people's code.

MIKE: On the flip side, I was reading somewhere sometime in the last month. I would have to go find the code. I don't have the source on it. But it was a researcher on human happiness. And if I remember the quote correctly, it said, "Happiness is love: Full Stop." Which is to say that hell is other people and so is heaven.

DAVE: Yeah. Yep. I heard a good one on this today, or last week, which is happiness is your circumstances minus expectations. I thought it was kind of interesting. Being present where you are instead of looking over the shoulder of the present moment to see the next problem that's coming.

MIKE: So, Jordan, you talked about the coordination that is involved in working on a larger project. What does a big project look like structurally versus a small one?

EDDY: I'm not exactly sure I understand your question. I mean, if you were designing a new service or whatever, I'm sure you have stipulations on things that you have to meet. In order for that service to work, you have certain metrics. You have certain clients that you work with. You have certain design that needs to fit. I'm not entirely sure I understand how broader than that you're asking.

MIKE: Well, let me give you an example. Let me give you my example. So, at Acima, we've done a lot with Ruby on Rails. It's been a popular web framework for a couple of decades now. And it gives you its particular take on model-view-controller architecture. Here's where your database interface layer goes. Here's this models directory. Here's where your interface goes to the outside world, you know, your controllers. Here's your views. Here's your templates that you're going to use to display things to your end user.

That works really good for a small project. You build a blog. You can throw everything in that structure, and it just works. If you have a large multi-year project, it doesn't answer hardly any of the questions because most of your business logic doesn't quite live there. And it might be needed to call from background jobs, and I could go on and on.

And so, you're going to build a massive set of business logic, some sort of structure to represent your business logic that is behind the scenes and not in that model-view-controller. Now, you might think of it as a logical extension of one of those. But if you try to cram that all into one of those out-of-the-box layers [chuckles]...I'm seeing looks of horror [chuckles] from people on the call. It ain't going to work. The scale deeply matters to the architecture, to what your code looks like.

MIKE: I heard this talked about by Uncle Bob. What's his last name?

DAVE: Bob Martin.

MIKE: Martin. He said that if you look at blueprints, you can generally tell what kind of building it is.

DAVE: Oh, I like that.

MIKE: But sometimes when we start building with a framework, we say, “Oh yeah, it should look like the framework.” No [chuckles], he says, “That's wrong. In a large project, it should look like what your business domain is.” So, you can look and say, “Oh, okay. I see what you all do. You know, here's the kind of the center.” It's centered around...you probably have a directory representing your primary business domain.

If you're doing something in finance, you're probably going to have something financial, right, at the center of your business logic. And if it's not structured like that, if instead it says, “Oh, here's your multi-controller,” then you're going to have an awkward time because it's built around your tool rather than built around your business.

DAVE: I was on a team once where my assessment after six months on the project was I stepped back, and I said, “I don't know about anything we're doing in the business to make money, but we have written an amazing program to support a database.” We were so bottom up. We were just, like, get the database, get the database. Everything had a table; everything had a trigger everything...da da da.

And a year and a half later, very little stuff to support the actual business. It was a Greenfield project, like, an investor's baby, where it's like, go do this, and do this for me. And so, we had a lot of funding. And after a year and a half, we started having some difficult conversations about what was coming out of this money. And I'm like, you got a nice program about your database.

MIKE: So, you talk about the structure needs to be different. How can we use some of the things we learn from small projects? Yeah, go out and build a small prototype in school. So, Jordan, Chloe, in school, you build a lot of small projects. You can almost think of those as prototypes, right? They are very purpose-built, specialized things to prove a point that you'll never actually use in the real world [chuckles]. But you do it to learn about something, and we do that in the business world as well, right? We want to learn how something works. Would this idea work? If we try this out, is it possible? So, we build these prototypes.

That prototype is probably going to have all kinds of bad decisions. You're going to have to rethink to build the real thing. But how can we apply what we learn from the small projects to the big ones? Is there any carryover? Do you have to learn an entirely new set of skills? Going back to what I was talking about in the beginning about navigating in your neighborhood, have you learned anything there that you can actually apply to the larger problem?

EDDY: I've learned to play nice with other people. I think it's really key. And be very receptive to feedback that you otherwise wouldn't.

MIKE: So, you're saying a large project, the larger the project is, the more the human element matters?

EDDY: 100%. You can't just make changes willy-nilly, assuming that it's a benign change. You've got to have adoption across the board. So, it takes a lot more coordination between everyone.

DAVE: That poked my brain. We were having a chat in the engineering...actually, Mike, you started it. We were talking about how does AI help you? And somebody pasted a tweet from DHH that said, "When I use AI as my pair programming partner, it's really skilled, really good. When I let it drive, I stop thinking. I retain nothing, and it's useless."

And, in my mind, that's very close to what you just said about do we build a prototype and then leverage it? Or did the AI build it for us, and we've got nothing? We used to be raised on "build one to throw away," right? Because you're going to learn so many lessons from building the first one. And the important thing is to throw it away when you're done because you've made so many mistakes. Don't fix them. Just build the new one without the mistakes, right? And, like, in AI, if you let it just do it for you, that's not a prototype. You can't leverage that much anyway.

MIKE: That's interesting. You didn't learn from it because you didn't build it. Cheating on your homework.

DAVE: Yeah. And there's times when that's valuable, though. I needed a thing that would log in with Google, right? Just OAuth. Simple. I’ve built three of these in five years. I've been on teams that have built 50 of them over the years. And I’m like, can't remember how to do it. AI, go build this login for me. I don't need you to learn me how to make an OAuth login. It's a small problem.

EDDY: For the listeners, I don't know if we have anyone out of state, but here we're in Utah, right? Salt Lake City area, whatever. If I have to drive to, I don't know, like 30 minutes away to another city, typically, I will drive there. I know exactly how to get there. I know all the directions. I know what the subroutes are in the event that the road is closed or whatever. At that point, it's just becomes routine, right? Like, I’m on autopilot, and I have to just do it for the sake of just doing it because it's expected of me to do it.

It gets to a point where I'm just like, dude, if I had an autopilot on my car, like a Tesla or whatever, I already know how to do it. I don't have to focus to do this because I already know. So, I'm just going to tell it to do it for me, and eventually, we'll get to the same spot, and I know that I got there.

So, like, for mundane tasks, you know, where you know 100% you can catch issues or bugs early or whatever, I would say that's fine. But when you’re having to go to a different place that you've never been to before, you're a lot more attentive, and you’re running the risk, you know, of autopilot kind of telling you where to go without paying attention. So...

DAVE: You just synthesized the thing that we've been talking about this entire time. Prioritizing the future value or assessing the future value of the knowledge and the skill. Driving somewhere, you can't manage a 70 mile an hour night knife fight in rush hour traffic when you are still learning clutch, brake, shift, right? You've got to get the basic skills in.

I've got a note on my monitor that says, “Insight is not cure. Get it under your fingers.” Now, this is a guitar teacher that told this to me. He's like, you can't be thinking about chord, voicing, mood changes if you don't know where your fingers are, and if you don't know where the notes that you need to target are.

And peeling that back, when I told the AI, “Go build me an OAuth login,” I put no future value in me learning that, but I have in the past. 20 years ago, I sat and sharpened the whetstone in software of, like, I'm just going to build this thing. I'm just going to do just this pattern. I'm going to do just this thing. You have to get those skills under your fingers then you can start mentally composing the larger things built out of that fluently, fast enough that you can actually start to create (I'm muddling my metaphors horribly.) but so that you can create music in your software in how you develop it.

And what you just said about driving, to me, it’s the same thing. You start composing those things. And it's all based on, the decision I'm making right now, what is the future impact? What is the cost of it? What is the value of learning this skill? Prioritize later, I think, is what I've heard that said. Not put prioritization off until later, but right now, prioritize the things that will create value later. And when enough later has gone by, you're going to be up here instead of right where you started.

MIKE: So, we talked about building fundamentals, because they will still be useful in the larger structure, but they'll be composed. It'll be made up of many of them. I’m hearing that from various voices here. Suggests that learning your skills on small projects and doing that schoolwork without cheating actually gives you something that will provide value as you work on the larger things because it will give you those components you'll know how to put together. And you may not know how to put them together yet, but if you don't have the pieces, you can't even start.

Well, I think that brings us to a pretty good place. We talked a lot [laughs], a lot, a lot about making decisions and about not getting mired in too much decision-making, but trying to find that right spot where you make a good decision and continue to make decisions, continue to pivot and get feedback rather than getting stuck.

We’ve talked about the human aspect, about the absolute critical human aspect on large projects because that's where maybe most of the work is. Well, not maybe, that's where most of the work is, is in coordinating across the other people so that you can build something bigger together. And we've also talked about building up from small to large. That's pretty good for an hour, if you ask me.

Thank you, and until next time on the Acima Development Podcast.