Ruby on Ales 2014

Summarized using AI

Harry Potter and The Legacy Code Base

Kerri Miller • March 06, 2014 • Earth

In the video "Harry Potter and The Legacy Code Base" by Kerri Miller, presented at the Ruby on Ales 2014 conference, the speaker explores the challenges and intricacies involved in dealing with legacy code. Using the metaphor of a Hogwarts-like environment, Miller emphasizes that legacy code should not be seen as inherently evil but rather as a repository of decisions made by past developers. She suggests that understanding legacy code involves understanding the people behind it and their context.

The key points discussed in the video include:

- Legacy Code as an Artifact: The comparison of exploring legacy code to archaeological work, where developers dig through code to understand its history and significance.

- Understanding the Environment: Miller highlights the importance of context in which the code was written, asserting that code reflects the choices and environment of its creators.

- Techniques for Analyzing Code: The video introduces three core techniques for dealing with legacy code: surveillance, excavation, and analysis. These techniques help in inventorying the existing codebase, understanding its flaws, and documenting it for future developers.

- Collaborative Exploration: Engaging with coworkers from various departments is encouraged, as their insights can reveal hidden challenges and assumptions in the code that may not be immediately obvious.

- Continuous Refactoring and Documentation: The necessity of incremental refactoring and documenting code changes to keep the legacy code maintainable and understandable for new team members.

Miller presents several anecdotes and examples illustrating the emotional and practical challenges developers face when confronting legacy code. For instance, she discusses how assumptions about a system can create friction and how new hires can provide fresh perspectives. She also acknowledges that legacy code evolves, oftentimes becoming more complex and problematic over time due to environmental pressures.

In conclusion, Miller encourages developers to approach legacy code with curiosity and an open mind, treating it as a learning opportunity rather than a bane. Emphasizing collaboration and communication within development teams, she asserts that understanding the past and present of the code leads to better outcomes and helps dispel fears around legacy systems. Overall, the talk serves as a reminder that every line of code tells a story, and by understanding those stories, developers can effectively manage legacy code.

The main takeaways from the lecture are:

- Embrace the complexity of legacy code as a historical artifact rather than a curse.

- Collaborate widely to gain insights and knowledge about legacy systems.

- Approach refactoring as a gradual process, ensuring thorough documentation of changes.

The session aims to equip new developers and veterans alike with the tools to navigate and respect the complexities of legacy systems while fostering a collaborative environment for improvement.

Harry Potter and The Legacy Code Base
Kerri Miller • March 06, 2014 • Earth

By Kerri Miller
It's your first day at Hogwarts.com, and everything is wonderful and thrilling. You dig in to classes, and soon find a dusty book with a cryptic warning:

"Do NOT on any circumstances make ANY change to this magic incantation without talking to Doug first!!!"
Sound familiar? Approaching a legacy code base can feel like unraveling a mystery, not just about the code, but about the personalities who wrote it. What tools and techniques can help you solve the maze of twisty code? Let's explore how to get a handle on legacy code, how to negotiate joining an existing team of developers, and how we can get asumma cum laude at graduation.

Help us caption & translate this video!

http://amara.org/v/FG0s/

Ruby on Ales 2014

