Matt: I think you should start a UML diagram, TikTok, because these people don't know. Nobody knows what a UML diagram even is.

Dave: There is a dream, right? Was IBM's, um, I forget what it was called, but you would write your UML diagrams and it would just produce the code for you. I dunno if that ever actually happened,

Matt: I think that's what they call no code. You just go into notion and drag and drop some things and then the software will be written.

Matt: Today, I'm joined by Dave Copeland. He is the CTO at mood health and the author of sustainable web development with Ruby on rails. Before that Dave was an early employee at stitch fix and living social. On today's episode of Yangni. We talk about small user stories. Taylorism the big design upfront straw man. And if we can find the 2022 version of agile on tech talk. Welcome to agni

Matt: So I did the first 10 years of my career in the custom software consulting space, you know, doing, uh, Scrum and Agile and all that kind of stuff. So I have, uh, I have sipped the Kool-Aid and, you know, been up and down the mountain of, uh, agile.

And I like how you phrase it on Twitter. It, it's like, uh, you know, agile guys TM with the capital A, and so I'm familiar with most of these people. Um, so I think what we're gonna talk about today is the sort of agile virtue of stories should always be small and you should strive to have your user stories broken down into.

One day tasks. Um, if they're bigger than one day, then you have sort of failed in your duty as an agile practitioner and you know, you should be, uh, slicing it down, uh, much further.

Dave: Yeah. Yeah. I mean a lot of this agile, so there's like big A Agile and little A Agile, so I learned a lot about little A Agile working at a startup where I think we did the things that Agile people would say you should do in a general sense. But there's a lot of stuff in Agile that's very regimented.

Like you, your story must be. one day or more. It's like, or like single responsibility principle, or you must write code only for a fit. Like all these like must always, shell never blah, blah, blah. And like it's, you just take it to the extreme because you lose the nuance of like why that's a thing. Like why do we wanna sh, why do we wanna work in small increments, Right.

That's the question. And yeah, we should, right, Because you get quicker feedback, You're forced to think of like, what is something valuable I can deliver in a short amount of time to get that feedback. And then if I get distracted or I get told my priorities have changed, then I have delivered some value because I scoped something valuable down to as small as I could.

That's, that's super important. I think turning that into your, your work must be done in a day or you haven't like broken it down enough. Like I don't think that's very helpful. I think that's, I think that encourages Jira. I right Where it's like, Oh, my job is to close Jira tickets, so I'm gonna like make Jira tickets that I can close in a day.

And then my job as a developer is to close Jira tickets and like that. , that's progress, but that's not really de delivering value and I don't think that goes along. I don't think that is really the spirit of Of lower case. A agile.

Matt: Yeah, and I think, I think that sort of, um, resonated with me because like having lived in that world of like the, um, I, I, it's, it's basically thought of a pejorative now, but like a feature factory, right?

Dave: Yeah.

Matt: uh, where like your goal is, um, like you're working on a team and a company hires that team and your goal is to deliver a certain, uh, you know, throughput and velocity, and they measure that based on tickets.

And, um, you know, it, it's, it's interesting and like, as I've gotten kind of out of that world and you look into some of the origins, I just think it's kind of a interesting story in general. Like I think a lot of the Agile stuff has its roots in, uh, Tailorism, which is like, uh, scientific management. It's this, this guy Frederick Taylor who had like a steel plant.

Do you know this

Dave: No, I don't, Huh?

Matt: So there's this guy like Frederick Taylor and he was running this like steel mill and. Um, he, and it's hard when you look back, it's like these guys all have some kind of strange like, uh, puritanical like value system, right? So like his, his big thing was like, uh, he didn't feel like, um, some people were like working hard enough basically at his steel factory.

And so he came up with these, uh, metrics that were like, Oh, for every part of this process, like, how long should it take? Like a hardworking man to do,

Dave: Yeah.

Matt: So it's like, oh, to sh you know, you should be able to shovel like two tons of coal a day or whatever.

Dave: Yeah.

Matt: so that, that. Became the origin of like, uh, like performance targets and uh, this whole field that they called scientific management, which was like, Oh yeah, we've measured and then we can, can process this.

And it's kind of like the root of, uh, you can see like the, you can trace back the lineage of like Henry Ford in the assembly line and all this kind of manufacturing systems and you get to like Toyota and uh, Honda production systems and that's really where. Directly ties in when people start talking about, about, uh, Kaban and lean and, uh, and how those things kind of get morphed into the software world.

So it's, it's really interesting that, that it's kind of, uh, struck me as as funny that like, now we call like a feature factory, like a bad thing, and it's like,

Dave: Right,

Matt: you took management principles for

Dave: And you applied that ? Yeah.

Matt: applied them to software and like you're, you were surprised that like you didn't build a software, uh, factory.

Dave: Yeah. Well it, it's funny cuz it's like, There's this perpetual need of like managers that don't understand how software works to manage like it's a factory because that's the only mental model they have for like, how do I know anybody's getting anything done and how do I see if, if they could be working harder?

And the assumption like, well what if they're not working hard enough? How do I like know that? Right. And it makes, it makes sense, but like someone has to explain like that's not really how software development works. It's. It's very, very hard to get it to work that way. And I think a lot of people wouldn't really wanna work under a system that did work that way.

Um, so I don't know. And then the other option is like, like the game industry where it's like, well here's a date and you're just gonna work your ass off and hit that date and I don't care. Uh, so like those two options are both terrible. Um, but any, I don't, every single time I've worked somewhere where we had like story points or any kind of, everybody wants to turn it into hours or days or weeks or something, and like, it's really hard.

