Ruby Video | RubyCond 2021 - Workshop: Tackling Technical Debt: An

00:00:11.280 my name is chelsea troy i'll talk a tiny bit more about myself a little bit later but you're in the

00:00:16.880 workshop tackling technical debt and analytical approach if you're looking for joint cognitive systems that's across the hall

00:00:24.560 i will not be talking about that but yeah i guess let's go ahead and get

00:00:29.599 started um here so

00:00:36.320 the first thing to know about this workshop is that we're going to cover a lot i see a 99-minute timer in front of me the schedule said two hours i will

00:00:42.960 take the entire two hours however it is going to be relatively fast paced hopefully you're going to

00:00:49.360 learn a lot and if i do not get to a question that you have which may happen

00:00:56.640 please feel free to post it in the discord channel i'm going to be checking that after the workshop and throughout

00:01:02.000 the weekend and the benefit of posting in that channel is that other people will get to see your answer as well so

00:01:07.600 if we run out of time for questions at some point you still had a question do not worry we will definitely get to

00:01:12.640 those feel free to post them in the middle of the workshop and i will just check them afterwards so that link is in

00:01:17.920 the slide which you should all have in the discord channel finally there's uh

00:01:24.159 currently plans to turn this into a little bit of a longer version of a workshop for graceful dev which is a

00:01:29.360 project that avd grimm is doing so uh i will be interested to hear your feedback on this workshop to find out

00:01:35.920 what to expand on finally if you are a tweeter

00:01:41.200 uh there are three handles there please feel free to include them in your tweet one of them is of course the ruby cons

00:01:46.799 handle one of them is my handle and then one of them is the handle of my lovely assistant

00:01:52.479 leah miller um i guess that's about it for this slide so whoa

00:02:00.640 all right uh so like i said my lovely assistant leah throughout this workshop

00:02:06.159 we're gonna be asking y'all for some input at various points very very important that it goes into the mic however for

00:02:12.800 accessibility reasons what we're going to do is we're going to have leah bring the mic to you so if i ask you to raise your hand leah gets to pick who is going

00:02:19.920 to get it if we only have one or two people so um so that is the plan so that everybody

00:02:25.599 gets on there if uh if i have you raising your hand and folks are gonna come around please just

00:02:31.280 wait until you have the mic and uh that way we can hear your beautiful voice explain your question or

00:02:37.760 your story what have you finally this is me this picture was taken in my home city of chicago you can

00:02:44.959 almost see the sears tower there behind my head we don't call it the willis tower so

00:02:50.800 if you ever come and you hear that don't uh don't subscribe to that

00:02:56.879 okay so let's get started what is technical debt

00:03:02.400 now i think there are a couple of misconceptions about what technical debt is so i want to go over those real quick

00:03:08.959 we all have an idea of what it looks like i suspect you all have an idea of what it feels like hands up if you know

00:03:14.800 what tech dev feels like okay okay that's a lot of the room so a couple misconceptions about it first

00:03:21.440 misconception that i want to dispel is that tech debt is tantamount to bad code there are a couple of reasons that

00:03:27.920 this misconception is harmful for us when we're trying to talk about the state of our code base the first one is

00:03:33.840 that it causes us to equate the developers that came before us with bad development that's usually not the case

00:03:40.159 there are a lot fewer really terrible engineers than there are good engineers who had to do something under

00:03:46.000 constraints that we do not understand that caused the code to be the way that it is now

00:03:52.799 so that's the first thing i want to mention the practical reason that equating tech debt with bad code is an issue is that it puts us under the

00:03:59.360 impression that if we write good code

00:04:05.360 then we are not adding maintenance load to our code base which is not true we're going to talk

00:04:11.840 about maintenance load a little bit later second misconception

00:04:17.120 about tech debt is that once you build a feature it is free once you have built it once

00:04:22.639 we are done once it is shipped once it is working we don't have to worry about that feature anymore we don't have to

00:04:28.720 take it into account when we are writing further code that's not the case

00:04:33.919 on features we pay rent we have to do maintenance on those features and that's where this term

00:04:39.440 comes in that i mentioned earlier maintenance load i like to define technical debt in terms of two other

00:04:45.759 things which we're going to go over first of them is maintenance load maintenance load

00:04:51.600 is the proportion of total developer effort

00:04:56.880 spent on maintaining the existing feature set so

00:05:02.160 if you have one developer and that developer spends four

00:05:07.440 one day let's say working on features and four days on other tickets related to maintaining the code base

00:05:13.919 then the maintenance load is 80 so a couple examples of what kind of

00:05:20.639 tickets would count as maintenance load might be updating or up versioning or investigating existing code hands up if

00:05:26.479 you've done something like this congratulations you have done maintenance load determining whether a

00:05:31.919 given feature ever worked people done this you've done maintenance load did you

00:05:37.360 figure it out sometimes i haven't adjusting deployment so that existing

00:05:42.639 functionality will scale to new scales of folks done this few hands yeah you've done maintenance load

00:05:50.320 the heuristic i use to determine what's maintenance load and what's not is this any developer activity that is

00:05:57.600 not adding a feature or removing a feature

00:06:04.160 counts as maintenance load now we can get into depth on what a feature is we're not going to do that for now but

00:06:09.280 take your definition of a feature if you're not adding one of those or you're not removing one of those whatever else you're doing

00:06:15.440 maintenance load for the purposes of this workshop the other concept that you need to know when defining technical

00:06:21.120 debt the way i do is context loss so context loss

00:06:28.160 is a lot of the reason that we end up doing this work very frequently when i've gotten into code bases where i was told

00:06:34.400 that there was a lot of technical debt particularly earlier in my career i would equate that with bad code and think it's very convoluted or something

00:06:40.720 like that sometimes i was even told that that's the way it was then i would get in that code base and i would realize

00:06:46.080 this code isn't that bad it's just nobody here knows how it works

00:06:53.599 that's context loss it's missing information about how whether or why

00:06:59.039 a piece of the code base existed or worked it has

00:07:04.400 very little to do with the quality or functionality of the code itself it has everything to do

00:07:09.680 with the way the context was shared or stored or broadcast or not shared stored or broadcast among

00:07:17.599 the remaining team members you can get context lost for a number of things for example something wasn't documented and

00:07:23.680 the team forgot that's context loss only one person ever knew and that person left the company

00:07:30.560 hands up if this has happened to you huge source of context loss right there

00:07:37.759 this is why churn events are so risky technically is they drive your maintenance load way up usually

00:07:46.960 another way might be that the code is so complicated that even the original author isn't sure what's going on

00:07:52.720 anymore hands up if this happened to you my hand is up yeah this happens i teach computer

00:07:58.160 science students this can happen as fast as four weeks or six weeks if it's something sufficiently complex

00:08:05.199 so that's context loss so now we've got maintenance load we've got context loss we're ready to talk about what technical debt is tech debt

00:08:13.120 is maintenance load in the existing code base that comes

00:08:19.360 from context loss so that's what it is

00:08:25.599 that's what it means so how do we quantify that we can quantify that in terms of how much of

00:08:32.640 our developer time and effort is getting spent fantastic how do you know if your

00:08:37.919 maintenance load is under control right now so we talked about

00:08:43.360 a number but you're all in this room and you didn't know that definition or that numeric uh quantification before we got

00:08:51.200 in this room so you must know somehow what are some of the signs signs but your maintenance load is not under

00:08:57.440 control might include agreements with products to

00:09:02.720 take on tech debt to deliver a feature hey this boat's got to get from here to there do

00:09:08.320 you mind taking on a little water just just until we get there promise we'll let you bail it out when we get there

00:09:14.560 maintenance loads not under control another example the team

00:09:19.600 has accepted that there's some features that just don't work show of hands you all have this going on couple yeah

00:09:26.720 support teams that have just been told yep tell them the manual way just do it manually form the button doesn't work

00:09:32.320 maintenance load is not under control because we're not able to maintain the corpus of features

00:09:38.399 that we're committed to maintaining according to our user interface

00:09:43.600 another example there are repositories or features that the whole team avoids anybody had this experience a

00:09:50.480 repo nobody wants to go into a legacy api nobody wants to touch that's right okay

00:09:55.920 anything where the entire team at stand up is like nose goes

00:10:02.399 that's an abandoned house these are signs that your maintenance load is not in fact under control

00:10:11.279 so now i've got an individual question for you i'm gonna have everybody answer this individually but that link right

00:10:16.640 there where it says here that links to a google doc and i want folks to feel free to type it in there because i think

00:10:22.240 it'll be interesting if everyone can see everyone's responses to these questions

00:10:27.600 first what is your worst maintenance load horror story

00:10:36.240 what is your worst maintenance load horror story

00:10:43.040 and then how about the opposite

00:10:48.160 situation where things were smooth easy to maintain

00:10:54.160 i'll give you a couple minutes to type something into that dock

00:10:59.600 would anyone feel comfortable to share their answers

00:11:05.440 to this question and put your hand up if so

00:11:10.959 leah will bring the mock to you we've got a couple over on the rail here

00:11:17.760 by the doors so we have a legacy server that nobody

00:11:25.360 knows how to maintain with legacy code that no one codes it anymore

00:11:31.600 that we somehow have to keep running sounds like fun

00:11:37.360 if you spell fun with a ph amazing anyone else

00:11:44.640 all right we got one over here uh years ago i worked in a support

00:11:50.399 department for internet banking we did a professional service contract for a client took them live on a new copy of

00:11:56.000 their internet banking site four months in they reported a few users weren't receiving some alerts

