My name is Kayne Bacigalupi. My last name is Italian. That means that I'm supposed to be having a siesta right now. But I really love this subject and wanted to come talk to you about it. And the bottom, you know, like that little byline says, I'm a fixer-coder teacher. The reality is I've done this combination over the last, like, seven years of going back and forth

between consulting and being a rescue CTO. And so I've been, like, doing these trajectory starts and then the trajectory kind of rescues. And right about now, I'm feeling like a Greenfield project would be really great rather than rescuing another Brownfield project.

But I wanted to, like, get across, like, everybody, everything that I've been learning over the last seven years soon and now so that people could learn from it. So what is this? So what is this Evergreen thing that I'm talking about? And yes, I made it up.

And I made it up so uncreatively that it's probably already out there is something that you've heard of. So in the industry, there's this talk about Greenfield projects and Brownfield project. And you can see kind of from the illustration what's going on. Greenfield is new and fresh and everything is possible. And Brownfield is like, holy crap, I cannot do another point because I have, like,

sunk myself in the oblivion of, like, tech terribleness. I'm sorry, my stuff is not working that great. So Evergreen, like, my definition of it is, first of all, you have to have a long-term relationship

with your project, which I think is pretty rare. I've had the luck or good fortune to work on two Evergreen projects. One, I was an architect, and one, like, I revived, like, a terrible Brownfield project and worked on it long enough to see it go Evergreen again. But, like, one to two years, and then it's easier after that period than before.

And the reason why is because we actually know more about the domain than we did at the beginning. And so one of the things that goes wrong with projects is, like, at first you know nothing, and then you're building on top of that nothing. But at some point you know a lot about it,

and you want to go back and just, like, fix all the mess that you made. But with an Evergreen project, what you see instead is that you know this domain, and therefore you can build, like, abstractions that will quickly convert, like, features that happen very often in your product into the real thing. And also, that on a deeper level,

things are decoupled enough that when you do this massive product or domain reimagining, it's relatively cheap. It's not, you know, as cheap as, like, one of those, you know, like this expected feature kind of thing, but it's pretty cheap. So why do fields go so round?

And they do, right? And it's because that thing I was talking about, about the domain, everything that we believed is actually false. And so a couple things. One is the product changes. And, you know, like, I remember when I first started doing development with teams, I would just be like,

there would be two things that I'd think. Be like, this time I hope that product doesn't screw this up. Because I've got it perfect, and if they just stick in line with my technology, it's all gonna be good, right? And the other thing that I would think is, and those other developers, they'd better get in line, too, because everything's working out. And then inevitably, everything would not work out,

and it wasn't necessarily, like, those other people, it was very often me, right? Because the reality is, like, everything that we believe at the very beginning of a project is absolutely and totally wrong. And our instincts are to stop everything and rebuild. And our instincts are wrong, right?

Because this is what happens. Like, you end up, like, building a brownfield project a second time around, because the reality is, like, what you don't know about the future is just as unknown. You know about the past now, and you can rebuild it. But you don't know about the future.

And so, now is when I start inventing things. This is my invention, the law of optimistic rebuild, which is an unchanged system, or I'm sorry, an unchanged team will build themselves into the same legacy problems, which is kind of like that, you know, those two images that you saw at brownfield,

and then brownfield again. So, my daughter, my youngest daughter, she's 11, and she's really smart, and she's been getting by with ADHD being really smart. But she's gotten to this place like in middle school where she's been following the instructions, and like her counselor has been like,

here's what you need to do, you need to underline things. And she's taught us to teach her to underline things. And so, it's become this weird practice where I'm like, underline the most important, you know, like, parts of this sentence, and you find out really interesting things, even if you don't have ADHD. So, one of the things here is that the unchanged team part. So, there's some kind of implication