You, you spend a lot of time explaining that's not what we're trying to do. That's not how software works. And it gets very tiring to be constantly explaining that like, it's not as predictable as you would like it to be.

Matt: Yeah, it's, it's really interesting. Yeah, because from that like manufacturing and like control theory lens, that's how, that's how like manufacturing processes are monitored, right? So, um, you might, you might like measure the vibration of like this machine and say like, okay, if it's, if it's like more than one standard deviation away, then like that's like, uh, you know, like out of control or like how many, how many, uh, widgets can we make?

And you're expecting it to be very consistent.

Dave: Yeah. Yeah.

Matt: almost, I almost wonder how much of this too is like the fact that, uh, Well, I, I don't know if it's a fact, but, uh, my, my anecdotes at least that like Agile seemed to like, kind of proliferate through like larger kind of manufacturing based companies that were like transitioning to software.

Clients, a lot of the clients that I worked with were like, it's, you know, uh, you know, a big. Tractor farming company that is used to like producing, uh, machinery and dealing with like the yield of, uh, you know, industrial farming. Like, oh yeah, like we can do software too.

Dave: Right. Well, and they get these consultants, right? Cuz there's a lot of money to be made being in consultant to do agile transformations cuz it's basically like we have software people, we don't know how to manage them. They, we don't think they're like getting anything done that we. Agile comes in and says, Hey, there's all these practices and stuff that can help.

And like in theory it can help. Like I'm sure, I'm sure it does, um, but it's still, you still end up with that. Like, now we've got things we can measure, so let's measure them. And, you know, I don't know how, how measurable they are or how, how, how predictable. I mean, even like, are you familiar with Dora that like the yearly, um, used to be an independent thing and now Google owns it.

But it's basically like they did this big survey of industry and they ask all these questions. That basically try to figure out like, how much value are you delivering as a team. They don't ask for that directly. They ask a bunch of things that sort of like hone in on it, but then they ask a bunch of stuff about how your team works.

Like how quickly can you deploy, uh, if something goes wrong, how quickly do you know about it and fix it? And so they come up with these like, they feel like better metrics, right? Like if your team is like deploying things quickly. Um, and they're fixing things frequently and they don't have a lot of errors in production, and there's like a fourth one, I can't remember.

Then you can say you're doing a good job. And then they can correlate that with teams who answered all of these business value questions. And then they can say, elite teams, teams that are delivering business value by their own judgment, but are delivering business value shipped to production more quickly.

So, so then theory, then these are things you can measure. To see how well you are doing. And even that is still this in directed way, like, just cause I deploy quickly doesn't mean all of a sudden I'm delivering more business value. Um, but that's why you see people online are saying like, Oh, we shouldn't do code reviews cuz that gets in the way of me delivering quickly.

Or that's, that's a, that's a gate between me and my changes and being able to get them up on production and like that is true. But just cuz you're like, unreviewed code changes go to production doesn't mean you're all of a sudden an elite team. Like if, right. Or even if it's not broken, right? You could ship all the most amazing, unbroken, quickly delivered code in the world.

But if it's not solving a problem that somebody has, then what was the point of it? And that's really hard to measure. I don't know how you measure that.

Matt: Yeah. It's even, it's even interesting, just you even like raising the concept of like, um, an elite team to me, like that, that makes me think that let like, uh, And it's so different too when you talk about, uh, like a game company versus like a fortune, you know, Fortune 100 manufacturing company,

Dave: Yeah.

Matt: um, like an elite team is almost bad, right in, in the kind of Fortune 100.

Concept. Right? And like everyone kind of knows the meme of like, hey, if you don't spend all your budget, uh, you know, like you lose your, your budget,

Dave: right? Yeah.

Matt: and that, that kind of dovetails into that one like, you know, weird principle that's like the work fills the time allotted or whatever.

Dave: Yeah.

Matt: it like, if you're operating in one of those contexts, like consistency is the most important thing.

And so like actually having an an elite team is like, actually. Bad because it's not predictable. And a lot of these companies are set up such that like they care more about, uh, consistency than, than the payoff versus like a game dev studio. It's like, uh, it, it's almost all about the payoff, right? It's like we're gonna kill our, we're gonna kill ourselves.

Like have this huge crunch time of development. And you hope that you get like the outsize return of like, Yeah, this is like the next big game. And every. Makes, you know, a shit ton of money

Dave: Yeah, but it's like the effort you put in doesn't necessarily determine if the game is any good. You gotta hit the deadline for reasons. But, um, that's the thing is like

Matt: at least, at least the payoff is like, uh, asymmetric,

Dave: Yeah.

Matt: right? Like it's possible to have this huge hit versus like, if you are like, Okay, I'm the v the, the VP of this product line within.

20,000 person megacorp, like your outcome is like, I was assigned these four projects for the year and like they all delivered within time and budget. Like that's how you sort of like win that game versus okay if you're a game company, it's like we need to like actually have, uh, results and it doesn't matter so much like how we got there.

Dave: Yeah. Yeah, exactly. So that's why, like when I was saying it, um, early at Stitch Fix, it felt very like lowercase a agile because we, I mean, The right, It's not a technology company, right? So it's like we're signing up customers who want clothes. We have a warehouse full of clothes. They need to get delivered to them.