00:12:02.560 and i discovered that that alert had never fired in the four months they'd been lived awesome it never worked

00:12:10.079 lovely all right maybe we can do one more

00:12:15.279 do i see anybody show of hands oh it looks like you've got somebody

00:12:20.959 a team was underwater with on-call responsibilities so they added a second person

00:12:34.480 amazing good maintenance load horror stories there

00:12:41.279 i have a couple myself i work on uh on one application well that's not a fair characterization i work on a couple

00:12:48.160 different applications where as we discussed a developer built the

00:12:53.200 application and uh then left for various reasons and it's the company or the organization has

00:13:00.480 been sort of using it for a while um a lot of interesting stuff happens in those but they're fun to learn to

00:13:06.959 spelunk okay so now i've got another individual

00:13:12.320 question for you this one i'm going to give you five minutes for

00:13:20.000 what practices distinguish your maintenance load horror stories from good stories now here's what i mean by

00:13:26.720 that what is your team

00:13:31.760 doing in the maintenance load horror stories what is development like on the code

00:13:37.519 base with the maintenance load horror stories versus what is development like on the code

00:13:42.800 base where you have the opposite of that where you have a smooth experience where the app feels

00:13:48.800 maintainable what are the differences and i'll say some of these differences might not necessarily be programming

00:13:54.560 practices it could be age of the code base one of them is 10 years old one of them six months old that's a big difference

00:14:00.880 or the differences might be size of the team but there are also generally practices the way that the team

00:14:06.959 approaches documentation the way that the team approaches testing the way that the team approaches meetings so what i'd

00:14:12.240 like you to do is write down somewhere on your own computer we're going to use these later

00:14:18.240 think about your horror story and the opposite and ask yourself what practices distinguish

00:14:25.680 those two teams and make a little list we will use this list later so actually do the exercise

00:14:35.760 so you've got your list we'll call that our cliffhanger for part

00:14:41.920 one of the workshop we're going to come back to those so keep them in mind

00:14:48.480 so now we know what maintenance load is let's talk about why maintenance load rises

00:14:56.839 so there's another critical concept here i call this code stewardship

00:15:04.880 not positive i like the term code stewardship so if you have a better idea for what to call this after we talk

00:15:10.480 about it feel free to tweet it to me because i am taking submissions but for now we're going to call it code

00:15:16.399 stewardship and it is specifically the skill of reducing

00:15:23.360 maintenance load now i want to be clear we cannot eliminate maintenance load unless we eliminate all of the code

00:15:30.880 because we have to maintain the system but this is the skill set of reducing maintenance load

00:15:37.759 and it's a skill set that we don't tend to incentivize or prioritize

00:15:42.880 in programming education and professional programming environments the places that do are anomalies

00:15:50.639 but it includes something i'll give you five examples here

00:15:56.320 it includes writing discoverable code by this i mean writing code that somebody who has not

00:16:02.079 seen this code before will be able to go in and use the code itself as an artifact

00:16:08.160 to understand what the system is supposed to do that's discoverable code

00:16:16.560 another example might be writing code with the malleability and rigidity in the right places and i want to

00:16:22.880 explain what i mean by this one because we often say that we want to keep our code flexible right

00:16:29.040 we want to keep our code flexible what are some other things we want to do with our code folks familiar with dry don't

00:16:34.560 repeat yourself okay so we want dry code but we also want flexible code right

00:16:40.480 suppose we dry up some code from two different places and then we find out that one of the places needs to change

00:16:49.279 is it easy to change relative to the way it used to be no when we dry up code

00:16:56.000 we trade malleability for the conciseness of that code we make

00:17:01.759 it more rigid because we are trying to get some other things we are making a bet

00:17:07.439 we are making a bet that if we want to change this thing that means we want to change it

00:17:13.199 everywhere and if that bet turns out to be wrong then

00:17:18.400 our code is not malleable in the ways that it needs to be now

00:17:23.919 i want to offer some grace here it is very very hard to make code

00:17:29.360 malleable everywhere i'm not sure it's possible to make code malleable everywhere or if you

00:17:35.840 were to do it you would have to give up all kinds of other things you would have to give up dryness for example because every single

00:17:42.160 instance of a place where you do something needs its own copy of the code for it to be independently changeable

00:17:47.520 and that also means that if you do want to change something everywhere now it is difficult

00:17:52.559 that malleability isn't in the right place either it's very hard to make a code to make the code malleable

00:17:58.400 everywhere i'd say impossible so what we have to do is figure out what is the most likely to

00:18:04.799 change about our code in the future and we have to make bets by placing the

00:18:11.600 malleability of the code in those places where it is most likely to change and probably the trade-off will be

00:18:18.000 making the code more rigid in places where it is less likely to change but those rigid areas are supporting

00:18:25.280 the malleable portions of the codebase we're putting our malleability and our rigidity in the right places because

00:18:32.160 when we try to make code flexible everywhere it usually ends up being flexible nowhere

00:18:38.880 another example of code stewardship might be documenting code with detail in the right places

00:18:48.559 show of hands who's read documentation that did not help you figure out how to use the library you were trying yeah

00:18:54.320 it's most of it um and it's not entirely programming teams fault code stewardship like i said is a set of

00:19:01.200 skills that we tend to under value under incentivize under teach and that comes

00:19:06.320 with documentation too and we ask programmers to be good writers and good indexers and good teachers and that kind

00:19:11.679 of thing that's a separate skill set and it's a difficult skill set it's a difficult skill set writing is

00:19:17.679 hard and so when we ask programmers to do that on the side of their programming job yeah a lot of the documentation ends

00:19:22.960 up not being what we want it to be right but that's a code stewardship skill

00:19:30.720 here's another example writing tests that convey code functionality and boundaries so tests are really valuable

00:19:37.440 for a number of things automated tests can help us catch regressions in our code base if we

00:19:43.760 accidentally break something they can give us the confidence to make changes even big sweeping changes without

00:19:50.960 worrying that we've introduced regressions tests also can serve as living documentation for our code if

00:19:58.320 code is going to change often it is helpful to have documentation that either changes or deletes itself

00:20:05.360 or or tells us that it becomes invalid at the point where the code changes right and tests are exactly that when i get

00:20:11.200 into a new code base that's well tested i like to use those tests as a laboratory to understand what the code

00:20:16.880 does i can change things in the test and figure out what's going to break how it's going to break i can understand

00:20:22.640 exactly what people expected my code to do a lot of times i can also tell how

00:20:27.840 this code has broken before because there's an automated test in there that's like test it doesn't do

00:20:35.120 that thing and that's the name that's valuable information too

00:20:40.799 here's another example transferring context to other members of the team

00:20:46.400 this is a really valuable code stewardship skill and it's the one that we haven't exercised entirely if

00:20:52.400 somebody leaves with a whole bunch of context right and i want to say that on this one the

00:20:58.400 smaller the team working on an individual unit is the more deliberate we have to be about this one i like i'd

00:21:04.159 like you to picture context for now as a giant beach ball this big okay and if i throw it towards you right now

00:21:11.760 do you think it's likely to hit the floor i don't think it's that likely to hit the floor and the reason is that there

00:21:17.840 are a lot of you and you're pretty close together so it's probably not going to hit the floor now suppose that i was in here and

00:21:24.559 there were like five of you interspersed around the tables not working closely together not so many

00:21:30.080 of you and i throw that beach ball there's not likely to be somebody who just happens to be where it is when it

00:21:36.799 catches when it hits the floor and so if

00:21:42.159 somebody is not going to be available they have to deliberately hand that

00:21:48.080 beach ball off to somebody else that's context transfer we could do it through pull request reviews we can do

00:21:54.000 it through documentation we can do it through testing we can do it through artifacts we can do it through a lot of these other means

00:22:02.080 so now i'm going to give you an individual exercise and this is where we come back to the list that i had you write earlier earlier you considered

00:22:09.760 what practices distinguished high and low maintenance load accumulations on teams over time

00:22:15.600 horror story code base and the smooth and easy code base

00:22:21.280 now what i'd like you to do is take those examples and copy them one by one and paste them into

00:22:26.960 this easy retro that's linked in the slide under what kind of example it falls so what i

00:22:34.320 want to know is those practices that you listed out do they fall under any of the five examples that we just talked about

00:22:39.840 of code stewardship and if so then you can copy them and paste them into that column on the easy retro

00:22:47.039 now if you've got a practice that does not fall under any of those five examples what i would like you to do is

00:22:54.480 put it in the sixth column for other examples of code stewardship

00:23:06.000 so i'll give you a couple of minutes for that if anyone has trouble accessing the easy

00:23:11.039 retro just raise your hand and we'll come and help

00:23:23.120 we're experimenting with methods here this is my first time doing a workshop of this sizing person so

00:23:36.000 so i'll give you a couple minutes to copy and paste your stuff in there let me see if i can pull it up so you

00:23:41.840 can see on the big screen this easy retro

00:23:50.400 oh we got some stuff we got some stuff

00:23:55.679 now i need that horse race music

00:24:08.559 cool keep typing i'm going to start reading off some of these examples so writing discoverable code

00:24:15.360 somebody says it was a newer repo that was fairly small and narrow in scope

00:24:22.320 the changes all followed the paradigms that were set up from the beginning including the testing suite making changes easy and safe i like this

00:24:29.840 one i want to point it out specifically because for those newer code bases you generally have a small enough number

00:24:36.320 of features but a team can stay on top of it a little easier than if you're talking about a code base that's 10

00:24:41.679 years old right gives you a lot more control over what's happening in the code base favoring readability over terseness and