that you need to change the team in order to change the process, right? And then there's this rebuild thing, and the rebuild thing is a little bit ambiguous because if you do an extraction to kind of rebuild, that's a rebuild too, you haven't like rebuilt the world from scratch, but it is a rebuild. And then there's this legacy problem thing, which is probably the most known thing there, right?

So, to distill it down, unchanged teams rebuild legacy problems. And you know, because I'm inventing things, and why not? I'm gonna give you a corollary, which is, it is a waterfall process

to rebuild what you already know. Which means that even if you did Agile, it's gonna take three to 10 times longer to rebuild it because it's waterfall. And more than likely, your business can't sustain that kind of thing.

So, why does Greenfield feel so good? I mean, to me, like when I start a project, it feels like the beginning of a relationship, you know? And you're like, oh my God, I'm so in love, look at this, it's all perfect. And I kind of alluded to this fact that it feels like anything is possible, and if only things don't change, things will be good. And so there's this rocket start,

there's like this amazing velocity trajectory, you're starting something new, you feel like a hero, you know? And I've been a consultant in a lot of situations like this. And that X, you know, in the velocity graph, that's where you get out, right? As a consultant. So where does this velocity come from? And it comes from borrowing.

And we need to borrow. And I want to say like right here that this is, like for me, this is kind of a phenomena that I've been seeing growing since I got into the startup industry in 2005. Because I used to work on projects that existed for a very long time, and were like, I was one of the only developers

and they were database projects of some sort. But now everything's kind of squashed and accelerated and there's this need to like, rapidly through the startup industry, jump to like something that is like fabulous instantly. And so we're borrowing a lot of stuff. And it's good to borrow that stuff. And we're borrowing from the standard library, we're also borrowing it from gems. And we think that we're getting code,

but we're actually getting a lot more than code. We're getting architecture. So if you think about any framework that you use, it comes packaged with architecture. And I'm like not talking about Rails or Sinatra, I'm talking about Event Machine versus Celluloid, right? You've got a service that's like over there on the side being a nice little microservice processing images.

And you have to make this choice, right? Which direction am I going? And that's an architecture decision that's gonna affect and impact like all the code that falls underneath it. But it gets even more complicated when you start to look at Rails engines or other libraries that come packaged with like a ton of domain, right? And product.

And then you're very tightly tied to whatever it is that you borrowed. So there was an article, it was about a year ago, an article, I mean blog, and it was on Code Climate, which is an excellent, excellent, excuse me a second. It's an excellent, excellent product,

and they write great articles about software design. And they coined this term. I think they coined this term. I think they're like me and just making stuff up, called technical drift. And it's worth thinking about. It's like, and this is their quote, which I think is awesome and a little bit harsh. It's a phenomenon that occurs when a development team continuously,

this is the harsh part, continuously fails to recognize and adapt to change. Because I think it only takes a little bit of failure to get to Brownfield. Causing the concepts in the software domain and the concepts in the code to start to slowly drift apart from one another. And then you get to technical debt. And the technical debt has interest,

and the interest compounds, and very quickly you are not in a place where you can do anything. So if you look at the adjusted velocity, the shaded part is kind of, have you noticed that I've got graphs with no numbers? Isn't this awesome? I can make anything true here. So the shaded part is borrowed,

and the rest of it is what's actually earned. And a more realistic goal is, yeah, there's a lot of graphs here, is a linear progression that your velocity doesn't change over time. And I just want to say, it's a really hard thing to achieve. It's like, and so the goal,

like I think in people's heads there's like, oh, that initial velocity, I just want to find a way to harness it and have it forever and just like, boom, I'm a rocket forever. And the reality is just maintaining the velocity that you have is an incredibly hard thing. And what you see here with the multiple lines is like scaling it with developers. So you start with like set number of developers, and then with each one you add like a linear,

hopefully, amount of velocity. But what you tend to see in teams is that it's got diminishing returns. And the brownfield progression looks more like this. There's this initial like amazing velocity. And then, you know, the consultant leaves. Yay, feeling like a hero.

