00:00:12.559
hi welcome i'm is joe masse we're going to talk about horrible terrible no-good
00:00:17.760
codebases i'm can i get a quick show hand who here is dealing currently with just horrifying code at work yeah
00:00:24.510
awesome so it's pretty much a support group if nothing else i'm so I've worked
00:00:30.150
a lot of different companies over the course of my career and this has really been one of the common threads across
00:00:35.250
all the companies that work at I guess I'm fortunate enough to work in places that are very profitable but the results
00:00:41.280
of that is that they're usually places that have just terrifyingly bad code and so we're going to talk about a lot of
00:00:48.510
different things I want to start off I'll give you an example one of the code bases I'm working with because I'm going to use it as an example across the
00:00:53.850
entire talk this was some place I was working at when rails 4.1 was being
00:00:59.250
released the code base I was working with was rails 1.2 we were actually
00:01:04.350
super proud of being at rails 1.2 because we'd actually started at 0.7 I managed to wake our way all the way up
00:01:10.320
to 1.2 fantastic and I had a lot of the characteristics that you know you're probably thinking about for your own
00:01:16.320
code bases we had custom packages somebody decided that they should write
00:01:21.330
their own lib SSL changes which meant that we were running our own Postgres
00:01:26.930
system libraries you know pretty nasty stuff we had a 6,000 Lyon user model
00:01:33.200
fantastic good news is that everything was in one place the bad news is that everything was in one place on the test
00:01:41.640
we took four days to run on a laptop
00:01:46.729
with a little misleading because of course if it takes four days to run your test suite you don't run your test suite on a laptop so we we actually paid you
00:01:54.720
know five figures worth of AWS bills to run across hundreds of machines we got it down to four five hours before you
00:02:01.890
could see whether your test path and then when it did pass about 10% of the tests flapped is there one no to
00:02:07.469
flapping test is when I say that some people do alright so flapping test is basically any test where
00:02:13.400
it passes sometimes but not all the time so like 50% of the time it's green or
00:02:19.879
30% of the time screen or the green unless it's like a Friday at the end of the month and so every time you got your
00:02:27.170
test run back you'd have you know sorry between 150 and 300 failing tests but it's not really certain which tests they
00:02:33.049
are we had about a million lines of Ruby so it's probably more accurate to say this wasn't a rails app this was a ruby
00:02:39.799
ecosystem with a rails app hiding somewhere inside whoa all right and so
00:02:45.920
we slide reddish into it so we did it exactly what you would do in this situation any time right we we declared
00:02:51.890
the entire legacy code base as deprecated we split off 30% of our team have them build a brand new copy of the
00:02:59.030
codebase decided that a year from now we would completely tear down the old code base and be done right it's going to be
00:03:04.819
rails 4 it's going to be you know microservices it's awesome and it went exactly the way that you would expected
00:03:10.370
to go right yeah sort of successful rewrite here the show and they would
00:03:16.430
actually deprecated the terrible code base before I don't see one hand two hands nice all right
00:03:23.000
so yeah it happened the way that you would expect 18 months later we had the new code base which we had managed to
00:03:28.730
move about 10% of the revenue on to it so we couldn't kill it because now it was actually making money and we had the
00:03:34.370
old monster that continued to make all the money all right and of course everybody really wanted to work on the
00:03:40.489
new code base and you really can't blame them right the new code base is where all the more interesting code happens
00:03:46.819
you know things that took us two weeks to do on the old code base we could do in just a handful of days on the new code base but the challenge here is of
00:03:52.970
course that we have to continue running the business right our requirements are still changing we couldn't actually
00:03:58.040
freeze or or in our hubris attempt to deprecated the entire thing we had to keep updating it and so this is a big
00:04:04.699
challenge right and I became really interested in this topic because we did
00:04:11.269
this to ourselves at some point somebody went into a class file that had five thousand nine hundred and ninety lines
00:04:17.870
of Ruby in it I decided that the right thing to do was to add ten more lines of Ruby right and you know better you know
00:04:26.450
that you need to have two hundred methods in one class you know that that's not the right thing to do and we made that decision
00:04:32.190
anyway and I wanted to understand why because I mean first of all because we
00:04:38.370
were about to build a second monster and because this this to me is like such a
00:04:44.550
common thing that I don't really understand how people who have all of these skills who have you know you go
00:04:51.630
through refactoring courses we spent years on this and yet you make these really bad decisions you keep adding
00:04:57.080
barnacles upon barnacles until we get it completely untenable code base and so I
00:05:02.490
was working with a bunch of developers on this codebase and I basically sat down and started to ask like you know
00:05:07.560
why is it that we don't split out a little bit of code and I got responses like this can't even tell what codes in
00:05:15.480
use anymore right anytime you have two hundred methods you go into an object you delete a little bit of code you go
00:05:22.500
wow I wonder if that's still being used of course it's practically impossible to do we had some super nasty method
00:05:29.820
missing magic that we used all over the place somebody had just learned Ruby in the really early days of the code base
00:05:35.010
and are like man I don't have to like declare anything it's just all going to be method missing dispatch that way and
00:05:40.650
so it is impossible to tell what's going on right changing the code breaks completely unrelated to I swear to god
00:05:47.940
one time I had so many change of you and break a unit test I do not know how that works and yet here we are
00:05:59.630
good luck merging your style pools hopefully you guys are of the belief
00:06:04.680
that it's useful to have a somewhat consistent code style so if you do what we did you you know install roubo comp
00:06:10.890
you run Robocop against your code base and it's a trouble yeah you know you can
00:06:18.030
do there's a there's a - a option you can auto fix all of your style violations you know and then you just put up a pull request that has 69,000
00:06:24.900
changes and then we can't trust the test
00:06:30.210
suite as I mentioned it takes forever run there are lots of failures you know
00:06:35.430
of course any time you change a piece of code a bunch of new tests are breaking but we don't know if that actually means functionality
00:06:40.680
broken and so you start to shy away from those right like I'm not going to wait days to run my tests but I do instead we
00:06:50.400
became surgical in our precision we learned how to not disturb any of the
00:06:56.370
code around what we were trying to change make the tiniest possible change push it up don't hang it up and then run
00:07:05.039
like hell long as my name is not on the get blame we are okay right and a couple
00:07:13.199
times you know we tried you know we figure we'll fix this all we'll add you know whatever new libraries we'll split
00:07:19.590
everything up but it always felt like you know basically trying to book it out in the entire ocean with this little plastic button like you keep going and
00:07:26.940
keep going and you never make any kind of progress and so that leads us here
00:07:33.380
over time we became afraid of changing the code base this is an actual
00:07:38.820
psychological condition interesting sidenote it's also one of the underlying conditions to clinical depression
00:07:44.690
awesome and we just became afraid of making changes and so now not only do we
00:07:51.030
have the original problem of a code base that continues to get worse we have the secondary problem of not being willing
00:07:57.780
to change it leaves us here atrophic
00:08:03.180
despair so it's a pretty nasty situation right well the good news is that once we
00:08:08.970
actually took the time to you know take a look take an honest look at why we continued to make everything worse it
00:08:14.580
gives the opportunity to start fixing right so we're going to talk about how
00:08:21.599
to tackle these two problems for the since odd number one how do you become less afraid of your codebase and number
00:08:27.090
two how do you actually dismantle it in a way that is sane the first goal that
00:08:32.400
we have is to name the thing there's this whole concept of like knowing a thing's true name is to have power over
00:08:37.589
it right it's cool concept and I think that this is actually true about when we deal with our really problematic chunks
00:08:44.430
of code if I ask you to think about this really tough terrible code base that you have that you've dealt with what you
00:08:51.930
usually think of is the very worst of the thing right I put up a whole slide of it's a million lines of code it's you know 6,000 lines of this
00:08:58.769
and it's you know test suite that takes forever and it becomes a stand-in in your mind for everything about that code
00:09:04.470
every time you try to deal with it what you get is the image of this big impossible thing but that's a terrible
00:09:12.029
cognitive trick right that's not the reality every codebase I've seen the badness is
00:09:19.140
unevenly distributed and what I mean by that is they're usually those couple things that you would put on the slide
00:09:24.930
and those are the ones that are horrible and everything else kind of trails off so here's an example how you can look
00:09:31.200
into this something we do if you don't do a lot of bash this might look kind of weird you go into your projects for this
00:09:38.149
taking this from the inside out if you look inside the parentheses we can do find with a name of star dot RB so it's
00:09:45.089
finds all your Ruby files pass it to WC - L that is the word count and - LT how
00:09:52.079
many lines there are so that's how many lines in every ruby file on your system and then pipe it to sort on the route
00:09:57.540
this is something that I do pretty frequently actually when I'm looking at big chunks people say well our service
00:10:03.570
objects are bad or our tests are bad and I'll say okay well we'll go into the tests and we'll just run this command on your tests and what we find is this kind
00:10:11.070
of thing you get an output that is the number of lines sorted nice big total again I didn't want to call it anyone in
00:10:16.470
particular so I did this on the device code based things I devised not so bad but the characteristics of this I think
00:10:22.860
are really interesting this follows a pattern that I've seen in most people's code bases the very bottom file has 700
00:10:28.680
lines not great not terrible that's fine but it only takes like 4 or 5 files before you're at something that is half
00:10:35.010
the size and most everything in that code base is much much much smaller and
00:10:41.220
so what I think is that the badness is really it's an exponential distribution
00:10:47.279
right so at the very far left we have the couple files that are infinitely
00:10:53.459
terrible as we move to the right what we get is this you know the long tail of things that are it's just kind of okay
00:10:59.930
that's actually really useful realization as far as I'm concerned because that means that we can just cut
00:11:06.120
off a couple things and we'll to move really far down that line there's another way we can quantify some
00:11:11.730
bad things they don't use rake stats before only a couple so this actually
00:11:17.160
built into your rails app already if you have rails this is a command that you can run right now and what it does is it
00:11:22.230
just runs through all of your files and gives you an output like this again did in a relatively small codebase for
00:11:27.270
illustration there's a lot happening here but just to give you a sense of something that can be useful to us so
00:11:34.140
this column will give you the lines of code in every section of your application and the absolute numbers
00:11:39.540
don't really matter here because you already know that you have a billion lines of horrible code and you're really not going to delete all of your Ruby but
00:11:45.720
it does tell you kind of where it's hiding in this case there's not much happening in mailers and there's a ton happening in controllers so it's a very
00:11:51.780
controller heavy application and so we can start to quantify what's going on and then over here the last two columns
00:12:00.110
the one on the left is the number of methods per controller and the one on the right is the number of lines and
00:12:05.820
compliance of code per method and again we can start to get these real metrics that are accurate so we can quantify
00:12:12.900
what's going wrong so we can see that yes we know that our methods are too long but the reality is that that's
00:12:18.060
really only true inside of our models it's not evenly distributed and then in
00:12:24.360
our case there were a lot of different metrics that we wanted to gather once we got the inference that we could you know
00:12:29.400
start quantifying these things we realized that the normal output of the tools we were looking at wasn't very helpful and so we wrote some of our own
00:12:36.680
so made a let's cut off the memo we made a quick method it's a number of methods
00:12:42.270
for active record class here's some fun if you don't know you can do this you can actually look at all classes that
00:12:48.360
exist on the first line select for the ones that are children of active record we can sort them by the number of
00:12:55.320
methods so class methods back count reverse it because it's in our own order and then map it against some string so
00:13:03.930
not great code not the kind of thing that I would put up on a pedestal but it actually gives you this really
00:13:09.120
interesting view of what's happening in your system and once again we see that the models at the very top had a lot
00:13:15.510
more going on in the models at the bottom and that it's distributed in the same kind of way
00:13:22.350
and this is another thing I created I had an inference in one of my code bases that my tests were slow because I was
00:13:30.400
creating tons and tons of active record models I know it's a it's the blinding realization this is exactly what people
00:13:35.800
tell you but it's not really good enough to just say our tests are bad because there are lots of mod you know lots of models being created the reality is that
00:13:42.520
you usually don't know which ones are creating a lot of Records and so I built a simple for matter for r-spec and what
00:13:49.089
it does is whenever you run your tests I know if you can see in the green there to the left it shows you how many models are created and how many queries were
00:13:55.660
run it takes an uncertain bad and give you a sense of measurement that sense of
00:14:01.930
precision and when you do this when you add these sort of things to your codebase what you find is that the sort
00:14:08.950
of overwhelming terror of fixing these code bases ends up becoming pretty
00:14:13.960
manageable there are a couple places that are horrible there are a couple tests that are horrible right so the
00:14:21.070
next thing we need to do is talk about how we actually approach fixing some of the code right the first thing stop the
00:14:30.459
bleeding we got where we are precisely because we kept making things incrementally worse we cannot fix
00:14:37.810
everything until we stop making the codebase worse it's difficult to enforce
00:14:43.240
that line by just saying please don't make everything bad because of course you know people already are in that
00:14:48.339
position where the obvious thing to do and Robocop remember gave us you know 70,000 style violations but there's
00:14:55.270
actually another way we can run it if you run River cop against your codebase
00:15:00.839
find the very largest file and then set the threshold to that file number so
00:15:07.360
what I mean is run Robocop it says well you've got you know 23 parameters on
00:15:12.610
this method you say great this is our new threshold we will never be worse than 23 parameters on a method again
00:15:20.050
very courageous statement right and you go through and you do this for all the major metrics and the goal here is to
00:15:26.589
have a green Ruvo cop run em I do it's kind of a fake green right you're like oh man
00:15:31.970
no worse than 6,000 275 lines of code but the usefulness of that green is
00:15:37.699
something that you shouldn't take for granted because then anytime somebody goes back into that class and adds more
00:15:44.720
code they get one violation they get an actionable violation and every time
00:15:51.439
you're able to go in and start cutting apart at the very worst part to your codebase you say well we have this method that has 23 parameters let's take
00:15:57.680
it down to 22 great victory we can also tighten up our parameter in the
00:16:02.750
configuration here this is called ratcheting this is one of my very favorite techniques for starting to get
00:16:08.689
a handle on these kind of code bases because they only move one way at the very least do not get any worse and as
00:16:16.550
you get better you find that it's incredibly satisfying to be able to tighten down those ratchets now again in
00:16:23.600
the situation where I was dealing with this there were some metrics that Rubalcaba didn't have at the time I
00:16:28.610
think some of them are actually handled now but there's another way that you can do this too if you don't want to do it with Robocop it's also useful if your
00:16:35.649
engineers in your team don't really care very much about style violations but they're not the kind of folks we're
00:16:41.360
going to run that test so this is the code that we had before remember to grab
00:16:46.459
all our objects and we put it inside of a spec we set a threshold and then for
00:16:53.209
each of those classes and create a describe block now this is kind of devious our spec that's not something I
00:17:00.379
would encourage you to do in any other situation but it's actually really easy to create these expectations and end it
00:17:08.240
and what that gets for you is that now every time they violate a rule they
00:17:13.610
actually end up failing a test and this is a lot easier to catch in code of view it's a lot easier to catch overall and
00:17:19.100
it's one specific set of tests that you can look at and know that these are not the kind of tests that would normally become flattened right so stop the
00:17:31.400
bleeding and then need to actually make an improvement the important part right
00:17:37.330
but our skills that we had before weren't helping us very much look at some ways that we can actually scope
00:17:43.220
down to some smaller changes we can we can actually enact excessively so first rule before we get
00:17:49.039
into an actual result think globally but act locally I mean by that is that if your goal is
00:17:55.659
to make sure that all methods have no more than 10 lines you will not go do
00:18:03.620
that to your entire code base there will never be that pull request it's not going to happen and so you should keep
00:18:09.529
that goal in mind you're going to have to become comfortable with the notion of fixing these things a small amount at a
00:18:14.659
time one of the ways that you fix bad code bases is typically to introduce new patterns you know decorators and service
00:18:20.720
objects and such and you know yesterday Justin surles was talking about the value of having consistent style and
00:18:28.340
across your entire code base and what he said was that you know if you don't have that consistent style you pay a penalty
00:18:34.190
and this is interesting because what I'm encouraging you to do here is specifically to have different patterns
00:18:39.980
in your code base while you're in transition what I think the reality is that when you're dealing with not greenfield code you're not doing new
00:18:46.370
development you're working on this monster you have to accept that down side in order to make any progress the
00:18:54.620
pursuit of that consistency is destructive where to breakage is going
00:18:59.750
to happen if you are a senior developer do the junior developers a favor and
00:19:05.870
suck up every once in a while it's scary right like the first time you take down
00:19:12.020
production the first time you make a change that's like a truly frightening moment and we do all make mistakes like
00:19:19.220
I should probably replace it's not that you should make mistakes but that you should be honest about the fact that you
00:19:24.470
made mistakes we are all screwing up consistently but be honest enough about it that everyone else doesn't perceive
00:19:30.559
you as never making mistakes and remember that as we fix things we are going to break things that's reality we
00:19:37.909
do our best to mitigate it but we can't get rid of it and then the third prioritize here's my order of things
00:19:44.809
that I think you should fix I think you should make your tests okay you should
00:19:50.480
eliminate dynamic code should be headed to Dragon by which I mean you should kill those really bad pieces of code and
00:19:56.750
you should prioritize high churn code walk through those so tests they're
00:20:02.209
actually some really cool blog articles on how you can look at you know you're flapping tests or how you can look at your slow tests and go in and fix each
00:20:09.259
one and I've had a lot of people inside of teams say oh I'm going to assign my two q A's and they're going to look at
00:20:15.169
every single flapping test and then we're slowly going to move towards having them all be stable it has never
00:20:20.239
ever worked I have never seen this work and so I have a much better strategy for
00:20:25.309
you to get your test back to being green delete them I mean delete them and the
00:20:33.259
reason I mean this is that bad tests a bad test suite is worse than useless you
00:20:41.509
still pay the entire cost of maintaining this week you pay the cost of writing new tests you pay the costly literal
00:20:47.539
dollar cost of running them apparently on AWS across 100 instances but at the end of that process it doesn't tell you
00:20:54.259
whether your software works or not I don't care if you have a hundred percent coverage if the output of it is useless
00:21:01.009
you would be better to reduce your coverage and have a green run then to
00:21:07.159
attempt to keep working your way back towards that stability because once you have a green run you have real signal if
00:21:12.829
something goes red you have to fix it you will not get to that place incremental over to make writing new
00:21:19.909
tests fast so all the techniques that we know about refactoring depend on the
00:21:25.249
ability to run tests right and especially if you've taken my advice and
00:21:30.259
deleted some of your tests you're going to be writing some new tests and it doesn't work if you need to spend an
00:21:35.359
hour running any piece of your suite now the the realistic version of this is that you should really endeavour to
00:21:42.319
write tests that are not coupled to the rails framework you know again there was a little bit of what Justin was talking
00:21:48.649
about yesterday was ie writes these classes that do not mean to interface with active record directory and when
00:21:55.339
you can do that these tests are ten times faster at least and they allow you to avoid some of those worst parts of
00:22:01.219
what you've been doing second thing eliminate dynamic code so
00:22:09.649
I'm a little bit sad about this because Ruby is like really tool with metaprogramming right like we're really good at metaphor you could
00:22:16.190
do anything it's one of those neat features that everybody loves but I'm
00:22:21.290
going to say that you're not allowed to do it because you are like a teenager with a credit card you max it out and
00:22:26.540
you're like looking to score again you can't handle there are some people who are allowed to have dynamic code once
00:22:31.700
you're in trouble with your code base your privileges are revoked which means that you need to find the places in your
00:22:37.850
code base where you're using this dynamic code and remove them so for example this is a pattern that I've seen
00:22:45.260
a lot on the very first line we grabbed something that is probably a string constant eyes it and then instantiate it
00:22:51.670
here's the problem with this if I ever wish to delete any code ever I have to
00:22:57.740
make sure that it's no longer in use this is impossible to grep through the code base for and the more that you have
00:23:04.790
this kind of magic the worse off you are it's another version of it grabbing States and doing send you know
00:23:10.640
somewhere they're probably you know methods actually defined for these mark as things but again it's impossible to
00:23:16.850
know where they're being used or if you're really evil just cheek I'm gonna
00:23:22.400
call him out I know you can see the code in here inside of the class declaration apparently you can write actual code
00:23:30.290
snippets inside of your class but not not the block of the class but where the name would go you can put an if statement pure evil so
00:23:41.990
anytime really use any of these methods consider getting rid of them as much fun
00:23:48.559
as it is to be dynamic and elegance and all of that it's not as important as being able to understand your code base
00:23:54.440
and what you end up with is this sort of thing and in anybody who knows we know that I bore case statements I want to
00:24:01.760
burn them all with fire and yet this is better than not being able to figure out where your code is in use it's better to
00:24:09.140
be understandable than elegant next head
00:24:15.650
the dragon so what I mean by this is that like I said
00:24:21.029
we have this distribution where there are only a few things that are really really terrible and I think that you
00:24:28.140
should spend time specifically dismantling those things are 6000 line user parts and this is actually runs
00:24:36.330
against the advice that you get from a lot of people who teach refactoring the the rule is usually that you should only refactor something that has a new
00:24:42.899
constraint or you need to fix a bug and again that's really good advice because normally you're you're undertaking some
00:24:48.659
risk and some pain and you don't want to do that for no reason the overriding reason here is again that those singular
00:24:55.950
pieces of Terror make people afraid to work with the rest of the codebase and if we can cut them apart our
00:25:02.490
distribution looks like this it's not so bad so what it looks like specifically
00:25:09.299
for your code base is really individual I'm not going to cover every possible type of refactoring sadly it's not that
00:25:14.850
kind of talk but one thing I want to get across to you is that when I say to get rid of these files to make them less bad I am
00:25:21.809
NOT saying to go into your 6,000 line user file and refactor every line of it
00:25:27.830
because once again we do not have the ability to make that many changes you will not refactor 200 different methods
00:25:34.070
what you can do is tear them apart so I'm going to take it as an example here
00:25:39.779
a controller so controller say it's got you know 50 routes defined underneath it it's really really difficult for us to
00:25:45.929
go through all those routes to make a sensible change right but we can do define a new class initialize it with
00:25:53.730
some parameters and then take the 200 lines of misery and just plop it into the call method you can do this run it
00:26:02.850
it'll fail find whatever helper methods you need to pull into it and through a repeated process you're going to be able
00:26:09.120
to create a single chunk of code for this action and we go into our controller you see the first two lines
00:26:14.639
of this method all they do is grab that service invoke call on it and pull some
00:26:21.720
instance variables back out now when you do this you're going to basically
00:26:27.000
instead of having one controller that has 3,000 lines of code you have ten classes with 300 lines of code
00:26:33.570
and you'll still have some a lot of controller left over again explicitly you will have more code than when you started and you may say that's dumb but
00:26:43.500
you get something in trade for this what you get is that when you're working with any individual one of those services
00:26:49.280
you only need to think about what's happening inside of that service that is
00:26:55.110
an incredible improvement in your ability to make changes you don't have to execute the controller itself in
00:27:00.660
order to test the service that is a huge improvement and you no longer have that one spot where humans you know don't
00:27:08.160
dare to tread to try to fix things that is a huge improvement and last let's
00:27:16.170
talk about churn who doesn't know what turn is so everyone heard this metric
00:27:21.300
before cool so churn is the notion that there are parts of your code which change a lot
00:27:26.550
and there are parts of your code that don't change a lot simply the word for that idea and there are a couple things
00:27:32.670
that fall out of this so the one idea is that if your code is churning there probably one of two things true about it either the requirements change a lot or
00:27:40.260
your code is bad I'm probably both in reality well there's another thing that we can take out of the to our own
00:27:45.750
purposes which is that any kind of badness that you have to deal with gets worse when you have to deal with it on a
00:27:51.090
daily basis to keep changing it and so once you get rid of the very worst parts
00:27:56.250
of the code base you're left with a you know large well of net not horrible it's
00:28:02.520
not great and so the next thing that you should prioritize is that code that turns you know we can't go through and
00:28:09.000
fix our 70,000 offenses but I can go through and fix one file where another
00:28:15.570
name for this is essentially the Boy Scout policy you know whenever you go into a file leave it cleaner than you found it this is something that we can
00:28:23.130
actually start to handle as an individual mainly evil
00:28:32.120
stop the bleeding strategically improve that's our strategy if you do this
00:28:38.760
things will get better they're going to get better slowly and that's another one of the challenges that we face
00:28:45.169
so number four is focus on the process now if any of you saw Nick means talk yesterday he was talking about really
00:28:53.610
focusing on those long term goals or DHHS keynote on the first day talk about having faith that's important in this
00:29:00.120
case I should say from DHHS keynote I don't think you are Sisyphus I actually
00:29:05.759
had a specific slide in here and then he used it and like that seemed like a really weird specific thing to repeat between two talks so I took it out but I
00:29:13.259
don't think you are because in the legend of Sisyphus he made no progress and you may roll the rock up the hill
00:29:19.200
and you may roll back down but the reality is that you can make things better slowly and so what you have to do
00:29:25.559
is take some amount of solace and the good thing to do happen when you have these victories celebrate them because
00:29:30.659
when things aren't going as well you're going to want to look back on them so
00:29:36.539
the one other thing I wanted to give you during Mass at the end of a talk this
00:29:42.090
has always been a really interesting idea to me on the top you have making things 1% worse every day for a year the
00:29:49.500
end of the year we've got monster I'm tiny changed make things 1% better
00:29:55.259
instead not such a big change at the end of the year you've got something incredible there's something really
00:30:04.139
interesting to me about this and I think you have the opportunity to be the latter of those two so that's what I
00:30:11.159
think you should do it's all got my slides are up on well this bitly link
00:30:17.850
I'll post them on Twitter as well please feel free to follow me on Twitter and come ask any questions you'd like thank