00:24:49.200 cleverness in writing discoverable code high cohesion solid object-oriented design patterns a

00:24:55.679 well-defined set of design patterns often your team agreeing on what

00:25:01.200 practices you use is more important than whatever practices you used as long as you can pick something and agree on it

00:25:07.360 what the thing is is less relevant so malleability and rigidity in the

00:25:12.559 right places avoiding premature abstraction i like that one i give another talk about

00:25:19.679 refactoring and i like to talk about the rule of three in that one i don't generally consider consolidating until i

00:25:25.679 have three instances of something because i do not trust myself to predict with less empirical evidence

00:25:31.919 than that what's actually the same i've messed it up too many times

00:25:36.960 let's look at some more heavy use of interfaces and private methods open discussion with product about possible

00:25:42.720 ways product will change this is super helpful we're going to talk more about talking with products a little bit later

00:25:50.400 tests that convey code functionality and boundaries good test coverage testing suites are ignored because writing the

00:25:56.960 tests are too difficult and time consuming that must have been one of those nightmare code bases

00:26:03.840 fast ci and frequent deployments yup having a small tight feedback loop can be super useful from from a pragmatic

00:26:10.400 perspective because if it is logistically difficult or even impossible to run your code base

00:26:16.320 frequently and easily people won't do it and it's not because they're trying to be naughty it's because they can get their work done if they try to do that

00:26:24.799 okay documenting with detail in the right places clear documentation written without

00:26:30.240 assumptions about what the reader knows or can do the documentation that included examples where similar changes were made i like

00:26:36.960 that it's very helpful to have sometimes a pr to follow that you're doing something like i work on a programming

00:26:43.120 language called roc it's a functional programming language compiler is written in rust we're adding a lot of built-ins

00:26:48.400 to it which are things like find the max in this list find the minimum in this list find the last item in the list the first

00:26:55.200 item in the list the item at a given index and often when somebody's adding one of these built-ins we can point them

00:27:01.120 to a similar built-in that gives them the opportunity to see this is where we made a very similar change you're going

00:27:06.159 to largely follow this consistently created architecture design

00:27:13.919 records documentation that focuses on the shape of data at key points in the flow all

00:27:20.480 features tied to a story or ticket extensive documentation on both technical tasks and decisions made

00:27:28.000 adding a readme in the subfolders is specific to the content inside of the folder that can be very helpful very

00:27:33.919 often um the first instinct when we're supposed to document more is to add more stuff to the readme and eventually you

00:27:39.520 have like a 6000 word readme and it's absolutely beautiful from like an artistic perspective

00:27:47.039 but it's hard for devs to figure out what they're looking for um

00:27:52.559 so that can be helpful transferring context to other members of the team structured knowledge sharing mentoring

00:27:59.360 pairing pairing is one of my favorite ways to transfer context doesn't work always but in the right situations it can be very helpful

00:28:06.080 a bus factor greater than one fewer people to coordinate with that is definitely a reason that uh context

00:28:12.960 transfer would be easier clear ownership of modules or applications that can be helpful too

00:28:18.799 so um on a number of open source projects with very small teams supporting in the end thousands or even tens of thousands

00:28:25.600 of client developers it's not necessarily plausible for them to pair all the time sometimes one of them lives in australia

00:28:31.919 and one of them lives on the east coast of the united states and the time zones just straight up don't overlap and so

00:28:37.760 what they'll end up doing is saying you're responsible for this piece and you're responsible for that piece and on absolutely need to know basis you'll ask

00:28:44.000 each other questions about it and it ends up working it's not pairing it's not continuous context sharing but it is

00:28:49.840 very deliberate about the way it approaches context sharing and it'll work for those teams sometimes

00:28:56.480 okay so this is my favorite part a different example let's take a look at some of these

00:29:03.039 solid processes of canary and limited traffic releases canary

00:29:08.320 being um like pings that test your api regularly is that what we're talking about

00:29:16.320 uh breadth is always better than depth pushing back on product when we believe

00:29:22.720 that a simpler version of a feature will meet the business need rather than accepting all requirements

00:29:28.799 as immutable regardless of the complexity incurred i love this one we're going to talk

00:29:34.240 about this one later kudos this person

00:29:39.440 having a maintenance week and other allocated time just for engineer driven initiatives dedicated time or week to

00:29:45.600 tackle and shorten maintenance load not measuring or caring about what proportion of time and effort we spend

00:29:50.880 on maintenance and bug fixing this sounds like one of those horror story ones and it's a tough one because most teams don't measure this until

00:29:58.320 the ultimate metric which is developers quitting and that's bad right because developers

00:30:04.080 quitting like we said is a churn event which does what to maintenance load drives it even higher

00:30:10.960 adding refactoring efforts to the time estimates for a new feature when it's related to that feature

00:30:16.080 even if you don't have to refactor now this one is really helpful it's one of the microwaves that developers can use

00:30:22.640 some of their limited individual power and institutions is to say that refactor is part of this feature we're just going

00:30:28.080 to do it together and it's going to take the time it's going to take to the degree that you can

00:30:33.360 doing continuous maintenance on dependencies instead of waiting a long time before doing this yeah a bulk update or a big

00:30:40.080 update of dependencies can be a big pain in the neck discussing incidents in the context of

00:30:46.640 can we prevent this i also like this one a lot i've been in a number of incident reviews where we talked about the

00:30:52.880 response um and didn't get the opportunity to quite get to is there something we can do to

00:30:58.799 make sure that this doesn't happen again but that can be really valuable too both from a stress reduction perspective and

00:31:04.240 from like a pragmatic perspective so we've got some examples right

00:31:13.360 excellent so this is what we're going to do now am i on time i am on time we're going to

00:31:19.200 take a 10-minute break if you need to grab tea or pee or those kinds of things then we're going to go over some more stuff when you come back at the end

00:31:25.440 we're going to have a larger more comprehensive exercise also if you've been looking to lead but you didn't want me to notice now is your

00:31:32.000 opportunity people came back

00:31:38.720 what's that quote if you love something let it go it flies back

00:31:46.399 this is great all right we did our 10 minute break

00:31:55.039 everybody ready to continue fully fueled and ready to rock

00:32:00.720 we're going to talk some more so we talked about what maintenance load is we talked about

00:32:06.159 what drives it up we talked about how you might try to keep it down

00:32:11.440 but what if you're in the situation where you're bailing the boat and you need that maintenance load to come down quickly

00:32:17.919 that's what i suspect most people are trying to get out of this talk an analytical approach to technical debt

00:32:22.960 another title that i use for this sometimes is technical debt first steps a lot of the professionals who show up

00:32:28.320 to that that's an online thing i do that with o'reilly and uh a lot of the folks who come to that their maintenance load

00:32:34.399 is already so so high and they need to bring it down quickly so we're going to talk about how you might go about bringing down maintenance load now

00:32:41.519 we talked about why it rises we talked about how to prevent it rising now we'll talk about how to bring it down so there are a couple steps

00:32:48.320 step one is going to be to identify culprits in the code and in this section i

00:32:54.000 suspect i'm going to say some things that are not what you think i'm going to say so we'll see what you think

00:33:01.120 and then the second thing you want to do is prioritize high leverage changes and by high leverage changes i mean

00:33:07.279 changes that are going to bring down your maintenance load quickly

00:33:14.559 let's go through this step by step step one identify culprits in the code

00:33:22.840 so teams will often do this they'll try to set aside time to specifically pay down

00:33:28.399 technical debt can i see a show of hands who's been on a team that's done this my hand is up too yep so this it's from uh from a

00:33:36.320 theoretical standpoint this pro this approach makes a lot of sense um and sometimes we come out of it with

00:33:42.320 changes that are helpful i find

00:33:47.679 that the signal-to-noise ratio on the changes that get made in a week like this tend to be lower than i would like

00:33:54.480 and i think the reason is that taking time with a clean bill of paying back

00:34:00.240 technical debt is too vague it ends up leading to renovations that don't really reduce

00:34:06.799 maintenance load so that brings us to

00:34:12.879 an uncomfortable potentially conversation which is the conversation about code

00:34:18.879 renovations the reason that this is an uncomfortable conversation is that many of us myself

00:34:26.240 included have done this thinking that we were materially improving the

00:34:32.879 code base what is a code renovation it is a change that developers make to working

00:34:39.200 maintainable code because that code does not match their personal architectural preferences

00:34:48.159 the reason that i call it code renovations is because if we imagine maintaining code like maintaining a

00:34:53.839 building i don't like to use those kinds of metaphors to describe software

00:34:59.119 engineering that much because they often break down pretty quick but in this case it's opposite you can fix windows you

00:35:06.079 can fix the roof you can fix the plumbing you can change the grading under the house so that the basement floods less often those are all

00:35:12.400 maintenance and you can also trade out the kitchen for

00:35:17.520 a really gorgeous marble pink gold let's just say that this is all

00:35:23.359 good design decisions compared to what it was because you

00:35:28.400 didn't like it right and it's prettier you like it better but does anything on the house work better than it did before

00:35:36.400 probably not if you have good contractors then nothing doesn't work that used to work

00:35:42.960 but that sometimes happens too right now pet refactors often fall under this

00:35:51.520 code renovation category and they're fun they're often fun and

00:35:57.760 the developer who's doing them often learns something and maybe if the whole team agrees then everybody even likes

00:36:02.880 the code better but often they're not done with full team agreement they're done because some individual was interested in driving through this

00:36:08.960 change and the team didn't necessarily agree and so it took some time during the refactoring week to just