They need to get return. Like there's a bunch of like stuff that like any regular company would do, that's not technology, but there's a technology team and. Early on, I mean, it was small, like less than 10 people. No product management, no. Like, I mean there was a CTO and then us and so it was very much like we had to go talk to the people we're building the software for, figure out what they wanted, um, try to deliver something quickly to get feedback.

All that stuff that you hear about with Agile, like we had to do that cuz there's no other way to do it. And then you could see, okay, I made this change to our warehouse management system and they're tracking these metrics and they're like, ah, that change meant that. We're faster at picking the shipments and that reduced our labor costs by X percent.

So, awesome. Great investment. Or you'd have the opposite. We're like, We did this thing. We thought it would be a good idea. It didn't have any effect. Okay. And so we really had to go quickly. All that agile stuff we had to do, but we didn't have any like Jira story points, tickets, users, so we didn't have any of that stuff.

We just constantly were talking to the people whose job it was to run that part of the business and constantly delivering them things to look at. And then when you do. You don't need any of that stuff. Now, how do you do that with 200 engineers and a 5,000 person company? I don't know if it works that way.

I think you need to be more organized and I think that's where all this stuff starts at. All these like ceremonies start to, to crop up.

Matt: Yeah, it, it really seems like agile or like the related frameworks are almost like, um, it's sort of like a bandaid that you need because as you get bigger, like you're just un I, I feel like you're un unable to find like enough highly skilled, specialized people that can, that can do that, that like they need, like you need sort of, Guardrails and guidelines and hard and fast rules, even if the rules don't really make sense, like you're willing to accept that.

Like, uh, hey, like we can put, we can put like a, uh, you know, an average, uh, quality, uh, you know, person in this, in this role. And if they do these things, even if they don't understand them, like it will be better than just kind of, you

Dave: Yeah. Yeah. And we tried, I mean, we, part of our interview process was like, there was an, there was a part of the interview that was like asking you to do this, like, Hey, talk to a user and don't propose some cockamamie technology thing. Like really work with them. Like, so we tried really hard to hire people like that.

But then the other side too is like when you get big enough, it's like the junior associate in the warehouse doesn't have any agency to say, Yeah, I'm gonna get everyone working in all of our warehouses to change their process. Like they just don't have that agency. So who does? And then it turns out it's some like VP of ops and like that person.

they don't have all day to like sit and talk in detail about software. So you have to have some way to communicate with them, here's what we wanna do and why, and then they want to know, did it work? And it just gets complicated.

Matt: Yeah. I think the other thing that is sort of appealing about Agile is like it, um, it's a complete worldview and whether or not like the worldview is good, um, like a complete worldview that like is at least for the most part logically consistent with itself is like an easier sell to someone that doesn't

Dave: Yeah,

Matt: uh, like strong opinions, right?

It's like a prepack. thing. And that's why, you know, you can get a consultant that will come in and they will hand you like a 80 page, you know, uh, spiral bound book that is like, here is like, here's the training for how to do this.

Dave: Here's how it works.

Matt: it's certain, it's certainly like a more appealing product than, well, you're just gonna have to kind of figure it out for like 10 years and then you'll kind of know what sort

Dave: Right. Yeah. And the funny thing is a lot of these sort of core agile proponents, they would say that you shouldn't hand off this like spiral notebook, that you should use these things to figure out what's right for you. And yeah, you should, but like it's hard like that. Explaining that is hard. And who's gonna.

I dunno what these guys get paid $500 an hour or $5,000 a day. That's a lot of money for like a couple years of like learning, um, to figure out what your process is. And so I don't think anyone's gonna, anyone's gonna pay that. So it's no wonder that this stuff gets turned into like these sort of like rules of thumb, things that you just follow and do blindly without thinking about what they.

Matt: Yeah,

Dave: though I'm constantly surprised why Agile people are surprised that this is what happens. I, I just don't, It's like, it's totally obvious. Like if you say, Oh, you should break your stories down. Okay, how, how, how much should we break 'em down? Oh, you know, maybe like a day. Okay. All stories should be done within a day.

It's like, well, no, that's not what I meant, but it's kinda what you said and kind of how it's gonna get interpreted. So, I don't

Matt: Yeah. Yeah. So I wrote down on my little notes. A phrase and I'd be curious to know like what, uh, what your take on this would be. And, um, it's, Nobody is talking about Agile on TikTok.

Dave: You know, I don't use TikTok. I see TikTok tos when they get retweeted. Um,

I don't

Matt: I don't

Dave: sense, but like I

Matt: true. I just thought

Dave: Yeah. I. . I wonder about it cuz I was thinking like, so one of my coworkers like makes mechanical keyboards on TikTok and I'm sure his videos are not like quote unquote funny. They're probably interesting to watch, but not like funny goofy things, which is what I think of as TikTok.

So it could mean that the demographic of people on TikTok is such that like they aren't yet thinking about software process cuz there's gotta be, Right? I mean, I dunno how old you are. I know how old I am. There's definitely people. Considered Gen Z who spent a lot of time on TikTok, who probably hold the title of senior software engineer at some company who probably have experienced being engineers and, and care about being a good engineer.

Like there, there's definitely people out there like that. So I don't know. Um,

Matt: Yeah. I, I just kinda wonder like if, if that is like the next generation of software leaders, at least at like the individual contributor level, like what, what is. What's the agile, you know, of, of 2022? Because it seems like agile has gone the way of waterfall a little bit, which is that like, uh, it's been like turned into a straw man version of itself where the principles have been diluted by, you know, consultants.

