The first step of working with legacy code is realizing the incredible amount of value that has dropped in your lap.
In this talk, we are going to pinpoint that value. And move that value in a better to maintain and understand codebase.

First, we will cover the general mentality that will make it easier to prepare a plan of attack.
Next up are more technical tips that will make it easier to talk about the code.
We will end off the session by actually porting a small piece of code.

Comments

Comments are closed.

Eric Wing at 21:04 on 9 Jan 2019

Great talk. Very funny and informative. Good concise code examples.

Rob Wilson at 21:06 on 9 Jan 2019

What a great talk. The use of humour was well suited, and had some great ideas to share (will be implementing some of them with my team - mix of junior and senior developers).

I'd have like to have seen some code or real world examples to help explain some of the thoughts at the beginning...

Update: ...some code examples have appeared (which is mentioned in the blurb), and he's used Doctrine (I'm a fan ;) ), although as pointed out by Frederick, some small elements were missing from these examples

James Benson at 21:07 on 9 Jan 2019

Great talk, learned a lot, and it was really entertaining. Only comment is that I've not heard of DDD as a new programmer, so that might be worth briefly defining.

Tom Metcalfe at 21:08 on 9 Jan 2019

Great talk. Learnt loads and have a good few takeaways to think about.

The humour was fantastically deployed too.

Lucia Velasco at 21:13 on 9 Jan 2019

A bunch of references [to British culture]... *waits for Mr Bean*
I love the start [this isn't an indictment on the rest].
"That was an analogy."
"Does anyone know who this company is?"
My kind of humour.
I found the layer of abstraction of your analogies still very relatable and accessible. Well done!
I was sitting next to someone nontechnical who might not know what "legacy", "var_dump or "refactoring" means, but I think your talk clarified those well (and one would expect a technical audience, right?)!
Great energy. Good use of facial expressions and body language.
Not many people have the balls to say "move slow", I think they're worried that it'll get pushback because startup culture is cool. I like this advice.
Thanks for covering what code climate and the other one are!
People are often reticent to make broken commits, especially if they are used to squashing or trending their commits... It's an important thing to say, I wonder if you convinced the doubters?
I think your description of driver/navigator wasn't clear enough, since people often make mistakes on this.
I would have mentioned that when you use best practice in greenfield projects you're reducing technical debt for when your project becomes legacy/older.
Is VSCode not a fully fledged IDE? (Never used it)
I would make "watch your users/learn your usecases" its own slide. So many people never use their application and don't know how they're used!
For the record, British audiences are like rows of mannequins, the only reason I know how to smile and whoop is because I'm half Mexican. So don't take it personally if people aren't jeering enough ;D Just have confidence and provide the expected noises yourself?
Interesting view on microservices!! I do agree that it's a bit overwhelming to do ALL the things at once.
I'm sorry this is so long (my feedback/commentary, not your talk).
Good mention of SOLID principles, I would recommend doing the whole acronym and telling people to read up on them if they don't know them, because there are some junior developers in the audience who might not be familiar with them.
I would throw in another easy analogy halfway through for a bit of a brain break, and a summary slide at the end!!

Thank you!!! Good topic, excellently delivered. Apart from missing out Mr Bean!
I liked your answer to the third question, it was very thoughtful.

Very enjoyable it may have been, but there was an incredible amount of value in the talk too - not least making legacy funny and interesting. Using a decent IDE definitely helps us hugely with legacy. The translation layer idea was an interesting idea. Putting a Symfony framework around the legacy app was a turning point for us, though, facilitating many of the other things talked about.
Look forward to checking out the blog.

John at 09:44 on 10 Jan 2019

Great talk, really funny!
The only suggestion, maybe explain a bit more about the different concepts for rookies like me.

Nick Downton at 08:50 on 11 Jan 2019

Great talk.
It went in to just about the right level of technical detail, while still getting across a great set of principles.
I hope you get to try crumpets one day!

Dan Ackroyd at 13:32 on 11 Jan 2019

I think spending more time on why rewrites are bound to fail would improve the talk, as it's an important point, and although I agree with what was said, if I hadn't already heard the arguments in depth before the talk, I doubt I would have been convinced during the talk.

If you can, end the talk on a solid take-away point, rather than a list of stuff as it gives a 'stronger' impression.

The readability of the slides could be improved:

* For the non-code slides, just use all the space available rather than just the middle and decide if you want the background light, then have all dark fonts, or a dark background and light text.

* For the code slides, again use way more space but also optimise the code formatting for a presentation rather than editing the code.

* We're not staring at the code for ages, so it's better to use a black background rather than they dark grey of an IDE theme.

* The slides don't need '

Dan Ackroyd at 19:32 on 12 Jan 2019

Huh. It's possible my comment got chopped off due to a malfunctioning filter.

I'd put "The slides don't need ' < ? php ' at the start of each of them", which presumably got chopped off as a hack attempt....continuing the other stuff that was lost:

Also, although I agree that brackets belong on the next line when writing code, for slides have the { on the end of the method declaration line saves a whole line of space.

Finally blue and green should be avoided as text colours. People's eyes find it much harder to resolve blue colours than red, and slightly harder to resolve green than red. Changing from colours that are appropriate in an ide, to very light pastel colours will make the text easier to read. e.g. even as bright as #dfdfff is noticeably blue in slides, but is much brighter and so stands out much better.

I watched this talk on YouTube (https://www.youtube.com/watch?v=76C1TNI6Sdw). It's a really nice talk; there were lots of funny comments, which is great for the entertainment value.

There were lots of practical suggestions for working with legacy, many of which are actually applicable to green-field projects. I actually think the differences between these different kinds of projects are not so obvious after all.

Thanks, and just keep talking!

Very entertaining talk. There was a good selection of advice.


The translation layer is a good approach. My only suggestion for improvement would be I'd have to have seen more practical tips like the translation layer, possibly at the expense of the more higher level suggestions.

In summary a great talk. I hope you submit to many conferences, others would benefit from it too.