00:36:15.119 shove it in there everybody will like it once it's done these kinds of changes don't reduce

00:36:21.359 maintenance load and in fact they often erase context that the team already shares about how the code works

00:36:28.320 what happens to maintenance load when context is lost yeah it goes up so a lot of times these

00:36:35.839 pet refactors end up increasing the maintenance load because it means the rest of the team now no longer

00:36:42.079 understands a pattern in this code base and they need to take time and effort to learn this pattern is that adding a

00:36:49.119 feature no it is not is it removing a feature it's not that either it's maintenance load it's something the devs

00:36:55.200 are having to do to maintain this code base

00:37:00.320 now here's a question have you performed something that you now suspect

00:37:07.119 of being a code renovation show of hands my hand is up yep

00:37:12.720 it's common i worked on a code base where we had this absolutely brilliant ios developer amazing understood all of

00:37:18.960 the internals of ios was working on a team of eight people the other seven people were not as

00:37:24.400 deeply familiar with the internals of ios this developer did not like the way that you navigate from screen to screen

00:37:31.280 in a standard ios application so they built their own completely functional

00:37:37.839 screen navigation library and they made our application

00:37:44.560 depend on it from their personal github this was a health insurance application

00:37:50.640 with about 11 million end users yeah and uh

00:37:55.920 and it worked great until the day it didn't and on the day it didn't he had been

00:38:02.400 rotated to another project because i was working at a consultancy and people rotated every three to six

00:38:08.160 months he wasn't there anymore to explain what was going wrong and

00:38:15.040 the problem with navigation was not googleable because the way that everybody else does navigation in ios

00:38:21.440 was not this so it was impossible for developers to find artifacts that would help them fix

00:38:26.880 the issue in this developer's absence i ended up spending a week

00:38:33.280 putting that code back in plain old

00:38:38.400 plain old like not ios whiz

00:38:43.920 genius terms that were google-able and were the way that most people were doing screen navigation in ios at the time

00:38:50.400 um one time earlier in my career i changed a whole bunch of stuff

00:38:56.320 from static methods to uh instance methods and then i instantiated instances of those

00:39:03.119 classes in order to call those methods because i had learned that static methods were bad

00:39:08.560 and lots of little objects were good

00:39:13.680 and i don't think that changed the amount of time that anybody took to maintain any piece of that code one bit

00:39:19.200 i it did not improve the developer experience at all i think i got lucky

00:39:24.800 that particular thing didn't make anybody confused about the code because it was essentially adding an invocation

00:39:30.400 between the name of this class and the method but it did not help it was not helpful and i

00:39:36.480 spent several days doing this because i was convinced i knew how it went

00:39:42.960 anybody want to share their code renovation stories show of hands maybe

00:39:49.760 do you have a brave soul we'll appreciate your sacrifice for the

00:39:54.800 good of the group so before we had robocop we had many

00:40:00.800 conversations on code style and i spent multiple days switching all

00:40:06.720 of our sing double quotes to single quotes when i could

00:40:13.280 that's a good one let's uh let's give them a hand folks for their bravery

00:40:18.480 this is sharing your mistakes with a room full of like 150 people it's not an easy

00:40:24.079 thing that said anybody else want to do it oh sweet so that prompted her memory of

00:40:30.319 the same thing in javascript where we got into a discussion of whether we should put semicolons at the end of lines or not in an existing project with

00:40:36.800 lots of code someone submitted a code chain before the team had agreed fully is what to do

00:40:42.240 someone submitted a change that was functionally four lines of code and 230 changes in the file oh my gosh

00:40:49.839 and created a rather large incident in a meeting for the team over that

00:40:55.359 and what to do next oh man that's good all right let's give him a hand

00:41:06.480 some version of the semicolon wars where like some people remove the semicolons and other people come through

00:41:12.319 the file they add back the semicolons and it's like this passive aggressive king of the hill

00:41:17.920 game and whoever maintained it last you can tell where they fall on the semicolon wars

00:41:23.680 lines that happens that one's not too harmful because the code looks the same but

00:41:29.839 sometimes you get a big refactor and it's like we wanted this to be functional why because we like functional code that is

00:41:36.640 great but our production application wasn't the place to change all that unless we had a material benefit from it so

00:41:44.720 that's a code renovation congratulations we got through the code renovation portion of this

00:41:50.480 workshop which is the most awkward portion so it's all downhill from here

00:41:56.800 so here's what i'll say is that uh

00:42:04.079 so how are you going to identify these culprits in the code if it's not just based on what you personally don't like

00:42:11.280 this is a place where i recommend collecting some data from your team right you have some options here you could potentially show of hands if your

00:42:17.680 team uses retros they use retro yeah okay so what is a retro

00:42:23.520 beyond a sanctioned place where you are allowed to complain about things in the code base it's a

00:42:29.839 great opportunity to do it and conveniently you already have notes on your retros potentially pictures of them

00:42:36.560 maybe you keep them in a google doc somewhere so it's a great opportunity to go back and look at what developers are

00:42:42.160 repeatedly complaining about in the code base that is often a great spot

00:42:47.920 to start socializing some changes that would reduce maintenance load another option would be take a look at your

00:42:54.240 incident reports look at your incident reports what's causing incidents very often the reason

00:42:59.680 an incident happened was somebody made were pushed to change where they thought they knew what it did and they didn't

00:43:05.839 that's context loss that's an absence of context so that's a place where you might get it from

00:43:11.440 another option might be to look at where

00:43:16.640 your estimates are running over show of hands who does estimates some folks do time some folks do complexity okay if an

00:43:23.520 estimate runs over frequently what's happening is there was some snag that

00:43:29.839 the team hit that it didn't anticipate when it was doing the estimation in the first place a record of what those snags were can be

00:43:37.119 very helpful because if the same snag shows up repeatedly

00:43:42.160 then that could potentially be an option for reducing your maintenance load

00:43:48.720 so that's what i would call our data driven targets for maintenance load but we're going to talk about a few and

00:43:54.079 that's just going to be one of them so now we're back here prioritizing the high leverage changes

00:44:02.079 high leverage changes are changes that produce the largest reduction in maintenance load for

00:44:09.440 upfront effort and that's what we need if our team is bailing water fast right if we need

00:44:16.960 maintenance load to come down quickly we need to know what these high leverage changes are

00:44:25.200 so there are a couple things we're going to go through five priorities and the very first one is

00:44:30.240 going to be removing feature bloat wherever possible

00:44:35.520 feature bloat are features that are not pulling their weight

00:44:41.119 in customer value or client value relative to the amount of maintenance load that they add to our code base we

00:44:47.200 talked about how every feature adds maintenance load every feature adds maintenance load so if you have features

00:44:53.359 that are not benefiting your customers or your clients then they are costing

00:44:58.720 you in terms of time in terms of effort in terms of developer morale it's

00:45:03.760 important to keep an eye on that that's why i was really excited about that answer

00:45:09.040 in our easy retro regarding talking with product about what the changes are going to be

00:45:16.720 because it can be helpful to talk to product about which features

00:45:22.319 are causing a lot of maintenance load now it's not really products job to figure

00:45:29.599 out what features to remove they're focused forward they're focused on adding things they're focused on making

00:45:35.599 more stuff that works for your customers your clients they're not necessarily keeping track

00:45:41.280 of what features might be removed so you may have to help them here hey how many support requests are we getting for our

00:45:47.440 email client how many people are using our email client is that something like is our app

00:45:53.920 if our app's supposed to do one thing well and what we're building is not literally an

00:45:59.440 email client maybe having an email client embedded in it isn't the best idea

00:46:04.960 or maybe there's a feature that was really important back when there was a relatively small number of people using

00:46:12.400 the product and now that more people are using the product then that feature is not relevant

00:46:18.560 anymore in fact even if this isn't the case i found that a very valuable persuasive

00:46:24.079 technique for talking to folks about these kinds of things is you were totally right to add this

00:46:29.200 feature back in the day because of xyz xyz has now changed and so now you would

00:46:35.440 be right to allow us to remove this feature and that way you're not accusing anybody of anything

00:46:41.520 and often it's even true so that's what i mean by make features

00:46:46.880 earn their keep you want your thing to do what it is

00:46:52.079 supposed to do very well and it's going to reduce drag on making your thing do what it does well to not

00:46:58.640 have to maintain all this stuff that's tangential to that that it does poorly or adequately or passably but it's

00:47:04.240 taking up a bunch of your time the fewer features we have the more time we regain

00:47:12.000 to add stuff right and that is why importantly removing features does not

00:47:17.119 count as maintenance load because it is important enough to do that it should not be

00:47:24.400 it should not affect whether you decide to do it because it is so valuable for

00:47:29.680 maintenance load in the long run so that's removing feature bloat second

00:47:34.960 one addressing documented ups that repeatedly blow up time estimates so here's what i mean by this

00:47:41.839 suppose that we've got a week and we don't have to we don't have any future deadlines in this week

00:47:47.599 what are we going to do with it suppose we even call it a refactoring week this is where we can go into our

00:47:53.119 retros into our incident reports into our estimations and our understanding of why those estimations were off and find

00:48:00.400 empirically backed changes that we can make that will reduce our maintenance load

00:48:06.319 going forward so this is that data driven part that we were talking about a little bit earlier

00:48:11.920 now uh in order to be able to do this we need to be recording

00:48:16.960 the reasons the things took longer than expected that can sometimes pose a social challenge on the team because

00:48:22.800 people feel personally responsible if something took longer than expected my recommendation here is to emphasize in a

00:48:30.000 record like this that you're not trying to hold individual developers accountable you don't even have to put developer names on it what you're trying