Uh, because to like reach the masses, it needs to. Digestible. And, but at the same time, uh, I don't know, like my, my initial reaction would be that like, things like, Oh yeah, you should only like, break stories down into one day would be, like, would fit perfectly with like the bite size, like no context like Twitter, TikTok, uh, Style of like information disposal now, like, but like when I was coming up, it was like, Oh, you gotta read this programming book from the, you know, pragmatic bookshelf and it's like a 300 page book.

And now it's like, yeah, here's like eight seconds of some person who works at Facebook. You know, like pointing to a text box saying like, you know,

big function's bad.

Dave: Yeah. I, I don't know. I do wonder what software engineering TikTok is, is like, um, yeah. I mean, I don't know when, when I was much younger there, there wasn't social media, and so I just learned what I learned from. The other engineers that I worked with or, or reading books. Cause that was just kind of all there was.

Um, so it's interesting. I don't know, maybe it's like there's a diversity of ideas that there is no, like for me it was like I did waterfall cause that's what you did. And then Agile came along and that's what you did. And there wasn't a lot of other inputs of ideas. Like, it was like you could read a book or you could go to a conference or your manager would tell you something and now there's like a thousand places to get information.

And so every idea is out. I don't know. I mean, it's really, really hard for me to, hard for me to tell.

Matt: Yeah, I think some of some of the things that were so like new or appealing about Agile, I think just like the good. The, the, you know, like the most effective, the good parts like, just became table stakes everywhere. And so it kind of like lost its, um, affiliation with Agile. I think you can see that too.

Like if you look, do you remember there was a thing that was called like the Joel test that

Dave: Yes. Mm-hmm. , definitely.

Matt: evaluating like a, a company or like a potential job posting or something. And like you looked at, you look at that and it was like, Oh yeah, there, there are so many things. Or on that list, like, and I think there were things like, you know, can you like automatically deploy your software?

And it's like, like at the time that was actually a differentiator between companies. Right

Dave: having release engineers who had to do

Matt: Yeah.

I mean now it would, now you'd almost, uh, you'd almost like, maybe you could in some weird, cheeky, like, you know, anti counterculture way, like be like, Yeah, we still do manual deploys as like a selling point for your company or something.

But like, I don't think, I don't think anyone into software now. Would think that that was the default. And I don't

Dave: Yeah,

Matt: it's always

Dave: using version control and all, all

Matt: Yeah, yeah. Using version control, right. Like that, that used to be something that you would say like, Oh, I need to ask this, Ask the company in the interview, like, are the, are you using version control?

And it's like, now it's, it's, it's just like a given. So I'm wondering how much of these agile things just kind of permeated into like, Yep. That's just how.

Dave: yeah. Right.

Matt: like Jira used to be like

Oh yeah. Like instead of a design document that's like 400 pages and then like, Yeah, like the software needs to do this.

At the end of two years, at some point it was like, Oh yeah, this is like, we're gonna break work down into stories and we're going to think about things from like the user's perspective. I think a lot of this just became like the collective consciousness.

Dave: Yeah. Yeah. Well it's interesting too cuz I was thinking about like, um, a lot of developers, like they. They're, they don't like doing a design on any level. And it's because Agile said, I think it's either Agile or xp. It's like no big design upfront. And like I think a lot of developers don't know what a big design upfront actually is.

I think because no one does that anymore. No one writes the 400 page design doc anymore. They're like, Any design must be that big design up front that I was hearing about. So we don't do that. And it was just, it was very interesting. Like at Stitch Fix I would be like, Hey, maybe we should like write a design before you start coding.

And some developers are like, I don't, why would I do that? We don't do design up front. And it's like, you need to think through what you're doing a little bit. And I don't think an agile person would tell you not to think through what you're doing. But yes, we're not doing big design up front, but it's like you said, like now it's table stake.

No one makes a big design anymore, so no one even knows what that is. Um, so I don't know. It's very, very interesting. Um, yeah, I don't, I mean, it still seems like it's a mess. Um, I, I worked on a big project at Stitch Fix where we had a date because the fashion industry, as you may or may not know, you do not launch a new, uh, line, um, in the summer or in the winter.

You have to have it ready to go for spring or ready to go for fall. So we had a date. It was either gonna be ready for spring or ready for fall. And business wise, it needed to be ready for spring. So we started doing stuff I wanted to do can band. I didn't wanna track anything. I was like, Look, we can just figure it out.

And the team just did not get anything done. So we had to start making stories. And we were like, Okay, people are asking us how quickly we're doing it. So we just said, Okay, every story is one point. We're just gonna show a burn down of just stories. And we're not gonna say how big the stories are. We're not gonna make the stories be one hour or one day or one week.

We're just whatever we come up with as logical units of work, we'll do that. And it actually worked great because our little burn down showed progress and enough to give of a manager a sense of like, Yes, we're working, and yes, we're heading towards our. Um, we made them prioritize the stories so that we could be like, Here's a line we're gonna ship either when that line is done or on the date and anything that doesn't make it, we'll do later or we won't do, but you prioritize this stuff.

Um, but it was always a conversation with everybody and it worked great and we didn't have any regimented sort of like rules about anything. We just had stories that we counted and that was kind of it. Um, But I, my job as the tech lead was almost entirely wrapped up in making sure everybody understood that and keeping people at bay who wanted to do, who, who, who just wanted more information or who were an anxious about the project and like, that was not a fun job,

I did not enjoy that, but it did

Matt: Yeah. Got results.

Dave: we shipped in time for the spring season, so,