And actually the team feels like here too, like, oh my God, we have done so much. And then when things start to not go very well, they think, oh my God, what is wrong with me? And they don't think like, holy cow, I now have to pay back all this like debt and stuff that I have borrowed against. And then the second moment, like that second X is typically like where I come in

and there's like, there's so little movement, it's so hard to get anything done at all, right? And the reality is like the total number of features is the area under the graph. And like, especially with startups, I'll hear people saying, well, you know, I just have to prototype it. I don't need to test it. I don't need to design it well. It's okay if there's a 300 line method

in the middle of my controller. It's all fine because this is a prototype and then they outlive their prototype and they're like, oh no, we're making money. What do I do? And the reality is like way before they got to that place, there was a moment when the payoff like switched, right? So there's a moment when like this flat kind of

unglamorous trajectory of like persisting velocity like ends up being a much better benefit than that like massive debt incursion and then the plummet that inevitably comes. So now I'm gonna make up more laws. This is the law of software stages.

And this is essentially saying like maintenance is not the same thing as launching and there have to be different rules. And the corollary is that treating maintenance the same as launch will lead to diminishing velocity and that technical debt thing.

So what are the maintenance best practices? Well it turns out like this is like well known and also hard to follow. Like I just have to do a call out to Jim Weirich who died this past February and it was a sad moment for me even though I barely knew him. I met him once 2009 at a conference here. Actually not San Diego but like Ruby Comp

where I was speaking for the first time and there weren't that many women and I felt like a little odd and at some point he like walked over to this small cluster of women that was like just standing there going I don't know if we fit. And he was just like hello and he had just given an incredible presentation on Solid and it was just like he was such a mensch

in addition to being like an incredible educator and you know the designer of Rake and various other things. So let's talk about Solid. And I'm not gonna do as good a job as he did. So 2009 you should look it up on Confreaks for RubyConf. So single responsibility.

So the irony here is the single responsibility actually has two definitions. So each class should have one responsibility and believe it or not that's not as specific as the second definition which is each one should only have one reason to change.

And so what that means is that you have this code scattered all over the world and each of these things could really have one responsibility but the code is still spread out everywhere. And then like what the second statement means is like all those things should be one object, right? So that when that domain need changes it's in one location.

So let's try and apply this to my fake code example. And yeah it's a cartoon because it's easier to take part than like a 200 line method. And I'm really gonna take this part. So there's at least like two vehicle like objects in there so we know like we can just be like

single responsibility, no not here, right? But like trying to figure out how to get to single responsibility is its own like kind of beast. Like okay there's a car and there's a tank and there's a slug in the middle. Maybe the slug's responsibility is trying to like glue these things together and that's all fine except there are these other things that are kind of worrisome, right? We could extract like two objects

except there's these worries like those bumps on the top of the car which is bottom of the car. Is that like gonna become the rest of the tank? Is there gonna be one like big circular tank universe? The stuff coming out on either side of the car. So the car is kind of an issue, right? Could that be like in some way like smoothed out so it's a little bit more symmetrical

and we can like build some interfaces off of that? But truly the most worrying thing for me about this image is the face of the slug because there's this implication that you're starting with like this object that's deep in the mechanical like universe of this app and then it like goes out to the user interface and it's like hi.

You know what I mean? It's like oh separations of concerns, not there at all. So I don't know what to do with this object. This one's a little bit easier and it's still troubling, right? And in terms of single responsibility, not gonna help us much. All I can say is nope, not there, right? So let's try and tackle it from the oh point of view.

Open, closed. This is open for extension and usually that extension means inheritance. Closed for modification. So what that kind of implies is that I should be able to take this object and inherit from it and change the behavior in the ways that I need to. So let's explore with that.

So I would like in this case to have more legs. Same amount of tentacles, more legs. Okay, cool. All we have to do is extract out of that 200 crazy method everything relating to appendages. So we're starting to have like a sense