00:48:36.400 to do is hold your system accountable for its reliability so that developers

00:48:41.920 can make accurate estimates about it does that make sense

00:48:47.040 so we've got two priorities so far first of all remove feature bloat bring down the number of features that you are

00:48:53.280 maintaining as fast as you can and your maintenance load will come down second

00:48:58.400 things that you have empirical evidence are slowing down and frustrating your team

00:49:03.920 seems like a good set of priorities so far right suppose we've done that what's next

00:49:10.319 we can address abandoned houses at the point where a change is needed so

00:49:16.240 we talked about abandoned houses earlier repos people don't want to touch features that nobody's sure how they

00:49:21.359 work legacy stuff that nobody really knows intimately on the team anymore

00:49:26.720 the thing about these pieces of the code base is that they're often big enough that addressing the whole thing right away is probably not realistic

00:49:35.760 so instead we address them at the point where a change is needed we acknowledge that what developers are

00:49:43.760 going to have to do in order to make this change is effectively rebuild context that has been lost there's a

00:49:50.240 term that i like to use for this i call it forensic software analysis

00:49:56.079 this is going into a code base where we have lost context and attempting to recover that context

00:50:02.240 it's theoretically similar to what an archaeologist does on a dig site or what

00:50:08.720 a the reason it's called forensic software analysis is because it's similar to what a forensic analyst might do at a crime scene right take clues

00:50:16.559 from what is there to figure out what happened here it's something that we'll need to be

00:50:22.079 able to do in code bases it can take long it can be frustrating and it can be slow but it's not less of those things

00:50:28.079 because we're trying to avoid it like it's a game of the floor is lava right if we can explicitly acknowledge this

00:50:35.280 skill value this skill incentivize this skill on our teams then folks will get better at it and it won't be quite as

00:50:42.000 hard even if it is inherently hard it will not be quite as hard

00:50:48.079 the other skill that we can incentivize is context transfer which is if somebody comes back from forensic software

00:50:54.079 analysis and they've learned some things about this code base we make sure that they're

00:50:59.280 either putting the code in place putting the tests in place putting the documentation in place sharing pairing with other people

00:51:06.480 potentially sharing context through review to safeguard this context from getting lost

00:51:12.880 again so

00:51:18.400 now let's take a step back we've got our first two priorities those tend to be what i would refer to as the emergency

00:51:23.440 priorities that's what's going to bring down your maintenance load enough hopefully that your team will be able to

00:51:28.960 breathe some then we start addressing some of these things that we've been putting on the back burner because we've been so

00:51:35.040 overwhelmed with our maintenance load things like addressing abandoned houses

00:51:41.680 so our next priority might be looking for places where code flexibility does not match

00:51:48.000 how often that code actually changes

00:51:53.920 so we talked about an example of this right we're drawing up your code makes that

00:51:59.200 code harder to change in the event that we only want to change it in one of the places where it's used

00:52:05.200 it's not uncommon for developers to make inaccurate bets about the way that code is going to change in the future right

00:52:11.599 and that's just part of the job it's part of we're human we make mistakes we can't

00:52:17.440 see the future we didn't have the data the data told us one thing and then it told us something else the product

00:52:22.480 changed the whole company changed we did a whole reorg all kinds of things can happen that result in the code base not

00:52:29.839 having flexibility in the right places but maybe it's something that's going to take a relatively large upfront

00:52:35.920 investment of time to fix down here at your fourth priority is your opportunity to do that because

00:52:42.720 these are the kinds of things that require a relatively high upfront investment as we go down this list

00:52:48.480 hopefully our uh at the beginning we want the upfront investment to be low and the

00:52:53.920 return on that to be high because we're trying to get maintenance load down fast right so as we go down this list usually

00:53:01.920 either the return on investment is going down or it's becoming longer in time frame

00:53:07.839 or the initial investment is going up that's what's happening with this one the initial investment might be high

00:53:14.400 but the return on investment can also be relatively high because particularly if what you're doing

00:53:19.680 is rearranging your code base to put the flexibility in the places where you are changing your code a lot right now

00:53:26.640 then this is the kind of thing that's going to make adding features take less time maintaining features take less time

00:53:32.480 so that your team has more bandwidth for both of those tasks

00:53:38.559 so that's this one changing the code base to put the code flexibility where the code is changing now might be a high

00:53:45.119 up front investment but has meaningful returns in the long run

00:53:50.480 and finally equipping engineers to suggest streamlining options so

00:53:57.359 somebody mentioned this one inside of the other examples uh the other examples column one are

00:54:02.720 easy retro essentially being able to have a conversation with product

00:54:08.079 about exactly what the feature needs to do and whether there might be a simpler way to do it compared to

00:54:14.960 the given approach the reason that this one is number five

00:54:20.000 is that this one does tend to take a fair amount of upfront investment not necessarily in the code itself but in

00:54:27.599 your relationship with product and the trust in that relationship

00:54:32.880 because without that trust it's not easy sometimes it's not even possible to go to product and say

00:54:38.960 something that sounds like we're not going to build that right

00:54:45.040 generally relationships that allow for this kind of conversation are the highest upfront

00:54:50.640 investment they're higher up front investment than a big refactor they're often a higher upfront investment than building something from scratch i've

00:54:57.119 seen a number of rewrites that probably should have been a conversation with products about something that already existed

00:55:03.040 but that seems like the lower uh upfront investment route

00:55:12.640 i'll use an example here to help drive home the point so i work

00:55:18.880 on a mobile app i maintain this mobile app that allows volunteers such as

00:55:25.599 yourselves to assist with scientific research research so for example we'll get four million images back from one of

00:55:32.319 the rovers on the surface of mars and the research team that's analyzing those images for signs of water having been on

00:55:38.640 the surface of mars at some point can't go through all of the images in realistic time frame say there's only

00:55:44.799 four of them right but what's relatively easy for them to do is put together a little field guide

00:55:50.799 that describes how to tell if this image contains signs

00:55:56.160 that water might have once been on the surface of mars and then volunteers come along and they it's essentially like

00:56:01.440 tinder but for scientific research so it's cool it's called the zooniverse and

00:56:07.359 uh there's one task inside of that mobile app that allows you to draw boxes around things this is helpful for a lot

00:56:13.359 of our wildcam footage so for example we will have a project on there with motion

00:56:20.160 activated cameras set up in the serengeti desert or something like that and when an animal runs into frame it

00:56:27.760 takes a picture but we want to be able to identify all of the different species that are in these pictures and so we ask

00:56:33.599 folks to draw a rectangle around the different things that they see in the picture and then identify what they are

00:56:38.640 this rectangle drawing task has two modes the first is insert mode where you can add rectangles and change their

00:56:44.319 shape the other one is delete mode where you can delete the rectangles if you thought you saw something but decided

00:56:50.160 you didn't so we had this code for deleting rectangles and it was

00:56:56.400 working on ios and it was not working on android and the way that this delete

00:57:01.760 functionality worked was that you would get in delete mode the way you knew you were in delete mode was that you would get a little x in the upper right hand

00:57:08.559 corner of each of your rectangles unless the rectangle was up against the right edge of the frame in which case it

00:57:14.079 would show up on the top left unless it was against the right edge and the top and then we would put it in the

00:57:19.440 bottom left or if it touched all four then we would

00:57:24.559 just stick it somewhere and like pray the reason this wasn't working on

00:57:30.640 android was that it had been done i guess on an ios simulator and the way that ios figures out the locations of

00:57:37.119 things is a little bit different than the way that android figures out the locations of things we were using absolute locations and so the integer

00:57:44.079 that we used to represent locations on ios wasn't the same for android wasn't working so

00:57:51.760 my job was to fix this my job was to make the delete functionality work on android what i could have done

00:57:57.440 was gone into each of those four conditionals and added another conditional inside of

00:58:02.799 each one if ios do what you were already doing if android do something else

00:58:08.640 so then we would have had eight separate conditions two levels of

00:58:13.680 conditionals right it turns out that the ui of this

00:58:20.400 particular feature also was not that great and here's why the rectangle was green with the little

00:58:27.520 x in it and the images that we were using for testing were all black images

00:58:32.880 so a green x with transparent background shows up on an all black image

00:58:40.640 when you put it on an image of grassland

00:58:45.920 nobody can find the delete button so we're getting all of these like classifications in and it's rectangles

00:58:52.160 with nothing why is it nothing well probably people couldn't figure out how to delete the rectangle so

00:58:57.920 there were a number of things that could have been improved about this experience and so the designer and i sat down and

00:59:03.200 figured out that what we wanted to do was make the rectangles easier to delete and hopefully make the code simpler as

00:59:09.440 well so what we ended up doing was we already had insert mode and delete mode right people aren't trying

00:59:15.440 to do anything other than delete and delete mode and so we don't have to make it harder for them to find the delete button what we can do is rather than

00:59:23.200 have only one corner delete the rectangle in delete mode now instead of the rectangles being green we're going to

00:59:29.599 turn the rectangles red we're going to give them a little bit of a pink sort of inside so that it is obvious that we are

00:59:36.160 in delete mode and then if you click anywhere on the edge of the rectangle it will delete that rectangle

00:59:44.079 because the code for identifying where the rectangle was was more robust than the code for identifying where the

00:59:50.160 delete button was this got rid of the issue and we were able to eliminate all of the conditionals

00:59:55.599 and just have one straight code path plus ship a ui that was a lot easier for

01:00:00.880 people to use but if we were in an organization where i were not able to have that