Matt: Yeah, it's interesting. I, I also worked on a project, uh, you know, you know, a very large project, um, that had similar like, strange, uh, time deadlines that you wouldn't think, and that's like for, for like big Ag, ag tech stuff where, uh, you know, if you're shipping software onto like a self-driving tractor, uh, you have the same kind of down seasons where like no farmer is gonna like update their fleet. Uh, machine software, like while they're in the middle of working, like a 12 hour day is like planting or harvesting.

Um, just interesting that like, but these are also the companies that reach for the like heaviest agile process stuff that's gonna say like, yeah, no fixed deadlines. Like,

Dave: Right.

Matt: have a releaseable thing.

And it's like, well actually we literally do get to releases a year. So,

Dave: Yeah. Yeah. And that, that's,

Matt: wonder how much like big, big, upfront planning and design like would actually be more appropriate.

Dave: Yeah. Yeah. Or like, you know, um, fly control software, uh, I assume all the software that NASA uses, like they're under these constraint, like, like these constraints about, like, sometimes that thing has a deadline and there's a reason that deadline exists and it's meaningful and, and you can't ship the software, Right?

Like the tractor example's a really good one. We, we had one at Stitch Fix. We had like a customer service. Kind of app that the customer service team would use. And at a certain point there's like, you know, a hundred or 200 customer service people and you can't just change stuff on them every day. Cause like they're in that every day in their job.

And like, one, it's annoying. And two, they need to be trained cuz they're sort of like, they have a job that they're trained to do and if they're training all of a sudden doesn't match the software, that's not, nobody wants that. So then it's like, okay, well what do we, what do we do? And so you'd have to get organized around doing releases.

And that's just a, a, a function of doing business. And I'm, I don't know what's, I mean, I can only imagine what some Agile person would come up with to like, get around that. But the thing is, like my need as a developer to get my software done has to take second place to the user's needs to use a software for whatever it's for.

So like, if I want to be done with something today, but the user can't accept the change today. I have to wait, The user shouldn't have to suffer because I need to be done with something. Right. Um, and that's kind of a, a nuance that a lot of these agile aphorisms, like don't really address or charitably don't address.

Maybe don't even respect, I don't know. I definitely get a vibe sometimes where they're like, the developers are in charge of everything. You do what we say. Everyone will ow to the way we wanna work. And like, that's not healthy. I don't.

Matt: right. They, it doesn't seem to really capture like the. The rest of like the organizational complexity around some things of like, Oh yeah, like to, I think you raise a great example, like, Oh yeah, to add this new feature to the customer service tool. Like that's, you know, a three, we can definitely achieve this by the end of the sprint and we will like launch it, you know, live to production or whatever.

It's like, well, You didn't, you didn't account for that. It takes, you know, two weeks to rewrite the training manual or that there's a new batch of people starting, you know, like we onboard new reps every month and so like, actually you should not release this until, you know, September 1st, because you know it's gonna disrupt the cycle.

And Yeah, it's like, oh, well, you know, don't worry about that. Like, can we slice this, you know, and then play like scheduling Jenga enough to like get this in. And our, you know, next, uh, next sprint. And like the developers can ship it and they want to turn it on because, you know, uh, work is not done until it's live in the hands of customers

and.

Dave: Yeah. Yeah. And so then you have to be like, well, like one of our other products that I didn't work on, um, they, they suffered this problem acutely, and so they ended up having to build. A, you know, a feature flagging of complicated feature flagging system so that they could not only like get things into production without screwing up everyone's workflow, but then turn it on for certain users in certain cases.

So they would flip it on for like the managers, so the managers could play with it and update the docs, and then when that was done, they would do it, blah, blah, blah. And all of that like required some planning to figure out like what's the way to do that and how should that work? Y that has to be part of it too.

So that's, you know, when you're, you can't just take a feature and build it. You have to think like, well, how, how is this gonna go out to the users? And the answer might be, Oh, we'd have to build some complicated thing first to allow it to be, to be managed. And, you know, that requires some planning. Um, little bit of design, you know, And I think that's okay.

I think a lot of agile people would say that's okay. But it's very hard to read the agile literature and think that that's,

Matt: Right, And I mean it, it's, it's like a sufficiently complex scenario that like, I understand why in your like introductory materials, like you're gonna sort of gloss over that, but when like reality hits and that's how things are working in your context, you have to be able to. Uh, you have to be able to adjust, and I think that's what the principles, uh, versus the practices of Agile would, would tell you,

right?

Is, is like, you shouldn't, you shouldn't, uh, you know, just put your head down and follow this because, uh, you know, it was, it was written in the, the handbook.

Dave: Yeah. And then, I mean, you've got a, you've got a big organization where you've got veterans, uh, you've got managers who came up through software managers who didn't. Junior people and all of them aren't gonna necessarily read about a software process and understand the purpose of it. Right. You have to.

Why is it important? Like what problem are we actually solving by having sprints? What problem used to exist that now we've solved by, you know, taking a more of a user focus? And that stuff will be obvious to people with a ton of experience who maybe have been through it, but not a junior developer. So a junior developer may view Agile just as bureaucratic and terrible as Waterfall because it's sort of handed to them without any context.

Um, and they're not gonna know, like, , What was the alternative to making user stories that I get done in a sprint? Like why was that? What, what? They won't even know that there was a thing before. That's terrible. That this is solving for. Um, and that can be hard to get across to everyone at every level in the way that they're gonna understand it.

Matt: Do you know the, the show, uh, hot ones?

