Talks
Harry Potter and The Legacy Code Base
#legacy-code
#refactoring
#software-development
#code-quality
#ruby-on-rails
#developer-experience
#team-collaboration
Summarized using AI
Harry Potter and The Legacy Code Base
by Kerri MillerIn 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.
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
+3