01:00:07.119 conversation with the designer then we would have been stuck at the first option eight conditionals for this feature that just does not work that

01:00:12.960 well for our volunteers in the first place and so that's why i say that equipping

01:00:18.000 engineers to suggest streamlining options can be an extremely powerful way

01:00:23.280 to get simpler code and potentially better functionality it is often only at the

01:00:29.280 very low level of implementation that you face a trade-off between the simplicity of the code and adequate

01:00:34.559 functionality but the developers have to have the ability to pop up that level and in order to do that you need trust

01:00:40.480 with your design team or with your product team so that's why this one is fifth the

01:00:46.480 return on investment i think is high but the initial investment also very very high

01:00:54.240 so those are the five priorities remove feature bloat address documented holdups

01:01:00.240 address abandon houses make changes to where the code flexibility is located

01:01:06.559 and have engineers suggesting streamlining options with product and design

01:01:12.240 this is going to help you a lot with your maintenance load folks feel like experts in addressing

01:01:18.880 technical debt yet yeah yeah are you ready to test that

01:01:24.480 theory out you want to try something okay okay so

01:01:29.680 we're going to do an exercise now so this is an individual exercise and here's what i'm going to tell you

01:01:34.720 i want you to pretend that you are now a developer in fact i want you to pretend that you are the lead developer

01:01:41.520 such that what you say goes on a team responsible for making restaurant

01:01:46.720 reservations your application makes restaurant reservations that is what it is supposed to do well

01:01:52.559 allow people to reserve their spot at restaurants now what i'm going to do is i'm going to hand you six

01:01:58.319 tickets i'm going to give you time to read these tickets so don't worry but they are all for the restaurant reservation application what i'm going

01:02:04.880 to ask you is first of all which of these items would you address

01:02:10.960 second of all how would you address them and third of all how would you

01:02:16.160 prioritize those projects relative to one another i'm going to give you time to do this and then we're going to go over it as a group but this is how this

01:02:21.760 is going to work at the bottom of the slide you see a link it says ticket priority poll

01:02:27.520 and i want to show you this ticket priority poll so this is what you're going to fill out

01:02:32.960 what you're going to do is prioritize the issues starting with number one being the highest priority descending to two being

01:02:39.920 the second priority so for example if i wanted to fill this out and i thought that this feature was the highest

01:02:44.960 priority i would do that if i then thought that this feature was the second priority i would fill in the bubble for

01:02:51.520 number two then if i thought that this was the third highest priority i would do this

01:02:58.480 now you don't have to go all the way to six you can leave blank the ones that you would not

01:03:04.720 address and so if i don't think any of the others need to be addressed i can leave them blank

01:03:10.079 okay so this is how this works what we're going to do after

01:03:15.760 i give you some time to work through this is we are going to go to the charts that show me what your

01:03:21.920 collective prioritization are for all these issues and then we're going to talk about how to address them in order

01:03:27.839 of collective priority so this is what we're going to do this is the exercise on the next slide

01:03:36.960 these are the six tickets these are the six tickets that you are

01:03:42.400 going to prioritize and then we are going to go through them in collective priority order and talk

01:03:48.400 about how to address them does that sound like a plan awesome so what i'm going to do is i'm

01:03:54.240 going to give you 10 minutes and then at three o'clock

01:04:01.839 we will go over in a large group how to address these tickets good

01:04:07.440 excellent how are your answers comparing to your neighbors

01:04:13.520 we still have three more minutes you got plenty of time see what they say

01:04:20.880 it'll be our own higher level version of the semicolon wars

01:04:26.400 the priority wars

01:04:35.520 let's see if i can show you

01:04:42.920 106 responses holy cow

01:04:48.480 we got high participation in here these will definitely be the right oh i

01:04:54.960 see some more 108 responses 109 responses

01:05:06.000 good call thank you excellent

01:05:17.119 thank you 112 113

01:05:24.400 114 115

01:05:30.799 what do we think is 115 gonna be the number

01:05:37.440 leah said there's like 120 seats in here

01:05:43.119 116.

01:05:51.280 all right let's take a look at some of these

01:05:56.480 responses shall we this is you this is your responses so the way this works

01:06:02.839 is 117 the way this works

01:06:08.960 is that the blue bar represents top priority this is how many people put that as the top priority and the red bar

01:06:16.000 is the second priority the yellow bar is the third priority i'm

01:06:22.640 not sure whether google colors it because those are the colors of ribbons and like horse shows and stuff like that

01:06:28.640 but it is helpful for me to remember anybody do like a sport or a thing where

01:06:34.720 you have blue ribbons red ribbons yellow ribbons i did rodeo when i was a kid and so that's the way that you do that

01:06:42.799 all right so let's take a look at some of these priorities and the way that i'm going to do this is

01:06:50.000 i'm going to be arbitrary about it but i'll explain to you how um so here we have a couple things right um

01:06:57.280 let me see if i can if i zoom out i'll be able to see all the labels on this so i've got email restaurant

01:07:02.799 recommendations for oh i can i can do it by uh hovering okay so it looks like the

01:07:08.480 top two priorities from a collective perspective are social authors is handle dependent

01:07:14.960 44 people put that as top priority and 38 people put that as a second highest priority

01:07:21.760 and time zone adjustment 40 people put that as the top priority and 47 people put that as a second

01:07:28.319 priority this one is close so we're going to talk about social auth being handle dependent

01:07:36.880 first since it has the highest number of first priorities out of these two what i'm going to do is

01:07:45.359 ask why was this social auth handle dependent one your top priority if it was your top

01:07:51.760 priority can i have a show of hands would anyone be willing to speak to that why was this one a high priority all

01:07:57.200 right we've got one down in the front hang on we'll get you a mic seem to be the one generating the most

01:08:02.240 actual problems like 12 emails to support the month is doesn't sound like a lot but i don't know how many uses we

01:08:08.240 have but all the others seem to be less impactful right yep we have a measured

01:08:14.160 impact of this one we're getting people are actually complaining about this working it's something that has to work

01:08:19.359 in order for our thing to be able to function right yeah okay

01:08:24.400 so this one is as a reminder for y'all

01:08:32.799 we probably get a dozen emails a month about this now to logistics the authentication code

01:08:40.560 is in the api repo which is an old django app no one currently employs here no employed here knows much about it the

01:08:46.560 documentation consists of how to get it running on a machine but there's no endpoint don't documentation no swagger

01:08:52.080 no troubleshooting guide there are unit tests but no integration or functional tests

01:08:58.159 how might we address this folks have thoughts on how we might address this show of hands

01:09:03.679 all right we got on the stripe here or anywhere but um so how to address this

01:09:10.080 it might depend a bit of course but i would even think given sorry

01:09:15.520 given the requirements it doesn't seem like a very complex thing to solve so

01:09:20.880 maybe it's even worthwhile to get rid of this old django application and write it in a way that's more

01:09:26.880 consistent with the way we are well the good practices that we just discussed or the best practices that we just discussed

01:09:32.880 and so we actually killed two birds with one stone we solved this user problem and we get rid of this legacy techno

01:09:39.359 technology that and certainly after finishing this or the whole team now knows how to

01:09:45.199 this works or ideally of course we could potentially do that completely rewrite the thing that's i

01:09:51.040 call that the nuclear strategy it's an option sometimes it makes sense anyone been part of a rewrite show of

01:09:57.520 hands been a part of a rewrite yeah they're expensive very very high up front investment might

01:10:03.280 make sense in some cases does not necessarily make sense in all cases where we've got old code right we might

01:10:08.719 not necessarily be able to rewrite it um thoughts on what else we might do i see

01:10:15.280 one over here maybe uh hi hi so this sounds like an abandoned house that

01:10:20.640 you described so uh nuclear rewrite could be an option but probably you'd want to focus on

01:10:26.960 forensic analysis to understand how the thing currently works yeah uh learn about how it works

01:10:33.360 and transfer that to the team so it's no longer so scary right yeah definitely an abandoned house here nobody knows how

01:10:39.840 this code works tests not particularly instructive unit tests

01:10:45.199 super instructive when you've got complex logic happening within the bounds of one class but if you're talking about an entire

01:10:51.600 service integration test might be more instructive on what's supposed to be happening this codebase doesn't have that

01:10:57.120 so some forensic software analysis might be in order and some context transfer

01:11:02.480 maybe maybe the first step is writing an integration test for that service and

01:11:07.679 using that as the driver to figure out how it's working at some point

01:11:12.880 and then or using fixing this as an opportunity to figure out what's happening such that

01:11:20.080 if we're going to keep this if we don't end up rewriting this further maintenance will be a little less painful

01:11:26.400 all good options excellent all right so let's talk about another one second priority here this time we're gonna go

01:11:32.080 to the other one time zone adjustment would anyone like to speak to why this one was a high priority

01:11:39.040 thoughts on this

01:11:46.480 hello my name is oscar hi oscar um i chose uh that one as a highest priority because

01:11:53.600 say if it does work you're going to have two parties that are going to be unhappy with the

01:11:58.960 situation so as opposed to the authorization if it

01:12:04.159 doesn't work it doesn't go through so you don't have two disgruntled parties you only have one

01:12:09.440 um so that one's i feel like it's more relevant i see so there's multiple disgruntled

01:12:16.800 parties here you've got the restaurant's not going to be happy because they didn't get a reservation which is the whole reason

01:12:22.400 they pay you and uh people trying to make a reservation aren't going to want to use you in the

01:12:27.520 future seems like a pretty high priority feature what

01:12:32.960 what might we do about this thoughts how do we want to address this time zone