00:00:16.880 Okay, everybody, please welcome Kerri Miller.
00:00:25.199 Hey, everybody. Um, how about this? That's a little bit better.
00:00:30.720 You know, this is a strange Ruby on Ales conference because it feels like nobody's drinking, and I'm not drinking either.
00:00:36.160 So beer me!
00:00:41.440 Beer us now.
00:00:55.199 I'm not Jim and Rob; I don't always drink on stage. But when I do, it's butterbeer.
00:01:04.159 This has been a really fun conference. Is Randall still here by any chance?
00:01:10.000 I was so inspired by his talk that I want to do my own mic drop.
00:01:18.479 Actually, though, I really love math, although I don't have a real strong grasp of it.
00:01:24.080 This is usually my general reaction to real math-heavy talks.
00:01:36.079 I feel like I'm right there, like I have to get it. I can get it.
00:01:43.840 We'll just let this loop. Thank you, that's my talk.
00:01:50.320 I want to give a little disclaimer. When I first said I wanted to talk about Harry Potter and the legacy code base, I had some Harry Potter fans say, 'But Kerri, you've never read any of the books.'
00:01:55.840 No problem, that's fine; I watch the movies.
00:02:10.720 But if you're not a fan of Harry Potter, you're going to have a bad time.
00:02:16.400 There's a little bit of Harry Potter in this talk, so I'd like to welcome you all to Hogwarts Online.
00:02:22.000 This is our special convo cave.
00:02:28.000 I'm really glad all the other speakers have presented here, but our mutual employer has actually brought us here to tackle a very serious problem.
00:02:35.280 And that is the legacy code beasts that are living in the basement of Hogwarts right now.
00:02:41.599 Not everybody here knows me, which is strange because usually I blend in a little bit.
00:02:49.360 I am a senior software developer from House Minnesota. I uphold the fine traditions of funny gem names and two-space indentation.
00:02:55.040 You might think with a hat like mine that I'm from Texas, and then you might think, 'Well, she's wearing tie-dye; maybe she's from Austin,' but I'm actually from Seattle.
00:03:01.519 In Seattle, I work for Nerd, one of the sponsors of the conference.
00:03:06.640 They have the awesome pint glasses that we've been toting around and only having one drink in.
00:03:12.959 We all discovered the bathroom.
00:03:18.239 I also spent a lot of time working with the Ada Developers Academy.
00:03:25.920 Yes, thank you. I know a number of people, especially here in the Pacific Northwest, have volunteered or donated time and money.
00:03:32.560 It's a great program. In fact, we were able to bring four students down who are sitting in the front row, and I hope that they continue to heckle me just like they do in class. This is no different.
00:03:45.360 Promises are made on stage.
00:03:51.120 Now, a lot of people think it looks a little bit like the Beauxbatons ladies' wizardry school, but it's not.
00:03:56.799 This is not a posed shot; this is the classroom, figuring out OAuth.
00:04:05.600 One group said, 'Oh, we got it working,' and the others were like, 'What? I look and log in on Twitter. How does this work?'
00:04:19.759 But seriously, we're here to talk about monsters—monsters in the basement.
00:04:25.199 You're here as representatives of three different groups that have to deal with these monsters.
00:04:31.199 This is tough; this is a battle that happens to a lot of us from day one or day 100 or 101.
00:04:36.720 Who here has seen a legacy code beast before? Yeah, a whole bunch of you.
00:04:42.000 Even new students have seen legacy code. I made them do legacy code last week.
00:04:47.840 How are your scars? Do you have any scars to show? Most of my legacy code scars are on the inside.
00:04:54.720 These are nasty, nasty beasts that we have to face down.
00:05:00.400 So how did these beasts come about?
00:05:06.400 Now, all too often, we assume that legacy code is evil. But it's not; it just had a bad childhood.
00:05:12.000 It had a bad environment growing up.
00:05:17.360 We think of legacy code as being brittle and wrong, but really, we're interpreting that code outside of its context.
00:05:22.400 Legacy code is really a storehouse of domain knowledge, a set of decisions made by developers before us.
00:05:28.560 It's very strange talking to Mike like this.
00:05:33.840 If we take the time to study the history of code, we gain a better understanding of the business we're working for.
00:05:39.680 We'll also understand the context in which the code was developed and the context for our future development.
00:05:46.400 Because if software is a people problem, legacy software is also a people problem.
00:05:57.280 So we've created ideal habitats for legacy code to exist—these beasts rise up out of the depths and attack us.
00:06:03.520 You might perceive this assignment as some sort of penalty.
00:06:08.720 I mean, there was that incident with the visiting professor and the pumpkin and the Polyjuice potion.
00:06:14.960 But rest assured, this is not a penalty assignment.
00:06:21.680 In fact, you should see this as an opportunity to earn some vital points for your house.
00:06:27.199 Because you know you're a little behind.
00:06:32.639 Every behavior we see around us is not illogical for those who are doing it.
00:06:37.680 People always make the best decisions they can given the time, resources, and knowledge they have.
00:06:42.720 Would people agree to that?
00:06:51.919 Okay, a few people agree with that.
00:06:57.280 So, those who don't agree, do you actually go out of your way to write bad code, obfuscated code, horrible code?
00:07:02.720 Is anybody here doing that?
00:07:08.000 I see we have some Perl hackers here; I can say that.
00:07:16.240 When we're writing code, we need to take shortcuts sometimes.
00:07:23.199 We get sloppy and we tend to focus on implementation details rather than the larger picture.
00:07:29.120 Maybe we don't have complete information about what we're writing the code to do.
00:07:34.240 This is a bad user story, perhaps, or we're just not experts at it.
00:07:40.800 We're trying to set up some sort of DRB distributed crazy card shuffling system and we don't know anything about it.
00:07:46.880 We don't set out to write code that is going to decay and get nasty, but it does.
00:07:52.880 I prefer to take an evolutionary perspective to it.
00:07:59.280 Large events force their way into our code, and it can be as simple as getting a new hire who has a different style.
00:08:04.319 Maybe they use Seattle style coding, or we get a new data center.
00:08:10.520 Someone out there is shorting parentheses stock right now.
00:08:21.599 We get a new data center or our business gets acquired, and now we have to merge with a group of developers.
00:08:27.360 Or we hear about Node.js and start working it into our process.
00:08:32.800 Something changes, and it's in that change that we start to realize this code is bad.
00:08:38.880 This code is no longer serving its purpose because it's evolved.
00:08:44.640 It has some sort of evolutionary advantage which is no longer advantageous—just like our tails.
00:08:50.720 Most of us lost our tails when we migrated from primates to humans.
00:08:56.560 Moment of silence for my brother.
00:09:04.000 But when we move into these new environments, things that were formerly fine traits become expenses.
00:09:10.399 They become messy headaches that we need to clean up.
00:09:14.959 These are evolutionary adaptations that have lost their advantage.
00:09:20.240 They slow us down, and we get caught by a lion.
00:09:25.600 So we're introducing a new class here at Hogwarts this semester: Code Archaeology 101.
00:09:31.679 In the context of legacy code, archaeology is a great metaphor.
00:09:37.120 It's the study of cultures that came before us by examining artifacts.
00:09:42.959 These artifacts can be pottery shards or ruins, and by looking at them, we can understand the cultures that created them.
00:09:49.600 We can identify items that still pertain to our modern time.
00:09:54.640 When working with legacy code, we have a code artifact.
00:09:59.839 We're acting as archaeologists, piecing together how this fits into the larger ground we're excavating.
00:10:06.320 How does this pot shard relate to another, or this service, or this comment to this git commit that we don't understand?
00:10:11.839 There are several books downstairs in the library, several grimoires that we can look at to glean spells to help us cast these demons out of the basement.
00:10:17.839 But we also have to think about these activities in the context of our overarching hypothesis or objective.
00:10:23.839 Now, in practice, archaeology is a process carried out through three techniques: surveillance, excavation, and finally analysis and documentation.
00:10:30.079 Each of you will eventually be graded on a final presentation for this.
00:10:35.519 Unlike the real Hogwarts, here at Hogwarts Online, we do not give extra credit for dioramas.
00:10:42.320 I'm sorry, when you're dealing with legacy code it pays to be brave.
00:10:48.000 You know, just like Indiana Jones going into that tunnel to face giant rocks and spikes.
00:10:54.160 We're digging into things that will scare us, and we'll see code that will scar us.
00:10:59.680 It may make us want to take a drink and say, 'No, no, no, I've seen the worst code'.
00:11:06.880 Here's a Flog score for you: has anybody seen a Flog score of over a thousand?
00:11:13.120 How about 5,000? Do you know who wrote that method?
00:11:17.040 No, it wasn't me! Actually, that was a trick question.
00:11:20.560 Class names have been changed to protect the innocent.
00:11:26.880 When you're dealing with legacy code, you're going to have to perform some mighty feats of computer wizardry.
00:11:34.240 And you have to be brave and just take that plunge, like Sandy was saying, that leap of faith.
00:11:40.800 It's tempting to dismiss the people who came before us as doddering old fools clinging to the ways of the past.
00:11:46.880 We say, 'Oh, man, they were PHP developers; I wrote this Rails app.'
00:11:53.279 But that's okay, because really—
00:12:01.120 Every line of code tells a story; every commit was a reaction and a choice to something.
00:12:07.280 These were requirements or pressures from the environment that the person was working in.
00:12:13.120 Documentation such as README files and test cases provide knowledge, but they don't tell the full story.
00:12:21.120 It's the wisdom that comes from talking to the people who did it in the first place that really counts.
00:12:27.360 Whenever I start a new project or go to a new company, I like to take people to lunch.
00:12:34.080 I say, 'Let's go have coffee. Tell me what you hate, tell me what you love.'
00:12:40.240 What's great about working here? What's the worst thing that happens?
00:12:46.240 I don't limit myself to my co-workers; I talk to developers from other teams.
00:12:53.760 What are they caring about, and what are their horror stories and war stories?
00:12:59.440 I want them to show me the scars. Sales, support, and marketing teams are great fodder for this as well.
00:13:07.920 Take them to lunch.
00:13:12.560 Now in this picture, who are you?
00:13:20.160 You're the red block; I knew you would be.
00:13:27.040 Now, obviously, if I'm asking right, maybe we're Draco—are we the evil person coming to spoil everybody's lunch?
00:13:34.000 Or are we the golden hero who's stepping in to save the day? That’s an important distinction to make.
00:13:41.520 When you start working with legacy code—which is really legacy people—right? Because we all want to be heroes.
00:13:48.320 But, really, what we need is more of Neville Longbottom, the butt of every joke who passes out at the slightest hint of danger or excitement.
00:13:55.120 He is ultimately the star, if not the hero, of the Harry Potter series.
00:14:03.840 He works hard, he's smart, and he takes responsibility in critical moments.
00:14:10.560 Now, I want to discuss surveillance a bit.
00:14:17.280 In traditional archaeology, surveillance involves measuring things with sticks and telescopes.
00:14:24.320 When we talk about software, we start by taking inventory.
00:14:30.880 Where are we starting? What problems do we have in one particular area? What are our code metrics?
00:14:36.880 How is our test coverage? Do we have benchmarks? What do our New Relic performance graphs say?
00:14:43.760 We should pay attention to what's important.
00:14:50.560 I often ask dumb questions, as my students know.
00:14:57.600 I also seem to really like Ron Weasley for some reason; it might be a ginger thing.
00:15:05.120 We have to stick together; soul stealing is a taxing hobby.
00:15:11.200 Ask dumb questions.
00:15:19.120 People will move forward, especially when you're joining a new team.
00:15:25.760 If you have that one expert who used to work on the code coming over to your team—
00:15:32.800 Ask them questions about the assumptions they're making.
00:15:38.080 We've all heard people say, 'I wanted to use Redis, but they won't let us.'
00:15:43.760 Who are they? Who says we can't use something? Why?
00:15:49.920 What are the assumptions? Is it a bad piece of technology, or are there costs associated?
00:15:56.160 All too often, we move from the idea of a neat trick to this is how we do things.
00:16:03.040 Five years ago, I worked for a tiny online bookstore where we had a rule in the employee handbook.
00:16:10.000 'Developers must wear proper undergarments at all times.'
00:16:16.080 Every rule like that has someone's name attached to it.
00:16:22.160 There is actually a story there; I'll tell it in class on Monday.
00:16:27.040 When you do this exploration, there are assumptions that people make about their environment.
00:16:34.160 These assumptions can create friction, which is the moment we say, 'Oh, this is going to be expensive. This is a headache to change.'
00:16:41.120 Sandy's example of refactoring is that code I would leave alone until I had to make that change.
00:16:47.280 Most of you probably wouldn't cruise through the codebase looking for things to refactor.
00:16:54.000 However, let’s discuss some legacy code.
00:16:59.840 We're having some ongoing debate over Seattle-style coding.
00:17:05.760 In the basement, the number crunchers in the potion department said we have to remove poison for liability reasons.
00:17:12.960 So we did that, but then eventually the market forces changed, and the supply of vascular poison dried up.
00:17:19.680 We need to save that stuff; we can't just throw it away.
00:17:25.440 So we create a poison barrel class and start to deal with that, and then we remove the poison.
00:17:30.400 What's wrong with this piece of code?
00:17:36.880 This code is lying to us right now.
00:17:43.840 Because this code is not about removing poison.
00:17:49.520 If you just count the lines of code, you find that barrels and poison storage consume most of the space.
00:17:55.360 We still call it 'remove poison,' and this is a trap waiting to bite us.
00:18:02.160 We take a survey to identify the most likely candidates for fixing problems.
00:18:10.000 This is where new hires come in; they aren't burdened with any prior knowledge about how things should be.
00:18:15.680 You dig down to find where the code comes from: how does it relate to other layers?
00:18:20.560 Is it above or below? How do we assemble these pot shards into something useful?
00:18:26.159 We roll up our sleeves and say, 'I'll just do a little refactoring today.'
00:18:32.640 You can't blindly charge into refactoring; you have to have a plan.
00:18:37.760 It's important to have metrics by which you judge your success.
00:18:43.840 If you dive in, you'll distract yourself, because legacy code loves to rear its head and show its scary teeth.
00:18:50.080 You need to know what you want to do and get in and out.
00:18:55.680 If you see other problems, leave a to-do.
00:19:01.760 Note it and move on, because having a light touch is important.
00:19:06.240 Sometimes, yes, they add to complexity, but it's a path.
00:19:12.640 The code will evolve and continue to evolve forwards, never backwards.
00:19:18.000 How many people here are familiar with the Zieder Z works?
00:19:24.640 They have been draining this inland sea in Holland since the 1930s.
00:19:30.480 They didn't just throw a ton of dirt in all at once; they drained pieces over time.
00:19:36.640 They said, 'Now we need another 100 hectares of farmland, so let’s drain that.'
00:19:42.560 By tackling these things piece by piece, they perform an amazing feat of engineering.
00:19:48.880 In our code, as we remove the poison, we leave breadcrumbs to other developers.
00:19:54.800 We say, 'We changed this API, and the tests are green, but we don’t know who else is using this.'
00:20:00.800 There is definitely more refactoring work to be done.
00:20:06.880 This is just me doing bad code on an airplane, but the basic idea is to make small changes.
00:20:14.720 Just changing the name of something gives it a different set of powers.
00:20:21.840 Now for analysis and documentation.
00:20:27.600 Once you determine the physical and logical position of a code artifact, it's time to publish.
00:20:34.320 If we don't get published, we won't finish, and we won't get our doctorate.
00:20:41.680 Look at implementation details and identify edge cases that are not currently accommodated.
00:20:48.000 Document these, whether through tests or announcements.
00:20:54.640 I updated the Bacillus class, so look out!
00:21:01.480 As you're doing this documentation, especially if you're starting on a new project, work remains crucial.
00:21:07.440 Periodically going through this process identifies holes in your legacy code.
00:21:13.440 Every project has its own language, acronyms, slang, and ways of defining terms.
00:21:19.440 I make dictionaries, wikis, little grimoires that define terms in documentation.
00:21:27.200 That way, the next developer will understand because the assumptions may differ.
00:21:33.680 A sure way to fix a legacy project is to address naming errors.
00:21:39.440 I make a lot of maps; I'm a kinesthetic visual learner.
00:21:46.960 I need to touch and see things to understand them.
00:21:55.040 I was a stagehand and a glass artist; touching things helps me learn.
00:22:03.440 When I can't create a model, I'll find a giant whiteboard and a veteran coder.
00:22:08.960 We sit down and go through the code together.
00:22:12.960 This is a great way to have that cultural transfer about what's important.
00:22:18.640 Don't let them leave that room.
00:22:24.320 Once you complete the surveillance and excavation of a legacy code beast, it's time to move on.
00:22:32.960 There's always a legacy code beast first to contend with.
00:22:38.720 But I have confidence in all of you, especially my students.
00:22:45.680 I forget who said it, but writing shitty code just works.
00:22:51.360 Then it becomes too risky and expensive to change, so it lives forever.
00:22:56.560 That’s evolution—it's evolved into something we're afraid of.
00:23:02.560 The only difference between code and a pet project is the pressure of its environment.
00:23:08.640 The legacy code beasts are phantoms, boogeymen we use to scare new developers.
00:23:15.080 By breaking the knowledge down and making it understandable, we can untangle their mysteries.
00:23:22.080 Anyway, that’s me and what I do, but not necessarily in that order.
00:23:27.000 Thank you.
00:23:30.000 That was a little rambling, philosophical talk. What questions do you have right now?
00:23:34.160 Now that I don't have to use the mic, yeah.
00:23:37.440 I'm sorry, thank you.
00:23:41.760 Maybe.
00:23:44.960 Um, I found drinking game versions, but they weren't good enough resolution, so I apologize.
00:23:50.880 Yeah, can I say 'troll in the dungeon'?
00:23:55.680 True, in the dungeon.
00:23:59.360 No problem. Yeah, Stephen.
00:24:03.440 The website is Tie-Dye Everything.
00:24:07.440 If there are any other questions or comments, oh, Pete.
00:24:12.160 I didn't read the books, man; I don't know.
00:24:16.560 Um, I probably could. Yes.
00:24:20.480 Okay.
00:24:23.680 There is one last slide I want to share with you—it's fairly awesome.
00:24:30.160 Isn't this great? There you go, thank you.
00:34:12.000 So.
00:34:31.679 You.
Explore all talks recorded at Ruby on Ales 2014
+7