Dave: No.

Matt: hot, hot wing eating

Dave: Oh, is that what that is? Okay. I probably know of it. I didn't know that was

Matt: Yeah. Yeah. Yeah.

Dave: Yeah.

Matt: So as we go further in this discussion, I think we're, we'll get spicier and spicier. Um, so I'm, I'm curious, um, I think it was like a George Carlin quote that said, like, imagine the, like, uh, you know, intelligence of the average person and then remember that half the people are, uh, you know, dumber

Dave: Right.

Matt: I kind of wonder, like if you imagine like the ability of the average software developer and then remembering that half of them are worse than that. Like is there, is there like a benefit to having like these strict agile practices and even something like saying like, Yes, we can only give you like stories that have been broken down less than one day

Dave: Right.

Matt: as like a risk mitigating factor for the like decaying ability.

The average, uh, you know, the average engineer. Like,

Dave: I, I mean, absolutely you could believe

Matt: it's, yeah, and I think it's like, it's definitely sort of an uncomfortable, like truth a as as the industry. And I think it is overall a good thing, like tries to, um, bring in more people and as the field grows, like that's good and like we want growth in the, in the field, but there's like the unavoidable.

Uh, like pyramid nature of like experience and skill where like the more new people we bring in, that means like the average, you know, level of experience or, uh, I don't know if I wanna say ability, but, um, there's probably some correlation there.

Like it just becomes lower and lower. So like, do we say that like, well actually we want like to treat people with like kitty gloves and say that like, Yes, one person on the team needs to break down every story into these like, bite sized pieces. That's like all that we can realistically,

uh,

expect.

Dave: Well, it, it may right, It, it makes sense, Right? Cause you, like, I think about experience level as like, , what can, how much information do you need to get something done? And so someone with a lot of experience who knows the domain very well, right? The answer is like, they don't need much, but someone's right out of college or bootcamp.

Needs a ton. They need a ton of, and, and it's actually a shitty situation for them to be thrown into something with no guardrails, cuz they won't even know what to do. They'll flounder and they'll just, they'll just fail. So they need to be told on some level, like, here's what you need to do. Um, the, the, the hard part is when you get people who.

Don't want to be told who are being told too much what to do for their comfort level. And it's kind of annoying cause you feel like you're being talked down to. And I think the thing that makes it all complicated is a lot of these, it's not just the agile guys, but a lot of people are like, Oh, software is a craft, it's an art.

And they paint it as this thing where it's like you show up to the wood shop with a piece of wood and you like make furniture. And it's like, Not exactly. Sometimes like a thing needs to get done and there's only so many ways to do it and you just need to get it done. And like we are here to do a thing and perform work and perform labor and deliver a product.

And yes, it's not the same as working at a steel mill, but it's also not like we show up at our art studio every day and just come up with stuff either. So you need to have some way to figure out. , Okay. How mu how many, how much are we gonna, are we comfortable telling people what they need to do specifically?

And do we have a process to figure out what to tell them to do, uh, et cetera, et cetera. And if we're not willing to commit to that, then you either need to hire people who can figure it out on their own or just deal with chaos, I guess. Um, but yeah, I, I, I think what you said, like right, how, how, how else can you bring people who don't know what they're doing yet up to be successful and get their job done?

And also, More what they're doing.

Matt: Yeah, it, it feels, it feels too, like it's especially tricky to balance, like what is being like, uh, patronizing and what is like providing like, um, the environment in which you need to succeed,

Dave: Yeah, exactly.

Matt: Like, I don't, Oh, like even just thinking about that it like, kind of stresses me out of like, how do you like, that seems like you have to have a lot. Like tacked and, uh, uh, you know, it's a very precarious situation to be in of, like, I want, I want you to be able to succeed, uh, you know, early, in the early stages of your career. But I also like, don't, you know, I, I

want, I want you to learn the, the underlying reasons behind something. And sometimes you just need to like, uh, you know, trust, trust the experience to say like, Yeah, just like, do this

Dave: Yeah. Right. I do wonder how like other industries work. Like I have some friends who are, um, architects and I have to assume there's, there's some similar, there's some analogs, right? Because when you're making a building, like there's some design decisions that you need to make, there's some creativity there and there's some stuff that I would guess is very, very hard to completely express upfront.

Even when you get the plans. I mean, one of my friends, she. To the site for the building that she designed to watch them put it together and make sure that they're interpreting the plans correctly. So I wonder like, how, how that works. Um, and if there's some lessons there. Cuz I mean, my, my two friends, they like.

You know, when they were junior it was like they were told here, go do this. They were told to do and they were like, This is, this is a job. And there's a lot of engineers and I'm definitely one of 'em. I do not like to be told what to do and people tell me what to do. I'm like, come on, I can figure it out.

You know, I definitely get this attitude and I don't know how I was allowed to get that attitude, but like that just seems to be the vibe sometimes is like, engineers don't always like to be told what to do, and so how do you get them to do a thing that they need to do?

Matt: Yeah. I mean, I just like, my immediate reaction to that was like, that would never, the, the, the, the story of like, yeah, the, this, you know, the site supervisor or whatever is like going to the building site to make sure it's like done according to the, like, that would never. Fly in, like the culture of software development, at

Dave: No, I mean that, No, not in a million

Matt: that's, that's, that's the literal like architect astronaut trope

that's like, you know, someone who's not doing the work is gonna go decide how the work's gonna be done, and then they're gonna come and monitor and make sure that the work, you know, was, uh, you know, like you are my hands. I am, I am the, I am the mind.