01:12:39.360 adjustment feature as a reminder

01:12:46.239 yeah go ahead as a reminder this is 92 percent of our members live

01:12:51.280 in the same time zone as our database hosting so the adjustment code doesn't run for those 92 percent of people but

01:12:57.600 for some reason it consistently mishandles time zones that are behind the database time zone so if the

01:13:03.600 database is centered in chicago then it's not working for folks in california

01:13:10.000 it shows all the reservation slots as earlier than the restaurant intended in those cases it adjusts to time zones

01:13:16.159 ahead of the database time properly this code works as long as the database time zone

01:13:21.679 is uh behind the time zone of the end client

01:13:26.960 so maybe just drop the feature drop the feature that

01:13:32.640 is an option we could not support time zones such that all of the times are shown in utc

01:13:37.920 meridian time we could people will probably have to translate

01:13:43.199 it back themselves it's an option we could say we're only we will from now

01:13:50.080 on we will only work with restaurants in the database time zone so that's an option we can do that

01:13:57.840 but it is yeah but i mean well i bet more like 92 percent of people live in the same

01:14:03.920 time zone so just keep it on that one time zone ah yeah so 92 of people live

01:14:08.960 in the same time zone so we could keep business on that one time zone that is an option that's a thing that we could limit it to

01:14:15.920 and it would depend you know on on the future of the business does the business want to expand into other time zones is it cool staying in the local time zone

01:14:24.719 um but uh 92 is a lot it's easy and then and product very

01:14:32.000 often will do this too there will be a focus on what the majority on the majority use case and

01:14:38.000 the majority use case can be useful for getting something out the door

01:14:43.120 usually for your mvp the majority use case is all right as we start to try to build a robust application that's going

01:14:48.560 to support change and growth and team changing and all those kinds of things it becomes very important for us to

01:14:53.600 understand the primacy of the people who are using our application at the margins and a lot of visionary

01:14:59.520 application development work comes from considering folks that the market has not considered thus far

01:15:05.040 my favorite example of this is the 2007 iphone speech because everybody talks about it and miscontextualizes where it

01:15:10.880 came from but there was this vision of steve jobs was his visionary and he came up with this amazing device and he

01:15:16.159 completely changed phones for the remainder of known history so far well

01:15:21.360 a lot of the things that were visionary about the iphone got put into the iphone after they were

01:15:26.800 acquired by apple from companies often that were founded by and for folks with

01:15:32.400 disabilities this is fundamentally an accessibility device

01:15:39.520 the multi-touch capacitive screen completely changed the way that phones work because you're no longer beholden

01:15:45.280 to those buttons right and that functionality came from a

01:15:51.520 company called fingerworks that was focused on allowing human computer interaction for

01:15:58.000 folks who were losing or didn't have fine motor skills apple acquired the company in 2005 and put the technology

01:16:04.000 into the phone a lot of the most visionary software ideas come from centering folks at the

01:16:10.880 margins and the reason that i say that is because i want to caution folks about

01:16:17.360 focusing on the majority when you've only got you know some when it seems like a relatively

01:16:24.239 small percentage of folks who are using our application under certain conditions we're trying to get an mvp out the door maybe we can't focus

01:16:31.199 there but as the product grows it becomes important to explicitly put our focus there and many of the products

01:16:36.640 that begin with the marginal case in mind end up being the blockbuster visionary products that we talk about

01:16:42.480 for as long as we do now one

01:16:47.600 clever solution that i've heard to the time zone adjustment problem on a couple of occasions is figure out what the what

01:16:54.239 the last time zone on earth is and change the database to the last time

01:16:59.280 zone on earth that way only the code that works ever

01:17:04.400 runs which maybe is removing the feature it's removing the code path that causes the

01:17:09.920 problem so there's that too and um i love it in my experience from a

01:17:16.000 from practitioner's standpoint one does not simply change the database time zone but if

01:17:21.920 that were an option then that would eliminate the code path that's causing the problem right and then we can just delete all that code which would be kind

01:17:27.840 of nice i love deleting code that doesn't work don't you so that's an option

01:17:33.760 all right let's talk about our third priority

01:17:38.800 looks like it's this one there are a number of blues here number of a number of reds here number of

01:17:44.560 yellows email restaurant recommendation to a friend thoughts on why this one's high priority

01:17:56.000 i put this one as top although i'm sort of reconsidering whether it's actually time zones because that's such a bad bug as to make the service useless but this

01:18:03.520 also makes the service useless uh right like all other functionality that we've talked about here is broken when the

01:18:09.520 site is down that is true all of the other functionality on the site is broken when

01:18:14.560 the site is down and it's a useless feature we can remove and it's a useless feature as a reminder

01:18:21.280 our servers crashed three times last year from accounts signing up and spamming people restaurant recommendations

01:18:27.120 besides those incidents the only account that sends restaurant recommendations is the ceo so it's clear whose idea this

01:18:32.960 was uh fun fact unrelated but i want to share

01:18:38.320 it because i think it's funny when we were doing the dry run for this workshop leah pointed out i used to say our

01:18:44.320 servers fell over three times which in the context of restaurants is ambiguous

01:18:52.159 so now it is our servers crashed um how would folks like to address this

01:18:58.960 thoughts how would folks like to address this email or send restaurant recommendations

01:19:04.080 to a friend fija any thoughts

01:19:10.640 i see one in the can we call it the hallway track if it's not the hallway track but it's in the hallway of the workshop track

01:19:18.239 i think you have a couple options um one you can completely delete the

01:19:23.520 feature uh two you could limit it only to the ceo to keep him happy

01:19:30.000 you know get some political goodwill there might come in handy later that's true that's true so one option delete the

01:19:37.280 feature other option don't delete the feature but put a feature flag on it and turn it off for everyone except the

01:19:42.320 ceo's handle could work you know what in certain

01:19:47.520 circumstances that's what you got to do um one time i was telling somebody a story

01:19:53.120 about this in the hallway earlier there was a long story short a decision that we had to make that sounded like it

01:19:58.640 didn't make sense with an application and resulted in a designer needing to make a new icon ask me in the hallway if

01:20:05.040 you're interested and when i told my designer this same designer as the rectangle story by the way

01:20:11.760 her response to me in email format was one line and she was like please tell me

01:20:16.960 this is a constraint and not a goal and uh

01:20:22.320 it was it was indeed a constraint but that's what i would think of if i saw code like this that was like if username

01:20:29.360 equals ceo123 display button restaurant recommendation

01:20:34.800 to friend that'd be my first question for that client please tell me this is a constraint

01:20:40.480 all right so that's that one let's see what else we got what else we got hey

01:20:46.320 chelsea we've got one more oh okay so i think

01:20:52.239 the point of that story is obviously that we should delete the send recommendation feature but

01:20:59.040 i think it's fixed to an architectural problem like people sending too many emails

01:21:04.480 should not bring the entire service down there should be a job queue that's independent of your home page

01:21:10.960 so you can just delete the feature and move on you gotta have an architecture review

01:21:18.000 potentially there may be value in figuring out how uh how this happened because it may

01:21:24.080 speak to a larger architectural problem with the application so that is a potential

01:21:30.239 uh something we might potentially want to look at now if the situation is

01:21:36.159 you're getting ddos specifically having to do with people being able to use an email client in your application and you remove the fact that people are able to

01:21:42.239 use an email client in your application then presumably at that point you've removed the vector for attack right

01:21:48.800 but if this send restaurant recommendation to a friend feature is uh on top of functionality that you also

01:21:56.159 have in other portions of the application then it's an indication of a vulnerability across the application right something that we might want to

01:22:02.239 keep in mind so that's a good point thank you for bringing that up all right let's

01:22:08.400 talk about our next priority which looks like it's going to be between these two

01:22:15.199 i see three votes for object-oriented restaurant code being the top priority and three

01:22:20.560 over here okay let's try six for a second six for second everybody agrees

01:22:28.960 20 for third and 12 for third so let's say this object-oriented restaurant code

01:22:34.159 thing is the third priority for folks who saw this as a high priority would someone like to talk

01:22:39.360 about why they saw this as a high priority

01:22:45.280 as a reminder the code for restaurant behavior is written in an object-oriented fashion with each

01:22:50.880 restaurant type in its own class last year we added one new type of restaurant to do it

01:22:56.960 we subclassed restaurant and no up the reservation methods we also added six new functionalities to restaurants

01:23:04.639 so thoughts on the priority why should we address this one

01:23:12.639 i know three folks had this at the top six folks had this as second thoughts

01:23:25.040 uh i figured this was i'm not sure what position i put it anymore but i think i put it on the top three at least so for

01:23:30.639 me the consideration was that this sounds like something that works now but that will actually cause us a lot of

01:23:35.920 pain in the future because it seems like there's a lot of features being added here that might also be true for the upcoming

01:23:42.560 period that there might be even more features and this is some sort of a disaster waiting to happen um so might something that we want to

01:23:48.800 want to address right now when it's still manageable or when it seems manageable before it becomes out of

01:23:54.080 control and we are back in the social authors handle dependent where we have an abandoned house and no one knows how it works anymore

01:24:00.400 that was my consideration okay so it works now but in the future

01:24:06.239 this could potentially cause a lot of problems right we've got code here that is

01:24:11.360 flexible in the direction of types it's easy to add new types of restaurants but we're not adding types of

01:24:16.960 restaurants very often we're adding functionalities all the time and because we've put all of our code flexibility in

01:24:23.120 adding types of restaurants we can't add functionalities as easily

01:24:31.360 so and we're even ending up with it you know there's code smells in this we're subclassing things with no ops that's