that there are appendages here and we like extract out appendages and we've got a place that's creating all this and then we can override it. And if we're really good, we use the template method and we like create these hooks inside that so that we don't even have to call super or anything crazy like that and all the original appendages get built and then the new appendages get built

and everything's really good and then I only want two legs. Or like two legs and two tentacle-ish things, right? And then I've got a Liskov substitution principle. I gotta tell you when I talk to my team of junior developers, I'm like, oh that's a Liskov substitution problem. Like it doesn't go anywhere, right?

But like what it, oh wait, let me show you the definition and this is why it goes nowhere. It's probably the easiest thing of all these. It's like the least fuzzy and therefore it's the most mathematically specific which makes it really hard to understand. And so if we get to what it really means is

this is the violation, right? There's more specificity in the parent than the child and this is what it looks like in the animal metaphor which is, I don't know why, the thing that everybody uses to explain inheritance. Now I have never worked on an app with animals

but somehow, and I use a lot of inheritance, probably more than I should according to the luminaries but never done an animal. You can see that the proto-animal is this crazy thing with wings and a beak and so on and so forth and then you have to remove stuff in the children.

It's supposed to go in the other direction so that you have some very simple base and things there. So we can switch the inheritance, right? And then we're back to Liskov positivity. And then we get to interface segregation which is about kind of defining, yeah I don't know, this is like vague. They're all kind of vague

and that's kind of a problem, right? But essentially what we're looking for is these appendages, they all kind of act the same except for that one that has a mailbox on the end of it that's really troubling. We're gonna have to find someplace elsewhere. I don't know where it's gonna go but we've got two kinds of appendages at this point. Maybe we're gonna have more kinds of appendages.

Maybe that's what's implied by this crazy monster and maybe they do things like expand and contract and move to the left and move to the right. And we can build that interface and that's gonna lead to like some kind of monster kind of thing where we're passing those things. Like this is the moment to extract those things

into classes, awesome. Now we've got like 150 lines or something like that that puts it all together and we get to D and hopefully D is gonna solve all our issues except it's very vague, right? Dependency inversion, you should depend on things that are like more, less changeable.

I don't know like which is why like very often that gets implemented is dependency injection. So I don't know what I'm gonna need but if I inject it then it can change. That seems pretty fair and so then you end up kind of like with this kind of an object where like you have this core, God knows what

that's still not single responsibility and you pass in all these appendages and they do what they're supposed to do, right? Who knows? But this still isn't single responsibility and it's like kind of failed us. So what are the goals of Solid? It's to help us to respond to change. And the thing is it's not very specific, right?

Which I was kind of saying over and over again and the rules are tightly coupled. So when we went to dependency injection we lost all the inheritance and we were now like delegating, right? Which means that like two of those methods were just like dropped off the thing and we can no longer use them to kind of help us like manage all the complexity.

And the other thing is that the single responsibility and the dependency injection, they were like more theoretical and not so motivated by like changes in the product that we could like go, oh okay, I'll do this. At least this particular crazy product. And so I think there are really great guidelines if you already have like instincts about it and you already know it.

And if you don't, you know, which is more and more the case in my life, it's not so good. Which is sad, right? So what can we do instead? We, you know, like my sense is like we need something much more specific.

So I made some more laws. Your team should have solid design expertise. But it doesn't have to be everybody on it. And if it's not everybody on it then you should have a solid teacher. Which is not necessarily like implied by the expertise. Some people don't like to teach. And the people that are learning

need to be willing to learn. And the corollary, you know, is about your learners. So what we need is something that's actionable for everyone on the team. That's kind of reasonable. So what else can we do? So has anyone seen this funny?

Oh, you are on the spot, Sandy. This guy I used to work for, Jeff Dean, he was at Pivotal Labs and he worked on a project that lasted there for seven years. Which is pretty mind blowing because they're in the business that I've been in sometimes too where you're like, boom, rock it off. And then you're like, okay, have fun with that, right?

