Working effectively with legacy code isn’t all about creating test harnesses before refactoring algorithms. The “safety first” strategy doesn’t always apply. Not if the code you’re looking at is LYING IN YOUR FACE anyway.

In this talk I’ll show you what brutal refactoring is. I’ll show you the red glowy eyes of the Churn. And I’ll hold up some big warning signs that should prevent you from producing legacy code today.

Table flips allowed.

Comments

Comments are closed.

Intresting, like usual ;)
Make me find some path for my actual job \o/

As always an enjoyable talk to listen to. Not really new things, but sometimes I need a story like this. I liked the idea of looking to the git history to find problematic classes. And thanks for the reading tips.

Scott Dutton at 18:01 on 26 Jan 2019

Was a good talk about legacy, Would have preferred some examples on before vs after

An amazing talk as always. The jokes were amazing... but were they really jokes ;)

Tom Van Looy at 20:39 on 26 Jan 2019

when you said there were three Kant questions my immediate thought was that you were missing one. In my observation the three posed questions are somewhat egocentric, in the way that they are focused around the developer. What can *I* expect / do / know. It is not a secret that "some" software developers suffer from a kind of narcissism towards "software-development", completely ignoring project goals and prioritizing technical matters.

I think if you are dragging in Kant, the fourth question is an important one to include, and in this context can be translated as "what is the software developer". A more important question then "what can I do". What is the role of the software developer in a project, or in a specific project? Is (s)he involved in the organization? Should (s)he be more involved? Is (s)he not supposed to think and just execute? Is the team working in the right direction? Are they investing development time in the right parts of the system? Do decisions reach the entire team? What is the company's or customer's strategy? Are they creating competitive advantage?

Well you had me sitting there grinding over these things for over an hour, so I hope you are happy now ;-)

Great talk about legacy code. One personal opinion: you said so yourself, a lot of the way we think and feel about legacy code is because of psychological reasons. In my opinion, naming something influences the way we think about it. By calling legacy code "legacy" or even "monsters", it immediately paints a negative picture of it and you're feeling bad before you're actually working on it. The fact that you're working on legacy code, probably meant it kept the business afloat for however long it has existed, so it definitely has merit.

I've once heard someone mention that because of just that, they had renamed the namespace of their legacy project to "Goldmine" as a bit of tongue-in-cheek humor. But still: it clearly indicates that, while yes, the code is old and probably a little scary, it still contains some great nuggets of knowledge.

Steve Winter at 15:25 on 28 Jan 2019

Got a bit depressing at times, but it was always light-hearted. Your definition of legacy being 'code without an owner' was great.

Really liked the idea of using churn vs complexity to identify places which 'really need work' and have already tried that out with a legacy project I'm working with - interestingly it identified a few places I hadn't expected (and several I had).

You're a great presenter Matthias, with obvious in-depth knowledge!

Miro Svrtan at 17:04 on 28 Jan 2019

I felt the talk was bit disconnected: lot of theory & philosophy on one hand and personal disappointment stories on the other. This made the whole talk have a 'depressing' vibe.

In my experience, 'legacy' can be terrible code but I dont like labelling bad code with 'legacy' stickers by default: it's just bad code.

For 5* I would like to hear a few positive stories as well, at least how a depressing one from speakers experience was converted to a happy one.

A typical Matthias Noback talk : fun, interesting and refreshing. It was nice to see a talk being not all about code examples and demo's, but just a 'talk' about something we all have to deal with.

Nice talk with some fun jokes and an all around fun atmosphere. Had a few usefull tips/guidelines for legacy code but apart from that no real groundbreaking information/solutions. Thanks for the talk!

Jens Trio at 13:23 on 31 Jan 2019

Nice presentation about legacy code. I like your speaker style, an informative talk with some jokes in it.
I personally would have preferred some technical examples.