Sara Bine (a Lead Programmer at Tighten) joins us this week to talk all about YAGNI aka 'You Aren't Gonna Need It': what it is, why it's so important for anybody who's building software, and more.
Sara Bine (a Lead Programmer at Tighten) joins us this week to talk all about YAGNI aka 'You Aren't Gonna Need It': what it is, why it's so important for anybody who's building software, and more.
Dave Hicking:
Welcome to Twenty Percent Time, a podcast that takes you behind the scenes of Tighten, a web consultancy based out of Chicago, but entirely remote and spread out all over the place. We specialize in Laravel, a PHP framework, but we're often pairing that with any number of JavaScript frameworks and libraries. I'm your host Dave Hicking. And this week I am joined once again by Sara Bine, a lead programmer at Tighten. Sara, how are you?
Sara Bine:
I'm doing well, Dave. How are you?
Dave Hicking:
I'm doing great. It's Friday, which is fitting because this is Twenty Percent Time, the day that Tighten devotes to 20% time. It's not just the name of the show, it's an actual thing that we do. I'm excited to be here to talk with you today because we're going to talk about a really interesting concept that is not unique to Tighten, but it's something that we definitely like to think about and talk about at Tighten often and I'm excited to share it with people. But before we do that, Sara, for people who don't know you, they haven't interacted with you online or anything like that, can you say a little bit about yourself?
Sara Bine:
Yeah. I've been a web developer for over 10 years, mostly PHP and JavaScript. I've done a little bit of mobile app development, which is what my earlier podcast episode was about, native script. And I just love software development and YAGNI is one of my favorite guiding principles.
Dave Hicking:
So let's start from square one. What exactly is YAGNI, and why should a developer or anybody listening to the podcast really know what it means?
Sara Bine:
Yeah. YAGNI is an acronym that stands for You Aren't Gonna Need It. So basically, it means don't solve any problems that don't exist right now, like don't write code to solve future requirements.
Dave Hicking:
Don't write code, does this extend to other things as well? Not just code, but would you say software development in general? Even, you aren't going to need that product, you aren't going to need that enhancement. Does the same thing apply?
Sara Bine:
Absolutely, yes. I think the initial coining of the term was referring to software development coding specifically. But I have widened its usage and use it to apply to many things, not just software development, also my life, which I also talk about later maybe.
Dave Hicking:
Yes we should.
Sara Bine:
But I do think it generally applies.
Dave Hicking:
I was going to say think I used this... I wasn't even thinking. I did the thing where I used work terms around my non-work life, around my wife or my friends. Someone was like, "Did you say YAGNI?" And I was like, well-
Sara Bine:
I don't know if I've gone that far. But YAGNI goes hand in hand with some other Agile principles that are all sort of related to simplicity. So I might conflate some terms, but basically the premise is that humans are bad at predicting the future, generally. So either you won't need the solutions that you thought you needed at all or you will need something different than what you expected. That's why YAGNI works.
Dave Hicking:
When did you first become aware of the idea of YAGNI? Was there a particular reason this like resonated with you? Was it sort of like the bell went off and now all of a sudden you could like see clearly or was it something that like over time you've like come to adopt?
Sara Bine:
Not at all like a bell going off. I heard about it at first, a long, long time ago, like early in my career I heard a lot about various software development principles. I think even in school we talked a little bit about Agile versus Waterfall, but none of it really clicked then until I got experience basically. So like many developers I had a phase in the middle of my career where I leaned really hard into like patterns and abstractions, because early on you don't really know much so you just kind of do whatever. And then in the middle of your career you read some books, you're like, oh, patterns, patterns are amazing and then you use them everywhere. And by doing that, by writing way overly complex abstracted code and then being forced to maintain it for a very long time I felt the pain and learned how bad complexity can be, and that was what made YAGNI click for me.
Dave Hicking:
Why do you think YAGNI is the best fit for the type of development that we do at Tighten?
Sara Bine:
At Tighten we are constantly the newcomers on projects, right?
Dave Hicking:
Yeah. That's true.
Sara Bine:
We also always work within some time box. So like our shortest engagements are eight weeks, I believe. We have longer ones but you know, most of them are some matter of weeks or months. So YAGNI and Agile principles in general, sort of allow you to reframe the question. So instead of saying like how much time will it take to accomplish everything we want to do, you get to ask, how can we accomplish the most of what we want in this amount of time that we have, because the constraint is your time. And that approach to development is actually reflective of reality and not an attempt to predict the future, which is impossible.
Dave Hicking:
This is going to spiral into a whole other conversation perhaps. But why do you think it is that we're all always trying to predict the future? Exactly what you said. I mean, when it comes to software development, sure. If someone's listening to this and they're a homeowner when they hire somebody to work on a project for their house, whether it's a handy person or whether it's a, full fledged general contractor, they want like an estimate. They want to know how much is this going to cost and when is it going to be done.
Sara Bine:
Yeah. And how often are those estimates right.?
Dave Hicking:
Well right. So it's interesting to me, it's the idea it's like yeah, and those estimates are almost never right. And that's for situations where, I'm not a contractor, I'm not a carpenter, but you would assume a kitchen is a kitchen is a kitchen. But I no that's not true and obviously the same thing applies to software but even like on an exponential level.
Sara Bine:
It does. Yeah. Because we're dealing with sort of exponential complexity. How many millions and billions of lines of code are actually running to like run your abstracted web app, it's a lot.
Dave Hicking:
Oftentimes the limit is, it's not so much like if I wanted to construct some sort of gravity defined deck off the back of my yard, I am constrained by the laws of physics, I'm constrained by what is structurally sound. You can make software do an awful lot, it's just a question of time and money and... Well time and money mostly.
Sara Bine:
Yeah, exactly.
Dave Hicking:
So those restraints are interesting. So when you are trying, even now as someone who's been, as you said, an experienced software developer for a while, are there guidelines or mantras or principles that you keep in mind when you're trying to make sure you stick to this idea of YAGNI?
Sara Bine:
Yeah, definitely. The most straightforward one is just, it all boils down to default to simplicity. So to me that means like whenever I'm faced with multiple options and I don't know which path is right, or which path I should take, I pick the simplest one. Simple can mean a couple things, it doesn't necessarily mean like lines of code or anything like that. It could be technical complexity. It could be requirement complexity. It could be like time or money or usability or whatever. Whatever it is, you have to think about your specific situation. But basically it's all about not backing yourself into a corner. So you want to leave your options open for as long as possible. It is very, very easy to turn simple code into complex code later, but it's extremely hard if not impossible to turn complex code into simple code.
Dave Hicking:
The idea of not backing yourself into a corner, to me, that goes along with what you said before how there wasn't like some bell that rang off in your head where you said, yes, this is the approach I'm taking. I'm assuming you speak from experience and you've been on projects or you've seen projects or you've seen code bases where it's very clear that people back themselves into a corner and there's really no way out.
Sara Bine:
I backed myself into corners, that's exactly how it happened. Mid-career when I got so excited about all those patterns, I wrote a bunch of terrible, terrible code that I had to maintain and it was so hard to maintain because I had backed myself into so many corners. So yeah, I learned that lesson firsthand and painfully.
Dave Hicking:
As you said, this isn't something that's ingrained in every developer. You talked about being at school and how they talked about Agile versus Waterfall. Is this the thing where YAGNI is not taught so it's just not the default for development? Do you think it's maybe counterintuitive or is it just the kind of thing where actually you have to have experience in order to understand why it's so important? Or is it something else? Why isn't this the default?
Sara Bine:
I think it's probably some combination of those things. I don't think I was ever explicitly taught about YAGNI or keeping things simple or anything like that. There is like a kind of prevalent mindset among developer types that complex software is better somehow, more technically impressive or whatever. They're in it to build the most impressive, possible code base. I'm in it to build software that solves people's problems, not the most technically impressive focus. But also it turns out that writing simple code is really hard. So it takes most people a long time to figure out how to do that. It took me most of my career to figure out how to get there. But I do think it is intuitive, I don't think it's counterintuitive. Humans have trouble with complexity. Like English has several idioms about complexity and like the dangers of dividing your attention. Having too many irons in the fire or having a lot on your plate or having your hands full or whatever, there's like juggling balls in the air or spinning plates. The more you try and take on it once the worse you will do at all of those things.
Dave Hicking:
Yeah. The comparison to English really as you were talking there, it made me think about honestly being a writer. Where it's like writing is not a competition, the goal is not to write the most words. It's not necessarily a goal to write the most complex sentences. The goal is to be understood. Writing well is not the same as writing the most or writing the hardest and-
Sara Bine:
Exactly. Actually, it's harder to write concisely and simply than it is to use a ton of words.
Dave Hicking:
Yeah. Yeah. So we need a Strunk and White equivalent for programming perhaps.
Sara Bine:
Yeah.
Dave Hicking:
Yeah. So the idea of what you said before about how you're not trying to write the most complicated code you're trying to solve people's problems. Like, I mean, basically you're trying to actually like write the code that you need and nothing more.
Sara Bine:
Exactly. No more than that. Only the code you need.
Dave Hicking:
So if a dev is listening to this and they're interested in these ideas, they're on board with this, but maybe either they have clients that this would be a hard pitch, they feel like, or maybe they're a part of a larger development team where this isn't really how they do things. Are there any sort of initial ways that you can approach sort of writing code with a YAGNI kind of approach or any like low hanging fruit kinds of like, oh, if you just start here, this is like an easy way to get into this? I don't know if that question made sense.
Sara Bine:
Yeah. Yeah. I would say start small-
Dave Hicking:
Appropriately.
Sara Bine:
Yeah exactly. Focus on keeping things simple at the smallest scale. Don't just basically default to not implementing patterns or abstractions until you really feel like you need them. Sean, one of my coworkers here at Tighten, has this rule that if he has to write something twice, that's fine but then the third time he'll make an abstraction. He'll copy paste it one time but then after that it needs an abstraction. I love that.
If you're thinking about writing code for some future thing, just don't do that. When you feel stuck between multiple options, pick the one that's simplest or easiest to change later. Just be aware, be mindful about not backing yourself into corners. Also, practice breaking down tasks into the smallest possible pieces so that you can identify the more and less necessary parts of each task and postpone the ones that are not necessary right now.
Dave Hicking:
Are there any downsides at all to the YAGNI approach? Or maybe a better way to put it, is it possible to take this too far?
Sara Bine:
It's possible to take anything too far, right?
Dave Hicking:
Sure.
Sara Bine:
I think probably the worst outcome of taking YAGNI too far is that you could end up shipping software that's immature, but I think the alternatives are much worse. I know that some people-
Dave Hicking:
What do you mean by immature? Sorry. I didn't mean to talk over you.
Sara Bine:
Oh no, go ahead.
Dave Hicking:
I was going to ask, what do you mean by immature?
Sara Bine:
So maybe you think that some of your features won't be useful unless you include more of them, maybe you think that what you're shipping won't actually be useful to the end user. I would argue that it's still better to ship immature software and find out, basically just prove your hypotheses. So instead of saying, I can predict the future, these are all the things we'll need. You say, here's some of what we need, let's get it out there and find out what we actually need to fill in the remaining gaps. So validate your hypothesis through user testing.
Dave Hicking:
Turning it almost into like a big science project effectively.
Sara Bine:
Yeah, exactly.
Dave Hicking:
I'm sorry I cut you off while you were talking. I think you were saying something else about like how you can take anything too far.
Sara Bine:
Oh yeah, right. Yes. So sometimes I talk to people about YAGNI and they interpret it as like never try and build anything complicated, but that's not what it is. Basically, it's just be aware that complexity has a cost and have a good reason every time you take that on. If it's helpful, maybe think about it in terms of like a complexity budget. So you can take on a certain amount of complexity and do okay with it. But you have to be judicious about which parts you take on so that the sum total of all of it is manageable for you.
Dave Hicking:
That's interesting. One thing that this all gets at is... I feel like I've been on a number of calls lately with clients and potential clients where for a long time at Tighten we've talked about the idea of an MVP, what is your minimum viable product? I feel like a lot of the times we talk about what's like the M, what is the minimum, but there's a tension there between like, well, what does viable mean?
Sara Bine:
Can anyone really say ahead of time?
Dave Hicking:
Well, right. But, I think those two things together go to the idea of the YAGNI and to what you said before, about how you actually have to test it. That sort of the fear or the risk that you might put something out that's not viable enough at all.
Sara Bine:
Yeah. It's just the downsides of that are so small because you can always go back and improve it later. Nothing is ever preventing you from doing what you initially wanted to do. Like you could build the entire complex thing, you're just doing it one small piece at a time and pausing regularly to make sure that you're making choices with intention and always working on the most important thing.
Dave Hicking:
Throughout this conversation you've talked about the idea that you can always add more complexity, it's hard to take it away. In your opinion, and I'm not asking you to speak as the official spokesperson for Tighten necessarily, but you personally, as a developer if you sort of are asked to work on a code base that is definitely not written with the YAGNI principles. Is your sort of inclination to try to like find parts of it where you can simplify and write it the way that you kind of wish it was written or do you feel like, well, this is the way it's written I kind of have to go into it?
Sara Bine:
It's an interesting question.
Dave Hicking:
I kind of sprung that one. I'm sorry.
Sara Bine:
That's okay. It depends. YAGNI, I think, is about working within the constraints of your reality. So sometimes your reality is that you're stuck with a code base that's very complicated and not YAGNI like. If you get a lot of legacy code bases that happens all the time. Like I said, it's very hard to change complex code into simple code, so the amount of effort that you would have to expend to get that code base to a simpler place is immense, but you do what you can. So you can apply YAGNI principles even in code bases that aren't full of them already. Like you get a new task and you have several options and how to implement it, you can pick the simplest one. Maybe the simplest one is still not very simple, but you can still keep the YAGNI principles in mind and use them to guide your choices.
Dave Hicking:
Is it fair to say that the YAGNI way to approach it would be to not rewrite it until you actually have? We're working on this part of the app, as we build new things or as we have to heavily interact with code that is written maybe not with YAGNI principles in mind, we're going to do something about it, but until then we're not going to touch it.
Sara Bine:
Yeah. I would say that YAGNI would generally mean that you don't want to like full rewrite an app. So you want to break it down into small pieces and basically chip away at it. I think.
Dave Hicking:
From a non-developer per point of view, whether it's the client view or you just want to say the product point of view, it can be really tempting to try to be as prepared as possible for where you see this product going 3 months, 6 months, 12 months from now and there. So, you're trying to then like advocate for building in... Even if you're not building in every future possible, it's tempting to be like, well, we needed to support every option possible. But as you and I have been on enough projects, we know that can backfire sometimes. Could you talk a little bit about YAGNI from like a client or a product owner point of view?
Sara Bine:
Yeah. I think it's helpful to think of it in terms of cost. So we established that complexity has a cost. So all that time, you're spending, building extra parts onto what you want, let's assume that it doesn't pan out because... We're talking about like worst case scenario. So if it doesn't pan out. Then now all of the time that your team spent planning, building, analyzing, testing, all of that was a ton of time and money, all of that has to be thrown away. Also, since you were focusing on building this one thing there's lost opportunity cost of all the other things that you could have been building with that time. It can be a huge cost sink.
Whereas if you approach it from a mindset of like, I'm going to build the smallest version of this, ship it, and then regroup and make sure that we're still on track with where I think this is going to go, you're almost never wasting work. At most you have to throw away a small amount of work. Also, the faster you can ship getting to market first is the significant competitive advantage. And you can do more user testing because you get the software in front of your users so you get feedback from them about how you should be focusing future efforts. So now you've maximized your value now by working on a small amount of the important thing and you've also maximized your efforts in the future because you have guided direction about where you should go.
Dave Hicking:
Yeah. I can think of few things more valuable than actually validating your ideas with people who are either using your app or who you want to use your app. I mean, honestly you could do no code, you could show them design, you could show them interactive mock-ups if you wanted to. You could show them the simplest, simplest MVP possible, but yeah, until you do that you've just made a lot of assumptions, a lot of guesses, you have no idea.
Sara Bine:
Yeah. If that's still not convincing enough, just to remember, the YAGNI is all about being flexible and keeping your options open and not backing yourself into corners. So there's nothing preventing you from ending up with the exact same product that you would've developed by tackling it all up front, you're just doing it iteratively and with intention at every step and validating your assumptions instead of trying to do everything all at once. But you can end up in the same place.
Dave Hicking:
That's actually the last question I had about YAGNI. So I do have, I guess, one more sort of mini question, which is there one thing that you wished I'd asked you about YAGNI or something else that you want to make sure you mention?
Sara Bine:
I think I really just want to emphasize that it's about starting simple and leaving room to change later because everything in the world is always changing, especially in technology. So, if you can imagine someone who maybe five years ago sat down and tried to write like PHP or JavaScript code that's future proof and accounts for every possible edge case scenario, whatever, all of that code would have to be rewritten today because PHP and JavaScript has changed drastically in the last five years. Everything is always changing. So it's not just that humans are bad at predicting the future, but it's because everything is constantly in flux. So even when you have a good idea of what might happen, maybe a global pandemic comes out of nowhere and your whole industry changes. You can never really tell how things are going to go. So, it's just about being flexible and not shutting any doors.
Dave Hicking:
Yeah. Which software is risky sometimes. The riskiest thing is sort of going deep into a hole and not like coming up for air to actually like validate that what you're trying to build is worth it.
Sara Bine:
Exactly that. Yeah, that's the costliest option is to try to predict the future and then go into a hole and work on that for like a year and then come out of it and see that everything is different now, so all of that effort has to be thrown away.
Dave Hicking:
Sara, thank you so much for talking today about YAGNI. I really love this idea and this topic, even though it might seem a little like sort of nerdy or sort of maybe inside baseball, but I think that's kind of the point of this podcast. But I think this is super useful. I really appreciate you talking about this and talking about your experience with it. For people who want to find you online in some way that could be Twitter, it could be GitHub, it could just be Tighten.com. Where should people go?
Sara Bine:
I guess probably go to my website, which is Sarabine.com.
Dave Hicking:
All right. Well, thank you so much, Sara. I really appreciate it.