Dave: Yeah. But the way I think about it actually is, I forget who said it, but they said that the, the code is the design. So if you think about this analog to building a building like the blueprints, that's like a code. And so instead of like a bunch of people building the building, we. The computer just does what the code says.

Um, but you still need all this observability cause it's like kind of hard to know how is it all gonna work together. So I need somebody to observe what the code's actually doing to make sure it's doing what I thought it should do. Um, so that's how, in my mind, I, I think about that. Like I just, Cause I can't imagine someone drawing a UML diagram and handing it to me and then coming up next week and seeing if I like wrote the code.

I guess if we, um, had all this figured out, then engineering would be easy. You would need to pay a bunch of people, a lot of money to figure it out without being told what to do. I don't know. I, I do wonder like in a hundred years what it's gonna be, what it's gonna be like. Um, cuz I guess, I'm trying to think.

I mean, when was software. Not a job. I mean, probably within my lifetime, I don't may, maybe before, maybe a little bit before my time, but still not a hundred years worth of this industry.

Even existing.

Matt: certainly I think like you had computer programming as a field in like, you know, The sixties and

seventies. But yeah, I don't think it was until the, I'd say like the, at least my understanding is like the, maybe the late eighties when

like the sort of the field

Dave: and, um, I don't know. And it's, I mean, I, I just, you, you observe like every new group coming in, not, not learning the lessons from the previous group and reinventing the same solutions to the same problems. And it's annoying, but I, You also get it cuz it's like, how do you learn that all those are problems to either, like, you just, you just come into it and you're like, oh.

I need a way to, you know, um, package my css. It's like, well, that already exists, but it's not written in JavaScript. Okay. Um, you know, again and again and again. And will that ever settle down or will that just be the way it is forever? I

don't know.

Matt: it feels kind of bad because I think we both have said, you know, today that like, um, A lot of times people don't understand the reasons why things are happening, and it's like, well, what's like, how do you do that? Well, like the best way to understand the reasons why is to like experience the pain yourself and then sort of like reason through it, uh, on your own.

And then like, ah, now I sort of can see, you know, the, the hidden structure of things behind,

you know, the facade. And

Dave: Yeah. Or you have a class that explains it. Right? But

I don't know if you, I dunno if you got a computer science degree, but I did. And they, they didn't teach you anything about software engineering. It was all like math stuff.

Matt: Yeah.

Dave: is fair enough, that's what computer science is, but it doesn't teach you how to like be a working programmer.

Like, I don't know how, The only way I know how to do that is, is to, like you just said, go do it and fail enough to learn the, the right lessons. Hopefully before

Matt: Yeah, it, it does feel a little bit sometimes like we're trying to pull the ladder up as we, as we climb it, of like, ah, yes. Like, we've figured out all the reasons behind this stuff. Like you got, you know, this next wave. Like, you don't need to figure out the reasons. Like here, you know, here we

Dave: yeah, yeah.

Matt: but then the people that know all the reasons are too busy, you know, like, um, doing the work and not, uh, you know, selling the courses about the work.

Dave: Right, Right. Yeah. I mean, some of the best engineers I've worked with, like would never go to a conference, never speak at a conference, never write a tweet, never do anything, and they share their knowledge with like, people they're mentoring at work. Um, but like that's the scope of their influence and I get it.

Um, you just wanna do your job and go home at the end of the day.

Matt: Mm-hmm.

Dave: but yeah. So they're influencing a few

Matt: and, and that's, that's probably like the largest, like the, you know, the, the majority of people,

like in the field, like have not like read a software engineering book in like, you know, the past. You know, five years or whatever. Like don't, they don't watch like programming lectures in their spare time or, uh, you know, follow, like, what did the latest, you know, thought leader on Twitter?

What, what is, what is the discussion, uh, about and.

Dave: Yeah. Um, yeah, cuz like, kind of why, what? I mean that will be interesting if the industry grows, you'll have people who are not like, quote unquote, passionate about engineering. They're just like, I want a job and I

Matt: It's already

Dave: job. Yeah. And so like, why do I want to, like, I guarantee you like my, I mean, My wife is interested in public health.

That's her job, but she doesn't spend hours doing side projects in public health. My architect friends don't design other buildings at at home after they're done working. Um, they just do their jobs and they enjoy their

jobs, you know, but

Matt: There's lots of jobs where professional development is actually like a, um, it's sort of like a obligation, right? It's

like you

Dave: medical field, you have to

Matt: you need to do so much professional development. And it's like, Oh, like, yeah, I have to go in on like, you know, Saturday morning for this like eight hour, like refresher course.

And at least like the. The programming culture that I was sort of brought up in, it was like, that was like, no, like you, that's like the fun, you know, nights and weekends type stuff that like you're interested in. And

Dave: yeah,

Matt: as, as programmer became like one of these, uh, sort of prestige positions, like, you know, lawyer, doctor, like software engineer, it's like, oh, you.

You know, work from home or work in a, a non terrible environment where you don't have to work, you know, 80 hours a week and you can make, you know, life changing amounts of money and, uh, you don't necessarily need a professional certification. Um, yeah, I think

Dave: great.

Matt: yeah, definitely.

Dave: Yeah,

Matt: the people that aren't, uh, you know, don't see it as a, as a, as, you know, like their life's hobby,

uh, are enter.