But this was a seven year project and so he invented this bumper sticker. At least that's what he told me. Maybe other people invented it too. What would Sandy Metz do, right? Like how are we gonna deal with like the maintenance, the ongoing maintenance of it? And so here's some actionable stuff. Hire Sandy, she's available and embarrassed and in the front seat.

So when you want to just go over there and be like, I'm sorry, I'm not gonna listen to this jackass anymore. I'm gonna go talk to you. So, but the other, if you can't convince your managers to hire her, which I should say, my last rescue project, we had a consulting budget and it wasn't even something I was thinking of but I was like, okay, she just wrote a book. Let's bring her in.

And I was like, it'll be another person that can help explain like why their instincts are just not so good. And what I didn't expect to get out of it is the sense that this is very teachable and I think it took it a lot farther than she actually intended because I came up with my own stuff. These are her rules, by the way, and I'm gonna leave it to an investigation

of your own stuff. Like she came up with these rules and this is a source of like both pride and embarrassment while she was working at like our little consulting gig. So the thing that was really cool was like after a year of kind of like plodding through this mess,

we got to this place of evergreen and I was like, awesome. I feel so good about myself. I feel so good about my team and most of them were junior developers and there were like one or two senior people and it was great, right? And then we had Sandy Metz come back after a year. It was almost exactly a year and what I found out is

we were not doing what Sandy Metz would do. We were doing something else and it was crazy and like we found this out because she was doing these exercises and one of them had to do with dependency injection and she just kind of like built this road and she was like, okay, and the conclusion is you do dependency injection and she set them all loose and they went off and did God knows what

and we were sitting back watching and she's like, I don't know how to reign them in. You know these people better than I do. What should I tell them about like dependency injection to get them to go to that conclusion? And I was like, I'm not sure because the reality is I was doing something else with them and this is my law of STD sub two

and it's like a large group of junior engineers can practice this thing that I'm gonna tell you about with just a little bit of solid expertise and they can get to everything. So small and I went smaller than Sandy. She was like, here take these rules and I was like, no, no, we're gonna go even smaller. So we did and what that means is like on your screen

like when two people are pairing and editing this they can see absolutely everything there which takes away a lot of pain and also forces like greater granularity, right? And test drive it too. I had an internship program where I was teaching people who didn't know how to code at all how to code and there was like a lot of resistance from people

that had coded for a while about teaching test driven development. So what I would do is I would just be like, oh, that's a nice spike. Delete everything and start again with tests and they would be like, what the first time? And then after that they'd be like, oh, okay. And what would happen is you, I mean it goes to that interface part of solid. Like you're writing out before you get to the code

like what you expect, like what the contract is and it leads to like everything that you could hope for from solid as long as you have like somebody solid coming in and going, not single responsibility there. D, there's two Ds like the sub two. Dependency and jacked, I just removed the inversion

because it's kind of confusing for people and law of demeter. So only talk to your neighbors and leave it to your neighbors to kind of like encapsulate what they're talking to you. And one of the big like kind of risks in there is like all that like checking for nil that can just like percolate all the way down your app in Ruby. And actually that's what I was thinking about with the Matt's talk this morning

that the real typing issue that I see is like that nil versus the thing I expect and you know the no pattern can take care of that for you but whatever. So then there's like a whole bunch of other stuff that we were just like, we'd be like, oh problem. Let's kind of construct like a rule for our team about that. And most of the rules were about Rails.

So like an example would be don't put anything in your model at all because if you put anything in there everybody's gonna shove everything in there. So put it somewhere else. So we had like these query objects whose job it was to just maintain all the queries. So the relationship's really the only thing in there. It's not like an ideal situation for a bunch of senior developers

but it worked good for this team. So problem solved, right? Yeah, not so much. The reality is rules don't make code. It's the people that make the code. So getting back to like this internship like there's a like really peculiar problem.

