Baruco 2013: Rules, by Sandi Metz

looking forward to to to a next speaker during which I'm gonna have a nap that's not true sandy I won't do that as that's a lie I have seen Stanley speak many times and on and on the occasions where I've ever spoken before after I always publicly admit that I still haven't read her book but today I want to tell you something I haven't read a book yet and and I still feel bad about today because because I haven't yet to hear a person that hasn't read that book and it said that it has an effect their life at a professional life and perhaps their spiritual life in some way because of the ideas in it sandy is an exceptional speaker and I really would like you to put your hands together for Miss Annie Matz breaking mine so doctor Nick told me not to tell him any secrets because he said he would steal them and tell you and I have to tell you that he stole my nap joke stole it and I know we're running a little behind schedule and my talk goes exactly thirty minutes so I'm going to use a just a minute before I start to tell you that I feel completely unsympathetic if you're used to having a nap after lunch and now you're here because I am missing the Vuelta the three-week bike tour in Spain which some of you may be familiar with a an American Chris winter took the lead yesterday in a dramatic finish today is the final day and they're writing right now I want you to appreciate I'm here with you instead of in the front of the TV you're welcome so rules what a great title for a talk right we love rules in this talk I'm going to give you five rules about how to write object-oriented code following these rules will improve your code the rules are important so you should always follow them and they're completely arbitrary so it's perfectly okay to break them and while I was preparing this talk I read a bunch of research about rules and rule-following in humans and why we follow rules even when we would not otherwise even when no one is going to bust us and we would not otherwise be harmed by disobeying them and I found some really interesting research at least was interesting to me about rule following which i think is even more important than the rules I'm going to give you today and so this talk is in three parts at first I'm going to just talk a little bit about rules what rules are and how social scientists define them and then we're going to switch to the technical part and I'm going to give you five rules for writing code I'm going to tell you how to write object-oriented code and at the end we're going to go and do them a little meta talked about rules which is going to give you an even more important reason to have rules okay so first what social scientists think of rules they think of rules is falling into one of three categories there are taboos taboos are things that are forbidden we think of them as unclean or cursed and they usually involve breaking a taboo usually involves some form of supernatural punishment incest visit Cebu and so is cannibalism there's oddly enough there is there are no universal taboos there is not any one single prohibited thing that is uniform across all cultures next after taboos there are laws laws are rules that govern behavior that are enforced by social institutions which are not always rational there are criminal laws where the state decides they're trying to maintain what they whatever they think of as social order and there are also civil laws where the state adjudicates between two people who are having a dispute and finally after laws their customs or what social scientists call norms norms are group held beliefs about how members should behave in a certain context an example of a group norm is that kissing thing that people do when they agree this is a police station in France where they're changing shifts this would be absolutely abnormal in America but it is probably it would probably be abnormal not to do this in France it's clear to me that I do not look Spanish because everyone who greets me either gives me a hugger shakes my hand and last night I had to ask the guys as we were leaving the dinner if they would be given a cheek kiss as if I were Spanish and they said yes and so they taught me how so I got to practice that last night which was very cool so taboos laws and norms many of them are both arbitrary and unenforceable and so the really interesting question about rules is why we obey them and social scientists the people who study something they call social rules system theory they traditionally give eight possible reasons to explain why someone might follow a rule and the research I'm going to talk about in part 3 suggests a ninth which again I think is the most important reason but here but first of all here are the first date self-interest you might follow a rule because you gain something to achieve a gain or to avoid a we want to win the trophy and so we follow the rule next you might follow rules because you want to mark yourself as part of a group the the French police people might think of themselves as the really polite group who greets by kissing on the cheek and we might think of ourselves as the group that never leaves trailing whitespace there are all kinds of ways for groups to identify themselves and regardless of how informal the rules are they delineate the group and we use them to recognize each other all you have to do look is look at that picture and you know it's us they're marked as identity they follow the rules now next you might fall you might follow a rule because it's given to you by an authority they're obviously religious authorities this is a pope in barcelona a couple years ago but there are secular authorities there's no law that says you're out but you go back to the dugout regardless groups promote authorities and then they respect the rules that they create forth people follow rules because we have a sense of order people love order we follow rules that are otherwise meaningless because they make the world seem regular and dependable we know the right distance apart to stand at the bus stop and it bothers us when people violate that rule even when it does not otherwise harm us next there are social sanctions the most obvious being prison but some rules have such built-in sanctions that we tend to follow them even when there's not a law prohibiting them sometimes we follow because of what they call the veil of ignorance we follow these rules even when we are harmed by doing so because we don't understand the consequences imagine that you have a rule accept all free things this can turn out badly and finally you might follow a rule out of simple habit we like to think of ourselves as self-aware but there are many ways in which we are programmed by our experiences in our cultures and the most deeply accepted rules are often the least questioned so we have so there you go that's rules tab laws and norms and we followed them for all kinds of reasons even when it's against our own self-interest and so against that overview of rules I'm going to give you five these are rules about how to write object-oriented code now these rules are norms they are not laws and even though sometimes we treat our rules as taboos these are not chiseled in stone and so each of the rules is actually a constraint it's a limitation on behavior the first role my first goal in writing object-oriented code is that a class may contain no more than 100 lines of code the second rule is that a method may contain no more than five and the third rule is that you may pass no more than four parameters to a method I have always regretted this rule feels like maybe it ought to be three somewhere between three and four four if if you have to pass four parameters there's definitely an object in there oh and the correlator this rule is you cannot just cheat with a hash all right don't even alright so this first three rules 100 lines in a class five lines in a method for Primus path su method they're strictly about writing a plain old Ruby code the next two rules are about writing rails code a controller action may pass only one instance variable to view and a controller action may know only two other class names now some of you probably may have heard me give this set of rules on the Ruby rogues and a ruby rogues podcast early in the spring and I misspoke on that podcast and I said one here that a controller action could no one class what I meant that is was that it could no one business class in one presenter class many people who heard that podcast adopted that role and I can tell you it it works perfectly fine and so just like maybe four parameters should be three maybe two classes should be one the constraints could beat the constraints clearly work if they're tighter and then of course I gave one final role and it's a rule about breaking the rules so you can break any rule you want as long as you can talk someone into believing it's a good idea all right so here they are five simple rules they're incredibly easy they're easy to remember they're easy to implement the rules aren't complicated but following them has enormous consequences imagine the app that was created by these rules they force you to create small objects and they bias those small objects toward PO rows toward plain old Ruby objects they you can't write objects that are bound up inside the framework you're using the rules forced each of the objects that you create to know a minimal number of other things and so objects end up with very few dependencies we don't know what the future holds and but we'd like our apps to survive it and following these rules will help they make changeable apps that are built up small objects that require little context and have few dependencies they're simple straightforward well tested code that can be reused in novel and unexpected circumstances sorry so the rules themselves that are not that special and in some ways they are completely arbitrary I I cannot make a case that says 101 is substantially worse than 100 or that 99 is substantially better these are just a line in the sand they're a mark that says come here and go no further this is the place where you have to ask the question should I break this thing in half she does this what responsibility can I chisel off into another object the rules are means to an end and that end is to reduce the cost of software if you define cost as time money or pain then what we want is to produce features at the lowest cost and I assert that the best way to do this is to make small objects and I assert that the best way to do that is to define what small means to make a rule about small and then follow that rule so the rules are to achieve a goal and achieving the goal is far more important than the rules we're not bound to these rules we're bound to the goal and we will adopt any rule that lets us achieve that goal so I think I'm right right I think small objects will reduce your costs but I I am absolutely willing to admit that small objects have a price there's a cost of their own this is a design choice and like every design choice it has consequences following these rules places a bet that you'll be better off making many small objects then you will be making a few large ones it's choosing between objects and procedures I thought it was interesting that Matt said this morning that the scripts were 100 lines long and that's a procedure right which is kind of my limit on the the size of a class here I want you know it's bad for me to stray from my script so ask me more questions about that if you want to hear about it later so so think about this imagine your application is on a continuum on one side you can have a few really large objects long step-by-step procedures that have all the code in them at the other end of the continuum there's an application made of many small interacting objects on the the very big the list of long procedures they are really easy to understand you can look at that code and tell exactly what's going on however if it's hard to change it's easy to break something else if you make a change inside a long procedure and it's very difficult to reuse part of it you end up having to copy and paste and then you have to worry about what state that stuff relied on and so the the downside the upside is it's really easy to understand when you first look at it the downside is that it's almost impossible to change if your app never changes that's a good bet but most of our apps do on the other side of the continuum you have this notion of a big pool of small objects and those small objects are clearly more difficult to initially understand looking at the source code of a bunch of small classes does not tell you everything much of the logic in that app exists in the messages and the messages don't actually happen till you reconstitute it all and put it in memory and so when you're looking at the source code for a bunch of small objects you have to construct an imaginary mental model and supply the messages yourself in order to understand what's going on messages are at the core of object-oriented design they they create seams that give you levels of indirection and they let you define objects that play roles and then use the roles as shields so that you can substitute new objects behind them messages are what gives you change ability and so we have this tension between an app that contains a bunch of procedures where you can look at the source code and be comforted because you can understand what it's doing and another app that has a bunch of small objects where you can look at you cannot immediately tell the operation of the whole by looking at the individual parts of source code on disk and I'm going to tell you now I want to tell you two stories when I was at railsconf this spring I had a conversation with a young man who had read the book he had written a couple of object-oriented apps but they were mostly collections of long procedures and he was trying to follow the pattern of creating applications that had a bunch of small objects and he tried and tried to ask me a question that I had a very difficult time understanding so he spent a long time in the hollow sorta banging heads trying to get it right and finally I understood his question to be this he said I used to write procedures and now I'm creating lots and lots of small objects when will I understand my new app in the same way that I understood the old and when I finally understood that to be his question I had to look at him and say never you're never going to understand this new app in the same way that you understood the old it's not as if having a bunch of big procedures and having a bunch of small objects are two arcing paths that lead to the same end point they don't they go different places you know so what I told them was that you will never understand it like you used to what will happen is that you will cease to care it will note it will quit bothering you after a while and to illustrate why I'm going to tell you one more story caleb who's here somewhere who works for a thought bot in Boston Mass in the US was part of a group of people he when I first discussed these rules in the spring he took them into thoughtbot which is a consulting company and they decided to adopt them on a project they were working on and uses them exclusively as a test as an experiment to see if they would help and they spent a while on that new project and it and I had a conversation with him last week to sort of check in to see how they would evaluate that experience and experience and what they told me was that they loved it they the even though the experiment had ended they work they continued to use the rules on that project and that people who had been on that team that left and went to other projects took the rules with them they found them very useful as a way to write code but I specifically asked them about this issue about the tension between under standing a few large objects versus a bunch of small ones and I was particularly worried about and interested in the experience of junior programmers how they dealt with that pool of small objects and so when I ask that question they turn the camera around and pointed at a young man named Paul and I asked Paul how do you feel how does it feel working on this application that's built of a bunch of small things and what he said was that he loved it because it made him feel safe that he knew that he did not have to understand the entire application to make a change he just needed to understand his part and he had no fear he had absolute confidence that he understood the part he was changing he could make that change without breaking something in the larger hole and that's this power of small objects it really worked for those guys and so using making this choice going going more towards small objects requires a change in perspective and many of us think of our applications as rails apps and rails has an opinion about how to organize code and that opinion is tremendously helpful it's at the root of rails success I for those of you who are old enough to remember the there was a video many years ago about make a blog in 10 minutes that we all watch that brought many of us to rails and it was an amazing it was a feat of Technology and in that you may remember in that there was a controller that knew the name of one class post and it used that class to create a single instance variable at post to pass to its view that's the rails pattern and that application was the classic rails app it was a wrapper around a database that let you do crud operations right create replace up they delete operations against a pile of data the edges of the framework the incoming message and the outgoing persistence were stuck together they were glued right in the middle there wasn't any domain logic in that app and if this is the problem you have you should use the rails pattern to solve it it's exactly right put all of your code in some classes of application controller and active record base that's the perfect solution to that problem however some of have more complicated apps they're not really rails apps they're apps that use rails an application that uses really want is one that has a bunch of business logic that does not map directly to an action in a controller or to a row in a database table and when you have that if I want to follow the pattern of how rails expects me to behave and I have a bunch of business logic that doesn't fit into that in order to use the rails pattern I have to push the edges of the framework apart and create new objects of my own and put them in the middle in the five rules force you to do that that's a way to do it shell the edges of the framework apart make small Parra small photos with few dependencies create your own objects that have your business logic and put them in the middle and so if I'm right you should follow these rules not because I'm an authority or not because you want to identify with this group or not because they meet your sense of order but because it's in your own self-interest I think they save money in your application but it turns out that there's more to it than that that rules have more value than just saving money in your application and now we're to part three of this talk the meta part about rules it turns out that rule following is the thing we humans do to send signals to one another and there's some interesting research I have a psychology degree so I'm a recovering psychology student I read a lot of research there's there's new research that that I think applies directly to our business of writing software applications it's by these two guys I can pronounce one of their names Kimbra and that other guy and here's the name of the study which it like every academic study is impossible to parse so let me just do that this is their assertion that rules screen for cooperative types and I'm going to tell you about the study has two parts in the first study they divided subjects into groups of eight and they wanted to figure out in that group of eight which which were more rule-following and which were more rule making and so they had them play this game the goal the goal here is to walk across through all these stoplights you press this button to make the little person walk he when when they walk they walk to the next red light he start out with eight euros you lose eight cents a second while you wait every red light last five seconds and your instructions are the rule this is what they tell the subjects the rule is to wait at each stop light until it turns green all right so it takes four seconds to walk from light to light and then across the end and it also those lights obviously wait five seconds so if you obey the rule the most you can keep of your 8 euro is four if you ignore the roll you get to keep six you'll have more money left at the end if you ignore the rule and so some folks play the game like this they go to the first slide they wait for five seconds and it turns green they press a little lock button little person walks they wait okay so right you get the idea here um then some other people play the game like this they just put their thumb on the walk button because it turns out the walk button works even if the lights red you won't know that unless you run this experiment okay so this is the test they used to separate rule followers from rule breakers and I can here all are you thinking that you would be a rule breaker because your programmers and your game players and you want to know if the walk button works and you would press it you would try so let me give you a different instruction let's use this is our instruction to decide if you're a rule follower a rule breaker go to the first stoplight make this change in the source code and then check it into the source code repository after removing all the trailing whitespace and then press walk yeah you don't feel like so much of a rule breaker now do it yeah so the test is context dependent so imagine that you get put in a group based on that context that test the test that's contact dependent for us and so after they did that with every individual person they took the four most rule-following people and the four most rule-breaking people in every group and they separate them into teams and they had the teams play up furtive game here's how the game goes there's four players they play ten rounds in each round they draw tokens and so the toe each player has a infinite pile of individual tokens and those tokens are worth one there's a shared pool of tokens that's capped at 360 and they're worth two in every round every player draws 60 tokens and so here's what you obviously do in the first round you say well okay I'm just everybody just asked for 60 there's enough right let's get the tokens that are worth more and this leaves 120 tokens now between rounds the common pool this common pool regenerates by a factor of half and so in the regeneration phase that goes from 120 up to 180 now the game has two more rules that I have not yet told you about one is if the shared pool ever gets below 30 it doesn't regenerate and the other is if in any round people choose more tokens to so many tokens that the shared pool would get 2-0 the tokens in the shared pool get distributed in proportion to the requests that you made all right and so let's just play one more ghetto actually let me say this so you can think of the shared pool in case you have not already thought about this let me tell you what the shared pool stands proxy for it could be a field where farmers are grazing cattle it could be a see where we're fishing or it could be an application on which many programmers work over a number of years you can over graze a field or you can over fish a sea or you can hack and hack on an app for a while and they still give you value but if you abuse them for too long a time comes when they're done they're no good to anybody and so if you're playing this game if you're playing a game where you care about the health of your app in an infinite number of rounds and you trust your fellow players when there's after choosing 60 tokens in the first round here's how you play around - you do this math there's 180 left well I can't get into the bottom 30 so I have to take those off I'll just divide that before that because that's only fair 37.5 I got to round down so I'm going to pick 37 and sure enough there we go so there's a Nady ready if everybody takes 37 here I'm like having a little let's do this there we go everybody gets 37 we end up with 32 the thing regenerates we get 40 a etc so you can see that co-operators people who want the shared pole to get maintained and definitely rapidly devised this formula if every player chooses this in every round that the shared pole rapidly decreases so you'll only get a few in every round but everyone is better off if you keep the pool together if the pool survives and so you pick what your share is every round it totally works alright so remember we did that pretest we separated to have two teams of followers and breakers they had them played this game here's what happened the groups of rule followers were four times more likely than rule breakers to cooperate to keep the pool alive in addition it was clear they when they failed they feel because they couldn't get the math right under pressure all right there and they didn't let them talk and so the rounding issue is a problem like if you round up and everybody rounds up then you get across that 30 boundary but they did statistical analysis on the draws that they were making and they they meant to do it in the and it had they been able to haven't been able to communicate they would have sustained the pool forever the teams of rule breakers consumed the common resource almost instantly and by their choices mathematically you can tell they're not even trying they are over harvesting dramatically it's as its as if during each round their mental calculation looks like this so one thing they measured in the study was something they call reciprocity sorry I have a hard time saying that have been practicing all morning reciprocity and it's the tendency of someone to in the next round do what someone else did in the prior round and it turns out that we're height the choices are highly reciprocal and this is great if everyone's mats right if if everyone's nice and we're all behaving reciprocally then niceness has a tendency to be maintained however in these groups where their player who have bad behavior not only do they behave badly but then they all reciprocate the bad behavior and they have this amazing race to the bottom but so this is interesting but of more interest to us is they repeated the study and they used mixed groups they made groups that had some rule followers and some rule breakers and these groups behaved like breaker groups and the authors theorized that it's because of this quality of reciprocity it's as if there's a round played where someone does that and it just pokes everyone else in the eye and in the next round they do this all right okay buddy they they go they behave just like breaker groups the breaks that have one I'm yeah a break a group that's mostly rule followers that has a single rule breaker rapidly degrades to this and so here's what the authors of the study say about this they say that in mixed groups this will always be true that having one rule breaker on a team will inevitably cause it to exhaust the shared pool and by extension over graze the field or over fish the sea and I hesitate to take this analogy all the way to software development but I sometimes wonder if I should so they also say that the only way to avoid this problem the only way to avoid the inevitability of mixed groups over harvesting the resource is to screen for rule breakers and preemptively exclude them harsh I know still it's useful it's a useful analogy and it gives me words to think about the problem of not having everybody on board on the team and I think it will help me think about this and so a reprise in light of that study what are the consequences from of my rules well they still bias you toward small objects and pole rows and away from dependencies but a willingness to follow rules any rules any agreed-upon set of rules that are constructed to achieve a common goal it sends a signal of willingness to collaborate this means that you're a person who will do what it takes to maintain an application over time and round up round after round no matter what the future holds and as so as they say will screen for cooperative types and these are just the types with whom we want to work rules matter technically and socially they're restrictions right they're restrictions there are alarms that go off that tell you it's time to stop and think they force you to make small objects instead of writing big procedures and they force you to keep your business logic out of whatever frameworks you're using the rules on fixing stone we don't care I don't care what the rules are what I want is the good thing they give you we want cost-effective software and I'll adopt any rule that gives me that if you're an experienced programmer just make your own rules I don't care just make them any rules the point isn't my rules it's the belief in some rules and the willingness and self-discipline to follow them but if you're a novice if you don't yet have enough experience to make your own rules follow these do it it will improve your software you can break the rules only under the supervision of a trustworthy person that has more experience and how do you find that person well they have rules and they're sitting all around you right now sending signals by following them thank you I know it like first of all you were saying about you know you can break the rules we got valid reason cetera and in your book you talk about dividing responsibilities into modules and roles etc and it's kind of similar to like DCI and you know Jim Kay's clean blue book and he talks about putting the modules inside the use case and of course that kind of brings your total number of class lines over 200 and it's harder to test but his point is that that's a kind of logic to be self-contained so what's your kind of view should he have them the roles separate from things that you see I'm kind of a hard-ass about this okay you make a module if especially if that module is only used in one class you're deciding something code for me that belongs in that class and it counts against your line count okay sorry just is should be smaller than that try if you try to do if you try to solve the problem with smaller pieces and use that count against you I think you'll like the software you get thank you so math this morning talked about how he design Ruby to give the programmer a lot of freedom and it seems like some programming languages have sort of rules where ruby has freedoms matically type language doesn't let you change the type of something after you initialize it but in Ruby you can do that and I wonder sort of like would it be better to have a programming language that actually enforced these rules at the language level like why use such a language that gives you so much freedom when you're gonna then place these rules sort of on top of that that freedom and sort of take your own freedom away I would be better to have a language that constructed you I hate the idea that constraints give freedom I've always found that that gets me make the hair of my neck stand up whenever I heard that hear that phrase and I hate people giving me rules and so I would I am a deeply dyed-in-the-wool dynamically type text small talker and I want the freedom to do whatever I choose whatever I think is the best for my application so I I would never consider trying to enforce these limitations on people I initially made up these rules because I was helping out a group of people that had gone way far on the other side so they had thousand line controllers 1,500 the line domain models and so I tried to construct a set of rules that would push hard on the other side of the teeter-totter I I since found that folks found these rules useful it's interesting to talk Caleb wherever he went when I talked to this guys last week they talked about how much freedom they felt by having these rules it freed them from thinking from making a whole class of decisions because it just told them when they had to start thinking and so I would I would never try to enforce these rules on people but I am willing to entertain the idea that perhaps there is some freedom in constraints not because my personal experience is that but because people keep telling me they're using it that way my biases towards small objects I just do this naturally in my code there's almost nothing that doesn't meet these rules so it's it feels like the right way to write code not a limitation on code

Channel: Barcelona Ruby Conference

Views: 27,534

Keywords: baruco, sandi, metz, barcelona, ruby, conference

Id: npOGOmkxuio

Length: 35min 28sec (2128 seconds)

Published: Sun Oct 20 2013