Dave: Yeah. I think it's fine too, but to your point earlier, those people are gonna need some structure about how are they supposed to do their job because they're not gonna, they're not gonna spend a lot of time trying to figure out new ways of working cuz they think it's interesting. They're just gonna be like, Hey, what do I, what do I need to do to be successful here?

And there needs to be an answer and

Yeah.

Matt: So I, I, I think it's kind of like a pet hobby of a certain programmer. Twitter poster, uh, to, to like, uh, bemoan, like the, how all software is terrible,

Dave: Yeah. Right?

Matt: everything is rotten, and it's, and it's like, well, uh, that's fine. But like what? Like what are, what are you, or like your schools of, of thoughts like doing to like at a, at a large scale have any impact on it?

I mean, certainly

you can, you can say at your small scale of like, Oh, like that's why I do these things. It's like, Okay, well that's. your

team, your little corner of the internet. Uh, for as bad as, as we may think, some of this agile advice is, like if it's, uh, a good enough solution being, uh, you know, putting enough guardrails that we're

sort of like, it's like you're plugging, plugging the dam with your, you know, your finger or whatever.

Uh, it's.

Like it actually has, it has like more of an impact, right? Like I'm sure these, uh, agile people that we think are maybe giving, I won't say bad, but like suboptimal advice, like have on mass, like maybe done more to raise the bar of software quality. Maybe we're just all like unhappy with like where the bar is like, yeah, it took it from like a two of 10 overall to a three of 10 and like everyone's like, it should be at like a nine of

Dave: Right? Or we've normalized what is, you know, it's like, oh, this is now normal. And now when I look at this is terrible, Like it's always terrible. Like you just normalize, even though it was better. Cuz you're right, if there was none of this, the default way of working would be waterfall. Because that I think is what people come up with in their mind.

You plan, you design, you build, you test, you deliver. Like that seems very logical. So, So that is what we would be doing if there was no agile. An agile group to point to, Hey, these are successful people that have these ideas, and we should do that boss. And the boss is like, All right, let's try it. Um, so that definitely, yeah, you're right.

It definitely counts for something and it definitely has had, you know, more of an impact than what either of us might be doing on our teams if we ever had teams

Matt: Yeah, yeah,

Dave: because that was always my thought was like, I'll be the CTO of a company and I will, I will set the way things, I, I I will, I will have control over that.

Um, it can, it can be done in the way that I think is, is a good, is a good way to work. Um, but as I'm sure you've experienced, like at the end of the day, I gotta do whatever, like the CEO says we need to do x, I can either do X or argue that X is meaningless and Right. That's, that. Those are the options. So, so even still, it's like I, you know, we're still under some constraints to do something and there's gotta be a way to get it done, um, reliably, or we don't look like we're doing our.

Matt: Yeah.

Dave: Yeah.

Matt: So I think that brings us back to the, uh, question, uh, breaking stories into small,

Dave: Yeah. I guess we never

Matt: small stories. Um, Oh, we did,

we did. Um, Yeah, so I, I will ask you, um, breaking stories down into one day or smaller, like, do we need it, yes or no?

Dave: I think it's. I think it's like a good question to ask. Can you do that and still, and have your story still be something that's valuable to deliver? I think that's a good question to drive. I don't think it's a good rule to have to follow, right? So if the an so like the answer is no, I cannot. Then you can have a real discussion.

Well, why not? Let's talk about this thing, blah, blah, blah. Um, but if instead it's like you will go and come back with stories that are less than one day of. Then you don't have that discussion. You don't actually, it's not, it's not as, it's not as good. So I think it is a useful framing question to think about breaking up work.

I would, I would add other questions to that too, but I think it's not a bad question. I think it's a bad

Matt: If, if, if pressed. If pressed, you gotta say yes or

Dave: If guys say yes or no, then I would say, I would say no. Um, I would, I would stay away from quantitative rules like that. If.

Matt: I think I've almost, I've almost flipped and that I think I came into our discussion today saying, No. and I think I've been able to convince myself that, um, yes we do need them, but in a contrarian, like as a method of, uh, top down control, I think it is needed.

Dave: Yeah. I mean, uh, what you were talking about before, about like having a control and structure. If, if that was how things were gonna go. Yes, I then I could see the reason for wanting something quantitative like that, Like, you know, break it down. I wanna see work done every day.

Matt: I'm just, Yeah. I'm imagining like in today's like mostly remote, um, context of like Yeah, I think, I think I would want to like slice down work and break it down into one day things so that like you could course correct and be like, Yep, it's been like three days. This was supposed to be a one day thing.

Like, what, what's happen?

Dave: Absolutely. I don't wanna be working on a task for like three days. It's gonna be maddening. I want, I wanna have an organized, like the end of the day, I'm done with this part of the work. I may not ship that part cause it's inter. But I might use it to organize myself, and I think engineers would do well to work that way internally.

Matt: Yeah, I think if you are gonna have a very ified story pointed user story, uh, process, then like, Yes, you should do this, you should break it down. Because, uh, because it will probably be someone with more experience, uh, breaking them down into chunks. And

so you are, if you're operating in a factory, you probably wanna like, use an assembly line,

Dave: Yeah, that's true.

Matt: I guess that's what my take will be.

Dave: makes sense.

Matt: If you don't, don't wanna be an assembly line. Don't work in a factory.

Show notes, links in a transcript can be found@agni.fm. Today's guest was Dave Copeland. You can find Dave on Twitter at Dave tron 5,000. And I'm your host Matt Swanson. And you can find me on Twitter at Swanson. Until next time, just remember you ain't gonna need it.