00:00 have you ever started working on someone
00:02 else's code and taking a look at it and
00:04 your first thought is I don't understand
00:06 this I'm gonna rewrite it it's not
00:08 written correctly well stay tuned
00:11 because today we're going to talk about
00:12 should you refactor someone else's code
00:16 when you don't understand it
00:25 hi I'm Jamie and I want to help you stay
00:28 calm on your software projects not get
00:31 stuck and keep growing and have a
00:33 healthy balance between work and your
00:36 life today we're going to talk about the
00:39 inevitable situation almost every
00:41 software developer finds themselves in
00:43 at one point in their career which is
00:44 coming upon some code that's difficult
00:47 to understand deciding should I rewrite
00:50 it or refactor it or stick with the
00:53 patterns that are already in place
00:55 earlier in my career when I would
00:57 stumble upon another developers code
00:59 that did something that I had maybe done
01:01 already using a different pattern or a
01:04 different programming language my first
01:06 thing I would jump to was the conclusion
01:09 that they had done it wrong or I need to
01:12 define a way to convince management or
01:14 the team to let me rewrite it or
01:15 refactor it so it would be better and as
01:19 I continued my career and I especially
01:21 got into consulting about a decade ago
01:23 I've talked about that in many other
01:24 videos when I would get on to new client
01:28 engagements and that client that
01:30 company's paying me as a consultant to
01:32 do work for them I wasn't often able to
01:36 take the same risks that I did as a
01:38 product developer and so I had to think
01:40 a little bit more carefully if I'm gonna
01:42 rewrite another developers code am I
01:45 really willing to invest in all that
01:47 means and stick my neck out there if it
01:50 means that I might put myself on the
01:52 hook for overtime in other difficult
01:55 situations so today we're going to talk
01:57 about what are some things you might
01:59 consider and I hope that this helps you
02:02 make a better decision if you are in the
02:04 situation where you're trying to decide
02:06 should I refactor some existing code for
02:09 my preferences or maybe just leave it
02:12 so one of the first things that I think
02:14 you should consider if you're trying to
02:15 decide should I refactor this code or
02:18 not based on my own preferences is how
02:21 much do you think that product or
02:24 feature is gonna be sticking around is
02:26 it gonna be making money for a while or
02:27 is this a dead project or a product
02:29 that's not really generating much
02:31 revenue for the company I've been in
02:34 some times in my career in a situation
02:36 where I'm working on maintaining an
02:38 older software project or I've joined a
02:41 company as a consultant and help them
02:43 change something that's not really
02:45 making the company a lot of money
02:46 anymore and so if I find somebody else's
02:49 code and I go in there and I can't
02:50 really understand it right away and it
02:52 seems really complicated and I think it
02:54 would make it simpler to rewrite it I
02:56 have to think a little bit about is it
02:58 worth me rewriting it so it's easier for
03:01 me to understand if it's gonna basically
03:04 potentially take more time and put that
03:07 company's project at risk when they're
03:09 not even making that much money off of
03:11 it so that's one thing that I would
03:13 encourage you to at least consider if
03:15 you're thinking about refactoring based
03:17 on your preferences the second thing to
03:20 consider is how long do you think it'll
03:22 take you to refactor the code to match
03:26 these preferences or what you want to
03:28 change about it so it's easier for you
03:30 to understand earlier in my career
03:32 sometimes I would run into code and I
03:35 would go in and look at a design
03:36 something that was either in you know
03:39 the user interface or the backend or
03:41 maybe it was in you know the the DevOps
03:43 sort of pipeline of technologies and I
03:46 would think you know I see what they're
03:49 sort of doing here I've done this a
03:50 different way so I think it'll just be
03:53 simpler to use this other technology
03:54 that I'm familiar with but I wouldn't
03:56 spend enough time really trying to
03:58 understand what are they really doing
04:00 what's the full scope of everything that
04:03 that codes doing so that if I decide to
04:05 change it I really know all the details
04:08 including edge cases of what they were
04:11 doing with that existing code once you
04:14 know this it's gonna put you in a better
04:16 position so that if you have to decide
04:18 whether to refactor or not you're going
04:20 to be able to make that kind of cost
04:21 trade-off decision I mean it's very
04:23 common I've seen this
04:25 many times as a consultant where I'll
04:27 join a team and I'll have a certain
04:29 developer on that team who's really
04:31 adamant about you know let's say most of
04:33 the code was originally written in
04:35 JavaScript or C sharp and they're really
04:37 excited about the go programming
04:39 language and they might be like you know
04:41 I want to write this code and go or I
04:43 want to refactor this large section and
04:45 go and when you talk to that person and
04:47 you kind of get to know them a little
04:48 bit more you find out they're just
04:50 really excited about learning go it may
04:52 not be actually a good fit for that
04:55 project or that software task they're
04:57 working on and obviously if you've
04:59 watched any of my other videos I
05:01 encourage more software development
05:03 teams and managers to let their people
05:05 be more free and able to grow but I
05:08 think also we have to be a little bit
05:10 careful you know myself included when
05:12 I'm on a software project that if I'm
05:15 excited about learning a new technology
05:17 I don't try to kind of just shoehorn it
05:19 into a solution just because it's what
05:22 but maybe the whole company or that
05:24 project isn't really the right
05:26 opportunity for me to start using it the
05:29 third thing I would really strongly
05:31 encourage you to consider if you're
05:33 thinking about should I refactor this
05:35 code based on my preferences is what is
05:39 the hardest case of the code that would
05:41 be affected by it so an example this is
05:44 you know let me use something really
05:45 simple that almost everybody runs into
05:48 which is database or datastore access so
05:50 whether your application maybe it's a
05:53 mobile app or it's a machine learning
05:55 algorithm or something you know no
05:58 matter what you've written it in and
05:59 whatever it does usually most code not
06:02 all but most code has to persist
06:04 something to some database or maybe it
06:06 has to use an API to store something it
06:08 has to retrieve data back and underneath
06:10 the covers that could be a database that
06:12 could be you know Hadoop or Cassandra or
06:15 a key value store could be really
06:18 anything but oftentimes when I'm working
06:21 on a team there will be a developer or
06:23 somebody who starts working on and then
06:25 they look at the way let's say data
06:27 storage is being done and they think
06:29 they have a better way to do it and
06:31 maybe they do have a better way to do it
06:33 but they start making that change they
06:36 start that refactoring in a really
06:39 area of the code may be a really simple
06:41 retrieval operation or storage operation
06:44 when it's my opinion personally that if
06:47 you're gonna actually change a pattern
06:49 on a team and refactor something the
06:52 goal should be not to just do it as a
06:54 one-off but to actually make that change
06:56 so that you can refactor it across the
06:58 entire code base now that doesn't always
07:01 make sense there's there's always cases
07:04 where sometimes it's better to have a
07:07 software pattern that only applies to
07:09 one component but most of the time at
07:12 least I find you want to try to keep
07:14 most of your team using somewhat of the
07:16 same patterns so I had to learn this the
07:19 hard way and consulting when I didn't do
07:21 this it really created a lot of problems
07:23 but what I would just recommend for you
07:25 to consider is if you're thinking about
07:27 refactoring some code that's let's say
07:29 that datastore piece if there's let's
07:32 say 50 different sections in the code
07:34 that all use that pattern to retrieve
07:37 and store data try to find the hardest
07:41 or most complicated instance of that or
07:44 you know aspect of that in the code and
07:47 make the change to it first and really
07:50 the goal behind this is you want to find
07:52 any problems with your refactoring
07:55 approach right away I've been on some
07:58 projects where an engineer on the team
08:00 decides they want to make a change to a
08:02 pattern and they make it in a simple
08:04 spot and months go by and the team
08:07 starts adopting it and they start trying
08:09 it out and all of a sudden they get to
08:10 an existing piece of code that's more
08:12 complicated and it won't even work and
08:14 so now we've got you know half the code
08:16 doing it one way half the code doing it
08:19 another so I would just really encourage
08:21 if you're going to do some refactoring
08:22 for your preferences try to accommodate
08:26 and validate that hardest case first the
08:30 fourth thing I would consider if you're
08:32 trying to decide should I refactor or
08:34 should I leave it alone is are you
08:36 willing to get permission for the change
08:39 now this is a tricky one and not
08:41 everybody's going to agree with this but
08:42 if you're on a software development team
08:44 and you're a lone wolf and you're the
08:46 only coder maybe this won't apply but if
08:49 you're working with any other software
08:50 developers if you're going to change
08:52 pattern it really I think makes sense
08:54 even if you're the leave even if I've
08:56 been you know an architect or a lead
08:58 across a whole group of developers I
09:00 like to get buy-in from my own
09:02 co-workers and my and my friends on my
09:04 team anytime I'm gonna make a change if
09:07 I don't do this what ends up happening
09:09 is I make this change or this or this
09:11 change to some aspect of the code Irie
09:14 factor it and then later a couple things
09:16 can happen one the original author of
09:18 that code can get pissed off because
09:20 they look at it like why didn't you tell
09:22 me that you were gonna rewrite my code
09:24 and it's just kind of a nice thing to do
09:26 for the other person to let them know
09:28 hey I'm thinking about making major
09:30 changes to something you took the time
09:32 and investment in already writing the
09:35 second thing is if you want everybody on
09:37 the team to help make that change
09:39 consistently across the whole codebase
09:42 then you really should be getting buy-in
09:44 from everybody on your team who has code
09:47 that's gonna use that pattern and I
09:49 talked about in one of my other videos
09:51 that I actually encourage people if they
09:55 can do it if you're gonna make a change
09:57 or refactor to not only make it to one
10:00 aspect of the code but actually like if
10:01 you're changing the data store like I
10:03 talked about before the way you're gonna
10:04 access the data do it to all the code in
10:07 one go and just have it be consistent
10:09 from the get-go but whether or not you
10:11 do that I just think reaching out to
10:14 your team members involving them in the
10:16 process helping them feel like you know
10:18 what this person cares about us enough
10:21 to at least run this change by us even
10:24 if they really trust you I've been on
10:25 many teams where everybody really likes
10:28 my decisions they really trust me but I
10:30 like to involve them anyway just to help
10:32 them feel comfortable that I'm not gonna
10:35 just make some sweeping change and not
10:37 show you that I actually care about your
10:39 input to the change as well fifth are
10:43 you willing to teach everybody you know
10:46 making a change to a pattern or
10:48 refactoring some code just to get it
10:50 working so that you can hit a deadline
10:52 or maybe an estimate that you committed
10:54 to is one thing but helping everybody on
10:58 the team make that change or adopt that
11:00 pattern or handle the refactoring you're
11:02 about to make as well is another
11:04 and I've been in many situations earlier
11:07 in my career when I wasn't good at this
11:09 where I would write up a quick wiki
11:11 topic and I would email it to everybody
11:13 or I'd you know send a link on slack or
11:15 whatever chat technology we're using and
11:17 be like you know I'm done I've sent
11:19 everything out there that everybody
11:21 needs to know about this change and then
11:23 you know a month later all the sudden
11:25 I'm getting hit with all these requests
11:27 how do I do this how do I do that
11:28 and maybe I'm working on something new
11:30 and I don't even remember and now I have
11:32 to go back and figure that all out so if
11:34 you're thinking about refactoring some
11:36 code for your preferences I think it's
11:39 really important that you think about
11:40 are you willing to spend the time to not
11:43 just tell other people what that change
11:46 is and how it works but actually support
11:49 them and help them work through adopting
11:51 it and being comfortable with it so that
11:53 they can not have to come to you every
11:56 time they need to use the same pattern
11:57 you're introducing and the sixth and
12:00 final thing that I think is really
12:01 important that you just need to consider
12:03 if you're gonna change somebody else's
12:05 code to suit your preferences is are you
12:08 willing to work overtime if it turns out
12:12 that that change is much harder than you
12:15 thought I have underestimated that the
12:19 challenge and the complexity and
12:21 refactoring some code so many times in
12:24 my career I I couldn't even tell you at
12:26 this point but I'm and I'm not trying to
12:29 tell you not to take the courage and the
12:32 opportunity to refactor code if nobody
12:34 ever refactored code nothing would
12:36 evolve and be modernized and and things
12:39 wouldn't continue to advance and let us
12:40 do new things with the project but I
12:43 think it's really important that if you
12:45 trivialize or you make it sound like a
12:48 refactoring change is gonna be easy and
12:51 I've made this mistake many times in my
12:54 career where I'll be talking to let's
12:55 say a project manager or a product
12:57 manager or another technology team lead
12:59 and I'll be selling them on my change
13:01 and I'll be like oh this is gonna make
13:03 the code more maintainable and
13:05 everybody's gonna understand it better
13:07 and we'll be able to build things faster
13:09 once we make this change you know that
13:13 may all be true but I'm also betting on
13:17 the fact that I know that technology
13:19 well enough that I can really get that
13:20 refactoring done in time and if I don't
13:23 if this is a brand new technology to me
13:26 maybe I've you know watched some videos
13:28 on it or used a couple open-source
13:30 projects that use it but I'm not real
13:32 familiar with it yet
13:33 I'm putting myself at risk and you're
13:35 putting yourself at risk that once you
13:37 get in there if it turns out it's much
13:39 more complicated you may have to give
13:42 the bad news to your boss or the rest of
13:45 the team and have to tell them hey you
13:47 know this refactoring change that I
13:49 thought that would take two days
13:50 well now I'm realizing it's really gonna
13:52 take a month or two weeks or something
13:54 like that and you know hopefully if
13:56 you're at a company that has a healthy
13:58 culture they're gonna be fine with that
14:00 and they're gonna just help you make a
14:02 decision you know should you continue to
14:04 make the change or not they're not gonna
14:06 look at it like you made a mistake
14:07 because I personally think someone who
14:10 goes to change some code and finds out
14:12 it's more complicated is the most common
14:15 thing under the Sun and software
14:17 development and anybody that gets bent
14:19 out of shape about that just doesn't
14:20 understand this industry but I think
14:23 it's just really important that be real
14:25 with yourself you know I'm just
14:27 encouraging you from times I haven't
14:29 done this well you know be real about do
14:32 I really know this change I'm about to
14:35 make the technology that's involved or
14:37 the pattern that's involved that I can
14:39 feel confident that when I go to make
14:42 that change I'm gonna find out early if
14:45 it turns out that it's going to take a
14:46 lot longer and I'm gonna have the
14:48 courage to be honest up front and tell
14:50 somebody you know what this is actually
14:53 harder than I thought so what are some
14:55 situations maybe you've been in where
14:58 you've had to decide should I refactor
15:00 this code because I think it'll make it
15:03 easier for me to understand and move
15:05 forward or should I leave it alone and
15:07 use the existing patterns leave me some
15:09 comments below if you're new to my
15:11 youtube channel please subscribe and hit
15:14 the bell icon you'll actually be
15:15 notified every time I release new videos
15:18 you can also listen to this as a podcast
15:20 if you'd prefer on Google Play stitcher
15:24 SoundCloud or iTunes so until next time