Well, let me hold off on that for a second because like Sarah May like did a great talk at Fluent where she brought up this law that I did not make up. So here's the first law that's a real law except for the law of demeanor. And it's Conway's law. And it's a little inscrutable too.

Organizations which design systems are constrained to produce designs which are copies of the communication structures of those organizations. So what you usually hear as the example for this and I think the reason that he came up with this is you take a whole bunch of engineers and you say we need a compiler and then they divide up into four groups

and you end up with a four pass compiler because they're talking to each other in the way that their systems run. And so anyways back to the team and code like you can kind of start to see where some of these crazy objects come from, right?

Because code is about communication. And I didn't really realize this until I started working with other people which is a weird thing to say. So I had like these you know before my life in web I was doing databases and I was working on like government, education, nonprofit kind of like

database things that you know like they had no other opportunities to build these massive applications. And I would have these ongoing relationships and the projects were pretty evergreen given that they didn't need a lot of product change, right? And also given that I was the only one I was communicating with. So all I needed to do was build out

you know what am I gonna understand in three months when they come back to like tweak this? But as soon as you start coding with other people you're dealing with a communication issue like is this the most clear to my whole team? Which is usually not true initially and so you have to like come up with this group kind of ethic which is why

these rules are really important. So what do you do to choose a team that's gonna work well together? And this is like the hard fuzzy part although I've not made any laws but I did make some kind of bizarre metrics that I wanted to share. So what happened is I had this internship program

we put six people through it in groups of two pairs. And it was a great internship program actually it was super successful but there was this weird problem which was how do you hire for people to code and be great coders that don't yet know how to code? That's like a weird problem right?

Cause usually and it's a false kind of false sense of security like the things that we do to test coders for how they code is we make them do these weird intellectual puzzles that they don't do in real life right? And so like that's a possibility you could like put them in front of a white board and see if they've read that like

technical interview book. But not really effective which you know Google admitted last year thank God right? And so like we started to come up with these metrics and as it turns out like communication was like top of the mark and enjoyable

which is like a really weird one right? You don't wanna think like well I actually care about how enjoyable this person is but I'm not talking about like I wanna go out for beer with this person. I'm talking about like I wanna sit down and figure out and collaborate on this project together. I wanna figure this out with this person and I'm willing to do it.

Cause if you dislike kind of working with somebody to that degree like there's nothing good that's gonna come from you know like this. The organization is really gonna fail on those little problems right? Little problems that are actually huge in the code. And so there's a point that I wanna make in this

and the effective stuff in general which is like there's like the possibility of squashing diversity in all this right? Like you can go in this direction of like oh shit this is not good we need monoculturism. And I'm not suggesting that at all which is why it's really like do I wanna collaborate with this person versus do I wanna go out for a beer?

And it's really different. And then the other thing like the last one there last one on this slide I have another one that takes up a whole slide cause it's so weird is motivation. And so like what I was always looking for is proof that like that this individual was trying to educate themselves because you know we want people that are like hard driven

and I want people that work a sustainable pace right? But I want people that are like driven to their own education. So the last one that takes, the last metric that takes up like its own slide is self-ware and it's a weird metric. And actually at some point the company that I was at

took these metrics and started applying to the rest of the company to sales and marketing and you know like program management and all sorts of stuff. And this wonder of the CEO crazy and you just dropped it. But it's a reality and very often when we ran into problems we'd be like

oh this is a self-awareness problem. And so it's like this fuzzy generalization almost like solid principles that you kind of know it when you see a problem in it. But it's so there's like a couple things learning style right? Do I know how I learn best and can I teach myself? So that's in there. Do I know my environment related to that learning style?

Do I know my environment to like set you know kind of like a path through it? Impact control and then I'll get up to the top one. Impact control is really about like do I know how my behavior is impacting other people? And that's kind of like a big deal right? On a team.