01:24:37.120 usually an indication that our inheritance structure isn't actually representing the thing that we would like it to be representing thoughts on

01:24:44.320 how to address this anybody okay we've got one here in the

01:24:50.560 middle

01:24:58.239 um backing up a step it sounds like this is one where working with the product group to find out what the plans in the future are because even adding six

01:25:05.120 functionality in a year maybe that's not enough to really make it worth the effort so i really want to know like

01:25:10.639 what are the what's the roadmap for the next year yeah that might be helpful to know how are these

01:25:16.719 like is this rate of change going to continue is this rate of change gonna um is this

01:25:22.239 gonna flatten in the past year this has been a particularly difficult one for teams over the past two years because so

01:25:27.600 many things changed for talking about a restaurant reservation app the way that people interact with restaurants has changed so much in the past two years

01:25:34.159 that there's really more information needed here to figure out what might necessarily be the case now if we've got

01:25:40.480 a situation where our malleability isn't lining up with the changes we're making and those change patterns are going to

01:25:47.040 continue we might be in a situation where doing a refactor towards more functional

01:25:53.360 code towards something where it's easier to add restaurant functionalities rather than restaurant types might be in order

01:26:00.239 it would be a high up front investment but if those changes were going to continue into the far future it might be

01:26:06.239 worth it right all right let's chat about our next one

01:26:12.719 we've got two more to go and i'm going to say this one um this one got a lot of votes for being last

01:26:18.719 priority so we're going to do case sensitive api endpoints

01:26:24.080 thoughts on the importance of this one got a couple votes for first here

01:26:32.080 as a reminder this is case sensitive api endpoints to fetch reservations from our api the

01:26:38.159 endpoint is a get request to an endpoint ending in slash capital r reservations little r reservations doesn't work we

01:26:44.880 have three clients basically our mobile apps and our web front end all the developers roll their eyes when they

01:26:50.400 have to explain this to other developers hey there oh did you guys hear me so i thought this fell kind of under the

01:26:57.199 second priority that we mentioned you know issues that would increase kind of like time like i guess uh limits within a

01:27:04.719 retrospective so like how long it sounds like you have uh kind of like junior developers getting

01:27:10.480 confused already based on why you know the api doesn't work when it should be

01:27:15.520 like you know case insensitive it also seems like a straightforward fix just make the api case insensitive so

01:27:21.040 the existing functionality still works and then you remove this obstacle for developing in a speedy manner

01:27:27.760 yep so we've already got people potentially getting a little bit confused about this one and these endpoints

01:27:34.719 you know developers roll their eyes when they have to explain it conveniently we're not in a situation where we have a lot of clients using this

01:27:41.920 so even if we're not in a situation where it's breaking anything yet

01:27:47.120 we don't have that many clients to change and so theoretically it's a relatively low

01:27:52.960 upfront investment to change right and we

01:27:58.000 want our early changes to be as low investment as possible so one of the

01:28:03.280 arguments that i've heard for this one initially when i created these slides i thought of this one as relatively low

01:28:08.639 priority and the reason that i thought that way was that this is not something that external clients are getting

01:28:14.960 confused about it's only internal clients and the other reason i thought it was low priority was that developers

01:28:20.560 were rolling their eyes when they explained it to other people but that meant the developers knew the situation and they were explaining it to other

01:28:26.480 people so i wasn't too concerned about it from a priority standpoint but over the course of teaching this workshop a

01:28:32.880 couple of attendees have pointed something out to me that's made me think that this one could potentially go a little higher on the list which is that

01:28:39.679 i wasn't necessarily taking into account developer morale and this is one that

01:28:44.880 uh theoretically should be a pretty quick change

01:28:50.320 not only would it be a pretty quick change it's a change that might potentially make sense for somebody

01:28:55.520 who's new to the team and that would be a big confidence boost to be able to make this change that's going to make things less frustrating

01:29:02.080 for all of the other developers on the team without necessarily requiring a whole lot of changes to the code so

01:29:08.400 taking into account sort of developer morale i think this could make sense higher up the list depending on your

01:29:14.719 team because if your team has felt mired in debt for as long as you've been there

01:29:19.920 maybe even a little win like this one is going to help them gather the resources

01:29:25.760 that they need from an interpersonal perspective to be able to tackle some of the bigger changes

01:29:33.280 all right so we have one last one the absolute winner on lowest priority

01:29:38.719 which is functional navigation thoughts on the priority level for this one

01:29:44.639 all right we've got one here as a reminder our new senior software engineer came from writing closure and

01:29:50.159 he would like to experiment with a new functional approach to navigating between screens on our mobile apps all

01:29:55.679 right so i stacked the deck a little bit on this one with that story earlier

01:30:01.040 whoops yes so for me i put this at the highest priority um but i think the argument

01:30:08.480 mostly kind of comes in terms of what type of developer you are in terms of whether or not your customer obsessed in

01:30:14.080 terms of where is our majority customers using these kind of market shares or if you're um the other side where you

01:30:22.719 kind of hate on your customers so to say uh i don't know how to call that uh but regardless of the fact the functional

01:30:28.960 aspects is that nowadays we're trying to componentize our ui and various things like that

01:30:34.880 so ensuring that you're not losing out any potential market share say for example facebook switching for

01:30:41.360 to mobile when mobile became the biggest market share they had to hire or redesign their entire system to be able

01:30:48.080 to cater to that so i place it this to the highest perspective because this

01:30:53.600 actually affects our customers and being able to kind of re redesign and build new components on top of the ui that you

01:30:59.840 already have is the will will give value to the customers in the

01:31:05.360 future all right i can appreciate that thoughts

01:31:10.719 on how we might address this

01:31:18.159 i think that this is the lowest priority not because i disagree with your argument but

01:31:25.120 because to me this is a sign that you're adding more tech debt you're adding harder stuff to

01:31:31.760 maintain people don't know it there isn't a problem there are actual problems here that people are encountering

01:31:37.440 or you know like the team itself

01:31:42.560 and this isn't a problem yet and we're not sure it's going to be a problem so it doesn't seem like

01:31:49.360 it's worth addressing and i also think bringing the new senior engineer more in line with like what the

01:31:56.320 team is already doing probably makes more sense than immediately being like hey go do your own thing

01:32:02.480 just from like a come join our way perspective

01:32:09.440 yeah i appreciate what you're talking about with regard to what might be valuable for customer retention in the future and those kinds of things those

01:32:16.000 are absolutely things that i would want to consider in adding a feature like this so i appreciate that you're bringing them up

01:32:22.480 given this description it seems like those customer those customer acquisition and customer

01:32:29.120 retention things aren't necessarily factoring into this developer's

01:32:34.320 uh calculation of why they want to do this um what we've got here is

01:32:40.880 well we'll see somebody over there well i kind of agree that it's definitely still the lowest on my

01:32:46.639 priority list i would be willing to it's it's still important for like with new developers to also be

01:32:52.880 trying new new style because they're made sure not that this is actually like an ideal style rolling forward

01:32:58.719 uh that being said i'd probably do a time greet like make sure we can pull like be willing to pull it out if we we

01:33:04.719 find out that it's actually burning us like being able to drop that feature really quickly but at the same time

01:33:09.840 um i i do believe in like the controlled experiment of like letting that code be

01:33:14.960 that part of the code base grows like you know if we can do contain the experiment it seems like at least worth

01:33:20.080 trying to if other if other developers have appetite if it's only this guy yeah bucket but

01:33:26.239 so there are definitely opportunities there's opportunities for time boxes for hack weeks right again a lot of products

01:33:32.159 that companies ended up basing a lot of their strategy on came out of hack weeks because it was tough to socialize something right and uh potentially this

01:33:40.400 might fall into one of those that's a possibility it's something um

01:33:45.679 it brings up you bring up a good point with regard to whether it's just this person or other people often what happens with pet refactors is it was

01:33:52.960 either not socialized with the rest of the team or it was unsuccessful in convincing the rest of the team both of

01:33:59.679 which are signs that maybe we don't need to be doing this right now the first step is figure out how much of the team

01:34:05.040 could get behind a change like this so socializing those changes is really important

01:34:10.639 another thing that i've had attendees bring up in this workshop before about this one is if he wants if this

01:34:15.920 developer is really interested in switching us to a more functional approach somewhere then we could assign

01:34:21.120 this developer to the purple ticket in which there's potentially

01:34:26.159 a customer focused product focused reason for us to be switching to a functional approach from

01:34:32.400 an object-oriented approach and so that might be something that makes everybody

01:34:37.440 happy of course that just like with any technical solution is something that you might have to socialize but that could

01:34:42.880 potentially be an option here that i've appreciated folks bringing up in the past

01:34:49.600 you made it you made it through the hard exercise congratulations give yourselves a hand for that i'm very impressed i'm

01:35:00.800 happy to take questions although i think i'm about to be out of time but one thing i want to point out is that i have a feedback form for you right here on

01:35:07.679 the last slide this will link you to a google form i am very very serious about improving

01:35:14.080 on my workshops and so i would really appreciate it if you could answer those questions it's going to help me make this workshop better it's going to help

01:35:20.560 me expand it for the future there's also an option there to put in your email address if you would like to hear about

01:35:25.679 future expansions of this workshop so with that i really appreciate your time

01:35:31.280 but uh i'm happy to let you go for the day and stick around for questions

RubyCond 2021 - Workshop: Tackling Technical Debt: An Analytical Approach

RubyCond 2021 - Workshop: Tackling Technical Debt: An Analytical Approach