And so there's a lot of people with some level of autism in programming and that's you know kind of like this impact control thing like can I see beyond myself? And just general geekiness is like a kind of narcissism where everything is reflected back. You can take on those people and I love geeks. They're so cute right?

But you just have to know what you're dealing with and as a team you have to be able to just be like keeping that person or people in control right? And just be like I know you didn't mean it but when you said that you sounded like a jerk for these reasons right? And so maybe you should say it this way. And actually like I had very low expectations

that that kind of dialogue could go well and that actually you could talk to anybody about these metrics and be like you're not very enjoyable and you can't actually say that, you can't. But you can coach somebody to you know the way you're acting people aren't wanting to work with you and it changes and I had a really like I was just for a month I spent

teaching at a boot camp and there were like two people that were like just having profound arrogance problems and like and also one of them was having like that autism kind of spectrum thing and didn't realize he was going through the room alienating people and it took very little. I mean kind of an argument with both of them but it got them on track. It was hard for me, good for them

and it's possible to like really like get people on track. And so the last one is actually the first one is imposter versus arrogant and actually like when my team came up that the arrogant wasn't the word they used. And you know a little bit

and even a medium amount of imposter is like fine that's like humility. Like I feel like I used to have imposter syndrome and now I'm kind of in that other direction which I got to work on right. But too much of it and it's really hard to like promote that person's own personal growth.

Like there's a like again it's like one of those things like you take it on and know what you're working with and how much management resources you want to devote to that. The arrogant thing like I was saying it's possible to like bang somebody into shape on that and it really depends on the people which gets to you know like

this is all for regular you know garden variety people that haven't coded before like how to figure out like are they going to be good? And so what are the metrics that we can use for people that actually know how to code and that's like a totally different thing right. And so we use the same metrics in the end

because it turns out it was really good for knowing whether somebody was going to participate well on the team which was like significant and important. But there were two additions and one is design like so if we work on a refactoring problem together which is pretty important if you have like a brown field thing that you're trying to convert to green field or if you just want to stay in that evergreen state

how can you handle this you know duplication this mess this disaster right. So design would be in there and design with refactoring but there's this other element of faith and this is where my talk completely disintegrates and I'm going to leave it on you to go off into the world and figure this out because like what the hell with faith right.

Like there was actually like originally like a whole section of this talk that I cut out thank God for you too that was about orthodox Judaism and what we could learn about like learning and about like following and believing and having faith and also changing the whole system like changing the religion actually

but I took it out because it's a little bit bizarre and I don't know where it goes and also like I went back and I talked to somebody that I used to work with and I was talking to him like really passionately about like you know like this and then there's the Talmud and it starts with this tiny thing and it's in the Torah and then they make a then there's a mitzvah

that gets attached to it and then from that mitzvah you have this tiny little like kernel of truth that gets put in the Talmud and then there's like this like you know tree like rings around it and you know you're like and if we had that for code right like and any time that you were working with an octopus the tentacles shall each be their own class right

and then somebody else comes along it's like no no this one time I was working with an octopus and the most important thing were actually the suction cups and so that should be its own class and everything else can be like subordinate to that and like this whole like Talmud of like solid design principles and stuff like this and he just looked at me like I was crazy it was like I don't know what you're talking about

I think that people are just bored and that's why they go outside these rules sometimes and that was actually the biggest problem that we had with that Evergreen project is like people just going yeah yeah I want to do best practices but why can't I just write my like 200 line method that worked fine for the rocket start and it should work fine now so I don't have an answer to this one

this is you know like a couple slides back is where my real talk ended and this is like what I need to put out to the world like go solve this please right because hopefully I won't be doing another you know brownfield revival for at least a year I kind of need a break and so to sum it up

for going Evergreen you need to have some solid get some STD sorry and you need a great team and that's all I've got except I can answer your questions and also like if you want these slides even though there's no code except the weird cartoon monsters it's like I tweeted it out earlier today

right before the talk