Refactoring Is Not Just Clickbait - Kevlin Henney - NDC London 2023

So um let's talk about refactoring um so my name is Kevin Henny and um I've been around a while I remember when the first computers were created no sorry that's not that old that's actually um uh brexit technology it's one of Britain's uh great exports um you know we don't need everybody else's silicon And we can do our own um now normally we associate refactoring with dealing with Legacy this is one of my favorite Legacy systems uh we're not entirely sure what it does we don't know who built it we don't know why But it

seems to work twice a year and you're not allowed to touch her um I took this photograph almost exactly five years ago yeah yeah Valentine's Day because I'm an incurable romantic um took my wife down to see that there's even a crow perched on one of the trilothons and that kind of is the harbinger of of death and foreboding that's the Experience many people have when they look at code most people work on yesterday's code all this talk about technology being tomorrow is nonsense most people spend their life living in the past if you are

spending eight hours on a code base approximately seven hours as a typical maximum was spent in the past dealing with the issues of the past if you're really lucky one hour is spent on the future on the other hand that Might just be uh complaining about the code base to a colleague by the coffee machine but in many people's minds they associate refactoring as a kind of response to Legacy in other people's minds they associate refactoring as just a shortcut key okay it's the hence the clickbait title A lot of people oh yeah refactoring it's

on my context menu yeah I know the shortcut for rename And that's kind of it but we need to go a little bit further than this I mean where does a lot of this stuff come from where does a lot of our response and actually I'm going to say some of our response is not entirely accurate and our perceptions where does it come from so wonderful quote from Neil Ford the developers are drawn to complexity like Master to a flame often with the same Outcome there is this sense that sometimes we create our own complexity

human mind is a wonderful thing um we're very good at speculating it's a form of imagination we imagine how a system might be the problem is not that we use our imagination it's not that we are able to speculate it's that we then go and put it in the code I wonder if oh yeah somebody might do this quick accommodate that with an extra kind of hook or an extra work around or an attribute or something that'll make it easier to develop in future guess what the future arrives and you're in that seven hours going

what the actual this is stupid the Futures arrived it looks like nothing like this but I still have to bear the weight of all those Decisions in the past that we're supposed to make the future easier we are very good at taking simple things and making them complex we're also very good at taking things that are sophisticated and making them simplistic causing exactly the same problem yeah and a lot of people then attribute this to technical debt they describe it as technical debt now it's not that it isn't a technical debt but there are two

issues here First of all technical debt is not necessarily a bad thing when sometimes when people tell me they say oh okay our code base has lots of technical debt right but what are you trying to say are you trying to say it's a good thing or a bad thing now whenever I do stuff like that people they well they actually what I hope they think is wow Kevin's challenging my perception what they actually think is Kevin's an idiot doesn't he know about Technical debt well I do know about technical debt um we're now at

a point where it's over 30 years old as an idea Ward Cunningham developed it in 92. specifically though he didn't call it technical there he called it debt the term technical debt was not truly cemented in place till the early 2000s at the end of the 1990s I was using the term occasionally technical debt but I didn't like it I Prefer quality debt or design debt design deck was my favorite but as of the early 2000s we cemented it in to mean we use the term technical debt but the reason I challenge this is that

Ward did not originally say debt is a bad thing he just said debt is a thing and you can it can be bad but you can also use debt constructively in fact the reason he introduced it as a metaphor Was to use it constructively we've ended up using it only destructively we use debt for a number of things I can run up a debt short term in order to achieve a benefit that I might not otherwise have been able to achieve I can even do this long term and have a structured repayment so my wife

and I had a mortgage That's a classic example of a debt it's a very long-term thing what's the benefit you get a house but I don't wait for people with Um baseball bats to come around to collect money we have a structured repayment model debt is not intrinsically bad debt is a thing the question is what you do next as to whether or not it's good or bad so when people tell me we have lots of technical debt they're not actually telling me what they want to tell me so technical debt is an observation you

can make on a system of people and Technology And you can make a value judgment about it but what most people are ignoring is how did you get it it's technical debt's not a process it's an outcome there is a process which I started to call technical neglect because people keep being distracted oh we've got technical debt what do we do about it do you have unmanaged technical debt yes that's what we said well you should say it it's unmanaged technical debt that's Your problem how did you get it we have no idea it just

appeared like the bugs but until you understand that you need to understand that it is the act of a thousand edits it doesn't happen just once technical debt is just not mysteriously appear overnight oh look I suddenly got a mortgage I hadn't planned on that yeah banks are a little more cautious about things like that It's more a case of these are small debts they're your little credit card things I'll just charge that I'll just charge this I'll just do that oh a snack here a snack there shortcut here a shortcut there yeah I know

there's a better way of doing this and a thousand edits later you're going like oh where did this come from and unfortunately it's got interest it's Got your interest it's got percentage-wise interest but you need to look at the process neglect as we have physical neglect we have emotional neglect these are Concepts that are known in the world we should also look at the idea of technical neglect and then in response to this we often position refactory so if you've not come across commit strip you need to come Across commit strip there you go that

was easy um got a project manager talking to a developer here so will the refactoring and will refactoring code improve the loading time not really well it improve security then nope so it's for browser compatibility oh absolutely not so tell me why is it always the same old Story with you guys wanted to refactor everything I need to know because it's Debs if we know we've left messy Co we can't stop thinking about it when we wake up in the morning at lunchtime in the evening when we go home and when we're trying to go

to sleep and for those of you who were awake at three o'clock in the morning every now and then then as well it haunts us you know it haunts us can make it a little bit better now I Think at this point we need to recognize that software development is a knowledge-based endeavor what you're doing with a code base is you are codifying quite literally codifying knowledge your knowledge of the domain knowledge of the Technologies knowledge of how you work with the tools it's literally codified so in other words it's a collaborative effort saying here's

our best shot Now when you put it like that it's just like well here's a shot the problem is here is our knowledge here is the point at which it was codified it's always behind we're always living in the past now we'd like that tail to be a little bit shorter we'd like our current thinking as reflected in our system to be as close as possible to our current thinking on our wetware we want To reduce the distance there's nothing more frustrating for many people they experience this it's not whether or not a code base

is Pleasant to work in it's whether or not you know how it could be versus how it is it's the difference okay and it's often been said that comparison is the thief of joy and you should never compare yourself to others but when you're dealing with abstract Entities I know that this code could be better and not just a bit tidier sometimes you might be looking at a system I've had this experience often in our visiting companies where you're looking at it and you're going like well this code base could be about five to ten

percent of its current size five to ten percent of the current size of a code base is a a huge step change in quality of life and quality of delivery it's not A slight Improvement it is a fundamentally different kind of development and yet we often deny ourselves this so this gives us a kind of sense we need to have a better understanding of architecture now software architecture is a metaphor as indeed is technical debt um every now and then I hear people trying to debate why it's not a good metaphor That's a really dumb

debate it's a great metaphor it's a metaphor that's the whole point all metaphors are not supposed to be identities if you're worried about your brick alignment in your code you've misunderstood the point of metaphors the whole point of a metaphor is to shed light on something and say I wonder if that applies here is to provoke questions it's to provoke thinking if you're going to shut it down with an argument that it's not exactly The same thing then you have denied yourself the opportunity to think and sometimes when you look at a certain code base

that's what you want I don't want to have to think about this but this idea is important because we often reduce architecture to the Technologies The Big Box diagrams and yet we forget the most important thing about the metaphor architecture is for people to live in I don't see many software architecture texts point this Out because it's exactly the same it's for developers to live in what does that experience like now if we're going to talk about sculpture there is a quote that is um I've actually put the full attribution here because it's one of

those ones that does the internet uh does the rounds on the internet there is a beautiful angel in that block of marble and I'm going to find it all I have to do is knock off the outside pieces of marble and be very Careful not to Chisel into the angel with my chisel I've seen this attributed to Michelangelo Leonardo da Vinci honestly I swear if you look in the right corners of the internet you'll find it attributed to Abraham Lincoln as well um as she is George Pentecost the angel in the marble early 20th century

there's a thing here This is a great quote it's quite inspiring makes you think about things but we're missing something again we work with software first four letters soft we actually get to Chisel into the angel and then back out again in fact we should use a cudlier font there you go soft what we often struggle with is the loss of softness we often treat software as if it is indeed hard and unforgiving Because actually one of the coolest things is I've changed my mind there we go done that's it you have the ability to

do time travel which honestly is way cooler than most other professions you know from the very humble control Z I'm just going to undo the Last Action yeah oh I've spilled my coffee control Z on reality does not work I'm perhaps it works in the metaverse But nobody's been there we don't know so here's the thing we get to undo things we actually get to go and say no let's roll back to the last good command we get to time travel we get to move things around we get to speculate and try things out we

even get to try parallel universes yeah forget the Multiverse that's currently popular in SF movies we've been doing that for decades software developers got there first time Travel and parallel universes next time you are introducing yourself to somebody please keep this in mind don't just say software developer you're denying yourself a way cooler job description but this softness is something that we lose so I'm going to take you back to the late 90s refactoring by Martin Fowler now this was a book whose time had very much come I really first heard the term Refactoring in

the context of extreme programming stream programming the original XP and I came around in the mid mid 90s um pioneered by Kent back and others and refactoring was described as a principal practice and I remember looking at that going like yes this is this is what I've been trying to express and how I've been thinking about coding for a while in Fact the first company I worked at after University I didn't have a word for it I was dealing with a legacy code base and I just reached for the nearest mathematical idea which was factor

of factoring or factorization in fact I'm blessed by the fact that we have not ended up with refactorization as a term although I'm sure that there are corners of the internet that would prefer that because it sounds more technical But that's the key thing is this idea has been around for a long time but it's not been articulated as a first class practice so that started making it real Martin Fowler was one of the people on the original um C3 XP project with Kent Beck and he ended up writing this book refactoring I went to

uh see it was January 1999 and I went to the OIP conference in Munich and I went to a One-day workshop with Martin there and it was just like yes this is exactly what I've been waiting for it was kind of a breakdown of like just really simple structured in terms of kind of pattern-like thinking but one of the things that has been most overlooked is the subtitle improving the design of existing code it's not just saying tidy up your code make it a bit cleaner he's talking about Something much more fundamental he's talking about

improving the design it's a yeah and it's it's actually kind of grasping that and saying this is possible what is also interesting here is that this book was written before we had widespread refactoring tools although refactoring browsers had existed up until that point um they had certainly not gone mainstream by any stretch of the imagination and it wasn't really until The early 2000s that we hit that point and Martin gives a definition here what do we mean by a refactory a change made to the internal structure of software to make it easy to understand and

cheaper to modify without changing its observable Behavior we'll come back to what we mean by observable behavior in a moment there's a subtlety in there that is often glossed over But notice to make it easy to understand and cheaper to modify now what he's not saying here is take code that sucks and turn it into code that is good that is certainly part of this but sometimes we also take code that was good but the world has moved on there's nothing wrong you know we sometimes it's very easy to look on the decisions of the

past and say ah you know that's terrible but remember you know a lot more than you did in the past That person may have been you that wrote the code you're in it you have a privileged position and in the absence of actually real time travel um you're not able to take advantage of that and send them a letter or a missive or you know do peripheral style kind of communication back to your former self or your former colleague and go hey just try this that's switch statement it's not going to scale that switch statement

with five cases Is going to become a switch case a statement with 25 cases and it's going to be replicated in large parts of your code which if you're being paid by the line of code is magnificent if you're not not so good in other words consider something else maybe polymorphism maybe it's just a table of callbacks you know use lambdas the point there is that these are all possibilities at the time you put in Four or five cases that's entirely reasonable okay you don't necessarily know that the world will move in a particular way

you give it your best shot and then you come back and many of the things that we consider to be not good code it's not that they were not originally good code but they have grown to be that because of either their own growth but or the change in the situation around the code the world moves on Yeah code base I dealt with years ago struggle with the fact that it needed to move into a multi-threaded world and it was single threaded no it wasn't written badly single threaded but it was its assumptions were everywhere

it was very single threaded you know the smallest assumption was oh yeah the world is as we left it the smallest assumption is that when I do that and walk away that that Clicker does not move of its own spontaneous will okay there is no race condition between me and somebody else and carefully timed it so that nobody in the front row could actually validate that actually mess that up the world just changed that's that's fine so sometimes what we call barcode is historically good code okay so we have this Now what's interesting is without

changing exactly the same definition appears in the second edition of refactoring which came out 20 years later now the first edition I don't necessarily recommend getting it it's it's good for historical reasons uh uses Java but it's really old Java uh it's pre-job five for a start um and it uses junit but it's really old J Unit we're all junit five now let's change it three the new book uses types no actually doesn't use the typescript it'd be nice to use typescript it uses JavaScript um but this lives in a world where we now have

automated refraction tools so what's its value well it's still teaching about design it's still telling you that if you don't have those refraction tools understand the steps That you would take and why most most of design is why why is it like this why am I doing this it's the contemplation of Alternatives and you'll find that in any set of refactorings there's contemplation of Alternatives sometimes you may have extract method but you also have inline method the exact opposite which one is the right one I can't tell you it's context dependent the idea is that

you're invited to think and figure Out what's what's my code wanted me at this point what do I know what knowledge can I bring to bear it's a design process okay it's this process just as I said before it's just like we we like to look at an outcome an anchor on that in this case I talked about technical debt and we'd like to imagine that it's some kind of you know Pinnacle of clean good code but actually it's all about process it's all about what we do on a day-to-day basis now When it comes

to refactoring we need to understand that there is a flow there is a process you're always making decisions and some of these may be supported by automation that's your automated refractions but a lot of them won't be and that's fine so let's dig further back in time this is the early 90s but actually it all started in the late 80s this Um refactoring object oriented Frameworks this is the PHD thesis of Bill Opdyke who was actually one of the contributors to the original refactoring book you can see the date on that is 1992. and Ralph

Johnson is the PHD advisor Ralph Johnson is one of the gang of four the following year Ralph Johnson and Gamma and Helm and vocedes would publish design patterns but Ralph Johnson's longer term work was actually Refactoring that was where most of the early Reef automated refactoring work was done was at the University of Urbana-Champaign and a lot of it was done in small talk except this one the original refactoring work from the late 80s to the early 90s was actually C plus plus probably the language mainstream language that's received the least love from refactoring tools

um and Bill Opti Made the observation said the refactorings are defined to be Behavior preserving which kind of makes us think okay let's go back to this question of behavior preserving what do we mean by that um if you've not had breakfast yet apologies for this because you probably think wow yeah look that's that would look really nice in my stomach um however that's that's not the point here The point is of course I'm going to talk about Stacks uh the probably the most overly consumed and over specified uh data structure um in the history

of software development um but okay so um I will so let's use some typescript here I can characterize it in terms of its depth the top element um I can pop an element from it I'm going to keep life simple I'm going to make it a strict pop we're not getting a side effect return out of this one I'm Just going to keep life simple and I can push a new value onto the top now I've got a different number of different ways of implementing it I'm going to use an approach where I bind a

Lambda to um a variable in fact I'm making it a function a Constructor function and I use a local variable to be private that's the thing about JavaScript and typescript is that there are many different object models and some of them Are more or less object-oriented than others this one is actually the most perfect object model because it actually has a true separation between public and private um you can't get your hands on the internal variables and then I return effectively a tuple an object that describes the ways in which I may manipulate and operate

this is the kind of true interface and it satisfies the interface We specified before and here is a simple way of implementing it um I can do it all just as one line of forwarding operations okay each one of these just uses the underlying array and it wraps it and then conveniently enough the underlying array has a couple of extra operations like pot and push that I can use directly but I can strain it I give it I now have better names what is returned is not a thing that you can manipulate as an array

and nor should it Be it is a stack okay I use an array for implementation there is a strict separation there and now I'm going to refactor it in fact what I'm going to do is I'm going to effectively upend it reverse it um I'm going to change the implementation I'm going to make instead of the last element to be the top I'm going to make the zeroth element B the top and I'm going to use different primitive Operations on the array to affect that shift and unshift okay now the point is from the outside

this looks identical it behaves exactly the same way that is a refactoring that's what we mean by Behavior preserving the idea is that I have not actually changed the usage if I had tests then all of those tests would pass if I didn't have tests then I'd send myself on one of my own test driven development Courses because I should have tests for this so the point here is that that will satisfy that but let's understand this idea so a right-hand rule thing I came up with a number of years ago I find a very

simple way of trying to understand what are the qualities and properties of a piece of code that are a little richer than we might normally appreciate so functional characteristics Operational characteristics developmental characteristics we can actually go there are lots of other subdivisions of this but the key thing is that we've got three rather than two the way that people normally describe such things as functional and non-functional okay which is a I don't know I don't know how to kind of approach the whole non-functional thing Because non-functional is possibly just the least imaginative way of describing

the things that aren't functional so I've got these functional properties and then I've got these other properties oh what are they well they're not the functional ones yeah I've got two kids they're both boys first one's called Stefan the other one is not called not Stefan he's got his own name he's Yannick okay he's his own Person you name positively don't name it by what it isn't okay yeah those of you who is if you you know if you're visiting if you're visiting London you're thinking yeah I'm gonna go see some tourist sites I'm going

to go and see you know Westminster Abbey and then I'm gonna go and see not West Mr Abby yeah that's kind of a lot of options there we need to learn to be specific and that's what we're supposed to do in Software be specific it's even in the words like specification first few letters specific the clue is there so don't tell me what it isn't tell me what it is and also as an assign in English by the default meaning of non-functional is broken so if you're having a conversation with non-developers just watch out for

that okay they're going to be looking at you guys what do you mean non-functional requirements I Want it to function what kind of idiot wants it to break yeah I want it to crash you know I want it to be like Azure every Wednesday um so um the point there is it's not just bad naming it's not just a lack of imagination it's not just a failure but to be specific it's the fact that when we look closer at this category it reveals itself to be two or at least two If you want more categories

go and look at ISO 25010 especially of Europe through wake at three o'clock in the morning it will send you to sleep but it's a really good breakdown of eight different categories of kind of like software product qualities anyway let's stick with these three by functional I mean semantics it's the stuff I was talking about in terms of that stack it's the stuff that We normally think about in terms of user stories and requirements by operational it's not what it does it's how it does it that's time and space okay that's like how how long

does this take that's our performance characteristics that's where we care about availability and things like that that's where a lot of the abilities that live at runtime and that's the thing that unifies that's the thing that unifies um the uh operational and functional things They're both runtime qualities they can be experienced and observed at runtime okay so a user will experience those at runtime but they won't experience the developmental qualities developmental qualities are really properties about the maintainability habitability the degree to which you've managed the technical debt the portability of the code the qualities of

the code if you if you have particular design conventions and Guidelines for your architecture and detail code that's where those are followed those are those are requirements that don't come from the outside they come from the team these are what we want from our code because we live in the architecture this is how we like to live so that but this is often neglected sadly that's also why I put it at the bottom because everybody kind of sees the first two and they go yeah whatever It's at the bottom it doesn't really matter we can't

see it's below a kind of like imaginary line down the middle of the screen so what happens let's let's understand this is a simple way of classifying the changes that we make to our code and so in other words we probably need a better understanding of how we change our code how we interact with our code off we end up with just like I changed Something many years ago I worked with a developer who went by the suitably anonymous name of John Smith and that was that that was somehow perfect because um his commit messages

were also suitably anonymous every commit message was pretty much the same uh changed some code fixed some bugs added some features wow thanks John that was that that was Really specific I'm sure the diff will be very useful to me um we can break these things down and understanding the change that we make if we have a simple three-axis system oh it's not perfect but then again my fingers are not a perfect right angle so it's good enough but as a simple model of understanding it's like okay what have I changed when I add a

feature my goal is to improve or increase The functionality available whether that is that an individual function or a software product level I am adding something that was not there before what happens to the performance characteristics maybe they change maybe they stay the same if they change maybe they get better maybe they get worse but that's not our goal our goal is improve this more semantic capability Likewise the developmental quality obviously we don't want it to get worse but that's not our goal our goal is to add a feature interestingly enough this looks a lot

like bug fixing um when you fix a bug when you fix a defect you're actually the word defect is surprisingly close to the word deficit you are fixing a deficit in other words we promised you this much functionality But you got this much that shortfall is a bug here is the thing that you can't do that you should be able to do so although it moves in the same direction it does so from below the water line rather than from above it okay so the movement in that sense is the same but the sense uh

or the meaning of it is different but it gets more interesting when we start looking at things like optimization Because optimization is resolutely not about changing the semantics optimization because otherwise you know hey I've made it 10 times faster is not very effective when you say yes but it's buggy as well yes but it's a fast bug rather than a slow bug that's not a virtue so there is an idea here that it's a behavior or a functionality preserving transformation now the problem is I just slipped into it we have a habit and you Saw

it in the bill optike quote and the Martin Fowler quote of just assuming that behavior means the semantics it means the functionality and that somehow performance is not a behavior Trust Me performance is absolutely a behavior um it's just that we have a bias particularly you know with a shadow of computer science haunting software development we have a bias towards semantics because the other stuff's really messy but behavior is more than Just the semantics it is um it's how it does it if something uses more memory than it should that's a behavioral problem that you're

dealing with so we need to be a little more cautious sometimes about how we use the word Behavior and we see that our goal is to improve some aspect of the operational access uh in truth sometimes something else will get worse you know we we trade space for time in many cases I'm going to add a Cash while that trades space for time um uh development cruelty maybe it gets more complex adding a piece of cash into a piece of code makes it more complex it's not that it's wrong it's just that it's going to

be more challenging yeah it's a piece of code you have to deal with you would not otherwise have had to deal with sometimes we discover that the code it gets simpler um you'd be surprised what The power of a good Delete can do every now and then it's just like oh yeah we got rid of that code and guess what everything ran faster we'll use less memory it's like right we chose a particular data structure and actually got rid of a whole load of code and we got better performance as a result but the reason

I want to focus on this is obviously refraction which is another Behavior preserving transformation or functionality preserving transformation So Behavior preserving is the term that bill and Martin used but we should be a little clearer so there's kind of a a balance here um and this is where our tooling can help this is where our tests can help um in determining that we have respected that constraint that we haven't broken with the existing functionality but our goal is to improve something on developmental access that is our explicit goal now you can use these Different dimensions

of change as a way of breaking down your commits you can say okay I've got a whole load of things to do let's walk through them okay here's a bug fix let's not roll the bug fix now we're going to do the bug fixers yeah probably let's do the bug fix first okay now performance Improvement okay let's do that check that one out Okay now let's take a step back and see where we are with the code and if there's anything I can do to improve it or if there are any insights that I can

get from it that I want to change take the code in a New Direction maybe it's just a small tidy but maybe it's actually a proper design nudge down a different Fork as it were so we have the process of refactoring what does it mean to refactor to restructure software by applying a Series of refactorings without changing the observable Behavior semantic Behavior functional behavior of the software now there's a really subtle thing here that's easy to read past I'm curiously enough it's probably being aware of it I read pasta for a number of years I

kind of picked up on it where the book first came out and then kind of ignored it whenever I pointed this quote out to people A series of refactorings he uses plural to refactorized you're not just going to do one thing there's a it's a progression you're on a journey here okay so the idea is that refactoring is a process and when do we do it well as the author Annie Dillard observed how we spend our days is of course how we spend our lives yeah don't don't make refactoring the thing you're going to do

in the future oh we'll have a big refactoring sprint Well you know we'll you know our next major release we'll do it it's a daily thing it's like you don't save up well I hope you don't um personal hygiene until the end of the month you know I'm going to save time to yeah okay so here's a developer approaching personal hygiene the way that we approach code you know I'm going to save time today I'm going to save time by not brushing My teeth not having a shower and doing all those things see how much

time I've saved then at the end of the month you can I'm going to spend eight hours just like you know the whole month they're gonna go and see people who for some reason have been avoiding me for the last month you know I thought that kind of like you know social distancing was not the thing anymore but apparently it is I can't explain why yeah Systems thinking will help you with this so let's talk about the automated side of things the fact that it is so the fact that we have relied very much A

lot of people when they arrive into software development their understanding of refactoring is coupled to the idea of automation it's very difficult to arrive in software development these days and not Hear refactoring in the context of an IDE that's how you will be introduced to it the focus of this thesis on the is on the automation uh automating the refactorings in a way that preserves the behavior of a program this was 1992 with the work he began in the late 80s so what are the kinds of things that we might do so here's a book

that uh published Oh the beginning of the last decade um 97 things every program should know I'm going to pick an example from downtown horse North code in the language of the domain I I like this example for a number of reasons um there's a lot we could be talking about in terms of the domain understanding but it's kind of a key point it's about reflecting on knowledge and How we learn things and how sometimes we don't truly appreciate what we know until we see it reframed in a different sense so if we look at

this when I look at that and go I have portfolio IDs by Trader ID don't get traded it contains key people okay so this is some Java code and every single identifier there makes sense there's no problem there's the only abbreviation in there is ID and that's a Real world abbreviation not a developer abbreviation strictly speaking there is nothing there that we can rename so we might say oh this deserves a comment or or something like that but I still don't understand what it means so maybe that's why I want to comment alternatively we can

realize actually what we want to do is rename the whole thing the scope of renaming is not just an Identifier sometimes what you want is a name for a bunch of stuff but we tend to call that extract method and then suddenly you realize that this is actually ah trade account view portfolio Okay if a particular Trader to prevent Insider dealing is if they are if they are they have permissions on portfolio so this is from an investment Bank but here all that stuff is now squirreled away the logic is still there The mechanics are

still there there's nothing wrong with that description the mechanics it was just at the wrong level this is the decision that I'm taking at this point is Trader can view well that's cool so interesting enough that is one of the most common refractions you're likely to do extract method so um last year I kind of put this online I tweeted this And you know one of the great things about languages modern IDE support is that thanks to refactoring tools Legacy code is a thing of the past and like with all the languages developers never have

to experience long methods rounding classes poor identifier names complex logic honestly for those of you who have entered software development in the last two decades I envy you you will never know the pain of Legacy code you will Never know what people are talking about when they talk about bad naming or long methods or rambling classes you will never experience this like some people didn't experience the Tweet after all the one after that well here's the point we actually solve the problem we solved the problem with Legacy code in the 1990s and rolled it out

in the 2000s here in 2023 we should have strictly speaking Almost no code that somebody from that period of time would have called Legacy but we do which tells you it wasn't a problem of automation at all it was never a problem with automation yeah if you don't know what you're going to do with it it doesn't matter if the thing I don't know what I want to do with is automated or not it turns out that what we needed to Teach and promote was the idea that it's okay to change the structure and design

of your code as it reflects your understanding that that is a normal practice it is not a thing you have to ask permission for it has a name it's called software development if you're a software developer it's already in your job title you have permission that's what it's about if you could transform the daily experience of yourself and others From constantly being on the back foot fighting fighting the past rather than creating the future that's kind of yeah that's kind of a good thing what we've done is we've removed a large source of friction and

yeah on a routine basis so let's just align this linguistically uh c-sharp 2002. 2001 2002. there should be no refactoring tools we're not immediate they followed a Little bit later Java hit the world in 96 went through a major growth curve particularly the Enterprise stuff came along at around the same time as refactoring tools started being rolled out in Eclipse IntelliJ and becoming standard strictly speaking we live at a point where there should not be significant Legacy problems that people are fighting and yet there are So let's try and understand that it wasn't a tooling

issue it was a problem of understanding and culture and continues to be it's nice to have tools no don't get me wrong on that but that's not the problem so you know in a clearly scientific totally scientific approach I ask people online for their opinions Factors do you find you use most whether automated or not I I was not surprised by the answers extract method was one of the most popular here's a bunch of stuff I want to give it a name extractor here's the thing with the name I want to give it a different

name in fact rename is a broad family of things individual variables all the way Out to interfaces and packages of course there are boundaries to renaming we do have to respect that there's not it's not perfectly fluid um you know once you hit once you hit the problem of uh oh you're using that thing that I gave you and your code base is not my code base I don't have and you're actually under a different project management regime and in fact you might be in a different organization it turns out that that that Changes things

and I remember a team struggling with this in the early 2000s they kept refactoring their interface names and saying kevla and they sometimes people ask you questions when you come in as an outsider they what their people are looking for is permission they're looking at well actually no they're looking for absolution not permission they are looking for a blessing Kathleen we are breaking another team's Code please you know forgive us and tell us that it's all okay okay and that's the problem what they were doing is on a daily basis they were changing their mind

about some apis and breaking in other teams build on a regular basis yeah it turns out that it's social engineering you need at this point it was not a tooling problem okay sometimes of course there are things That we find we cannot change favorite story is clonable or for those of you watching.net I clonable now what is interesting about this is that that's how you spell it in English you'll notice that there isn't that there are that e just disappeared and obviously a lot of people are going like yeah but English spelling doesn't really have

a regular system of spelling you know for those of you who've learned English as a second or third language it may well be the language of the worst and most complicated spelling system that you have ever learned but let me tell you let me assure you the problem is not that English does not have a regular system of spelling the problem is that it has about six or seven regular systems of spelling all at once that's the problem it's not the absence of it it's it's got a surplus you just gotta guess which one are

you Feeling lucky and they got it wrong in fact this is not an remember I said about knowledge and our ability to incorporate knowledge as we go thanks to Twitter I was able to track this one down because I remember we're in the mid 90s I remember somebody pointing this one out right back before it was released before Java 1.0.2 which was the first proper release back in 19 the beginning of 1996 In fact we just passed the anniversary I just realized there we go 17th of January was last week clientable is misspelled with only

one e it's spelled with only one here ask any Genesis including my wife ask any English specialist we'll come back to that such as Henry mcgilton it's embarrassing let's fix it before we shift we can't fix it after and right now very little code relies upon this typo Now there's a couple of things there you will notice English is not spelled correctly it turns out also I had to check this one my Gilton is not spelled correctly either for those who are interested this is a known phenomena it's called muffries law if you write anything

correcting or criticizing the quality of someone else is editing proofing spelling grammar Etc there will be some kind of editorial Error in what you have written yeah anybody experience that one absolutely yeah Murphy's Law is specific application of Murphy's Law right so that one aside there's a point there obviously we can't refactor everything we do have you know there's a kind of a sense in our architecture let's go back to that idea of architecture architecture is the definite one of the Parts of Architecture is the definition of structure it's the definition of boundaries things inside

the boundary are free and easy to change things that are not so easy to change those are architectural they are harder to move um if we I mean the uh those of you who grapple with the architecture of this building the Queen Elizabeth second Center is a is a labyrinth of complexity and brutalist architecture Um there are some rooms where you know so you can actually see it in this room you see these columns here don't mess with those they hold the building up okay everything else everything in space is free to move this stage

is temporary I can move that freely the point here is there are some things you can't change and some things you can ideally you want to minimize the bits that you can't change okay so you want to place your Boundaries and this is something we learn over time you want to place your boundaries to allow freedom on the other side in other words you can strain your degrees of freedom on one side say actually we're going to really it's gonna you're gonna struggle to change the signatory of this interface or anything about this we will

have to have a we'll publish a version in deprecation model but I can't do that just with a simple You know flick of a shortcut but then on the inside I create the spaces that allow me the freedom on the inside that's what you're trying to do maximize the freedom on the other side of those boundaries that's why we obsess so much about classes and components and services and things like that we're looking for more meaningful boundaries that allow us the ease and softness on the inside and recognize that it's gonna be tougher on The

outside but I also want to applaud the achievements of software developers and software development as an industry here's wixionry the entry on clonable notice the spelling but notice the Alternative forms especially in Computing contexts cloneable with that extra e we have changed the spelling of a word through repeated misuse Repetition legitimizes repetition legitimizes repetition legitimizes but it also this is not news we go back to the late 90s Martin offers us advice on this don't publish interfaces prematurely modify your code ownership policies smooth refractory it's talking going about boundaries and the socio-technical side the relationship

to people that's what you Want to do you want to get a wave and this is the interesting thing this runs in the face of the common commonly communicated advice of the open closed principle the idea that your classes should be open to extension and close to modification that's kind of like that's a practice that is based on fear it is a principle that is based on I can't change anything it's actually The opposite of good practice so if you're following ocp or you think you're following ocp according to that don't prefer good practice instead

make code is open to modification as possible instead of rolling over and saying ah can't change it say how do I organize my structure to allow me to be able to change it change is not the problem I want to encourage you I don't want to push it down I don't want to say you're not allowed to do that and I'm also not Going to put in all that noise that encourages extension that kind of like speculative generality we want to move in exactly the opposite direction closed open principle if you want okay ocp is

a failure of good practice it's a failure of architecture if you're doing that so the other things what are the ones that are overlooked extract class so this is interesting Because although rename class and rename method and all these renames have the same kind of grouping in people's minds people are much happier to do extract methods than extract class and there are a number of reasons for that sometimes it's difficult to identify an abstraction but perhaps take the time if you've if you've got a class that's getting too big you know do do start wondering

about it's it's gravitational attraction you know if your class is Kind of like pulling in all the other code then you've got a black hole there and you probably want to do something about it so extracting class is massively underused extract interface is also not particularly used so extraction is not uniformly popular so let's approach in lining things the reverse it's a very useful technique sometimes when you're Trying to make the code move in a different way sometimes you don't want to pull everything out you want to put it all back so you can see

what's going on and then re-partition it reorganize it it's actually an instinct I found I run some refactoring workshops and I always fascinated people immediately reach for extract method as one of the first refactorings was actually it's kind of something you should do a little bit later in many Cases not all cases it'd be context sensitive replace one thing with another one construct with another getting rid of stuff is also important as I observed a few years ago we keep talking about incremental development we don't talk enough about decremental development get rid of stuff okay

streamline the thing okay your knowledge allows you to say this is dead code nobody's using this What's it doing in the code base I've wasted time and a new code base looking through something only to be told by another developer oh don't look at that we don't use that or why is it in the code it doesn't cause any harm I've just spent a day looking at it you know I mean I don't feel injured by it but you know time wise we've taken it here so let me just give you a very simple toy

example Let's mess about with Roman numerals because obviously that's something that everybody does on a daily basis in their enterprise software actually it probably would improve a lot of things to be fair um but speaking of enterprise software here is how we might approach this one so this is Python and this is uh you can't see everything so let's re resize there you go again if you've been paying by the line Of code there is absolutely nothing wrong with this but that's the thing about all toy examples what I love about a lot of coding

Carters is you people kind of go Ah that's too simple that's a toy example then you go straight into the code base they're working on you go yeah and it's exactly like the logic that you've got here okay sometimes you have to kind of look through this as a lens to see something Else so this is how to convert an integer into Roman numerals there's nothing wrong with it it works in that sense if that's our only goal I don't regard this as particularly good it's brutally imperative it's unnecessarily imperative okay this does not need

to be even if you're doing procedural coding this is Relentless in a way that I would not expect anyone to Recommend yet curiously as a collector of old books in software and I kind of lived through the period where people recommended Pascal as a good language because it will teach you good practice and it's got good language design and you know what I was foolish enough to believe people Pascal is a terrible language it's really badly designed and it does not promote good practice in any way it's massively limited every now and then I will

get Somebody either in person or on Twitter who comes up to try and correct me of this and they say oh but I really like Delphi that's fine but that's not Pascal the only way that that language was any good is because they took the original and said wow this sucks let's add things to it in other words they made it palatable it is so limited that you cannot express well in fact let's just look at the example There it is I was leafing through it and oh Roman numerals done it exactly the way that

I said you shouldn't do it so let's actually try and amend this now what a lot of people will do when looking at this is they will seek out a pattern now I'm expecting you to see the detail of this it's intentionally small enough that only only people with good eyesight in the back will be able to see this and I I don't want you to look at that I want You to sometimes the trick with code is to try and take a step back and squinted it okay or alternatively just choose a smaller font

what do you see what's the form of it you can see a lot of repetition structure so we're going to refactor this and we're going to do so in a way that we don't break it and in fact here's the tests in fact you don't even need a testing framework so This is this is what I used with this one as a variation what I used so here is testing without a testing framework we're going to look at that and we're going to go what do I see first of all um and the contrast on

that is absolutely terrible that's a real shame um yeah contrast is terrible okay um that you see that's what you get for having a colorblind guy do the slides um so Um what we see is that there are groupings of four while if if while if if while if if and then one while left over what many people see is this recurring structure in other words if we reframed it while a number is greater than or equal to 10 something it might be 10 100 1000. if number is greater than or equal to nine something

it might be 9 90 or 900 and the same for five fifty five hundred Four forty four hundred in other words there's a repeating structure and then people will be tempted to extract method of this repeating structure premature refactory hold yourself back a little bit take another look it turns out in this case if you look at this and squinted it just right the thing to remember is that and this is the whole thing about looking at things from different points of view and why refactoring is not just a simple Simple activity in the sense

of it requires a little bit of insight those ifs sometimes in the limit and if behaves just like a while in the sense that an if execute zero one times it's a very limited while in this particular case because of the way the values fall you can replace all of these with while and it still works which means that you're repeating unit Is in fact this which leads to a completely different style of solution even if you're doing although this is strongly declarative it's data driven people don't get taught about data driven techniques enough um

they don't get taught about as a first class Paradigm or combining Paradigm this is very procedural it's got a procedural for Loop but this is a technique that I would Expect NEC program at least not I wouldn't expect a pascal program tonight if I expect any c programmers to know it from way back when but it's also something that is yeah drop dead easy in pretty much any language the idea is let's drive it with data what is the commonality look for the data structure now the late Frederick Brooks made this observation back in the

1970s representation is the essence of Programming sometimes the Strategic breakthrough will be a new algorithm much more often strategic breakthroughs will come from redoing the representation all of the data or tables this is where the heart of the program lies the idea of try and understand the structure of the data and then invert the control with respect to that was far too often when people refactor they're just kind of nibbling at the edges and just taking the surface Phenomena and refactoring those and tying those up and often bundling them away into extract method so we

can imagine here 's another little example this is in C sharp what I've got here I go through here I go right I've got a new list so I've been given some list of words maybe it's an innumerable maybe it's actually another list maybe it's an array I've got a list of words So I create a copy of that then I sort it and then I drop in I drop abstraction level into a bunch of mechanics okay it's just like there's a there's a real there's a real change here this idea that you should try

and work at the same level of abstraction if you suddenly find yourself dropping into mechanics it doesn't mean you don't want the mechanics it just means you need to kind of think well hang on I said the first thing I said was take a copy then I said sort it and now I say what set up a variable assign it to null okay you're the wrong level here and there's a whole load of horsing around which is ultimately about removing duplicates so let's call it that remove duplicates so this is C Sharp I can make

it an extension method and confuse all my colleagues we can improve on the naming because It's not really about removing duplicates it's about removing adjacent tube because that's the more honest one the precondition is that it must be sorted to remove all duplicates but actually it's just about removing adjacent duplicates and for a lot of people they go huh yeah we're done we've improved it some people will then say stand back I know link oh no I'd ask you to stand back That's not a big Improvement I'm afraid um I know the repetition legitimizes but

if you've got the same variable occurring three times in a single expression you've got to say that's a smell a better use of Link would not to be used to use the keywords and would be this form and we might might Pat ourselves on the back say we are done but then I hear the words of the late Fred Brooks representation is the essence of programming huh oh yeah that's what I wanted what I wanted was basically a collection of unique words in sorted order and what I've done is and what's funny is that people

often say oh yeah you're using functional thinking here yeah look at me using data structures so The whole point is this is the most declarative of all of them I've just said what I want I'm not telling you how to do it I'm not giving you a process this is that so sometimes refactoring will take us down some surprising Avenues some different insights and it's a reminder dijkstra observed back in 72 the purpose of abstraction is not to be vague we often Associate abstract and abstraction sometimes with being vague which actually is this Precision to

create a new semantic level in which one can be absolutely precise it's to be specific this is what I really mean I want to tell you if I've got something there that does exactly what I need I might not realize that and importantly that progression I just showed you is not a is not to diss anybody forever having this code or go through those Steps sometimes those steps are necessary intermediates until something becomes so obvious you go ah wow why did I not see this before you couldn't have seen it before you were locked into

a different mindset refactoring is getting your hands dirty in the codes playing with the clay okay it's actually reshaping it go oh now I understand you thought you understood when you started but only when you start manipulating it he's like oh now I'm Best about with it six ways to Sunday I can now figure out the seventh way so final piece I'll look at um another one from 97 things to show you kind of a radical reframing one I've used a number of times one of my favorite pieces from that book by uh Burke hoffnerville

although I'm not supposed to say as the editor I have favorite pieces um put the mouse down step away from the keyboard first of all great title It tells you exactly how to deal with most problems you get so entrenched at the level at which you found the problem you try everything and exhaust that level and the only thing apparently left you is to invest more time and what you do is you push harder at the thing that's not working for you you're stuck at that level take step back do something in fact I often

tell people whatever it is that you're not doing try That as in if you are currently sitting try standing if you are currently standing try sitting if you are listening to music turn the music off if you're not listening to music Turn some music on yeah if I'm messing about with code or working typically I will listen to ambient music [Music] um Uh or I'll listen just sort of uh sort of rainforest or ocean sounds if I'm stuck with something sometimes I turn that off or alternatively I put on some progressive metal you just need

to get your mind because clearly wherever you are is not helping you you need to move somewhere else if you've been drinking caffeine all morning guess what herbal tea is a really good Break from that if you're saying ah I'm virtuous I don't drink caffeine try it try it come to the dark side but that's the thing it'll change the way you think go for a walk have a chat with somebody yeah don't don't try and ring up somebody that you currently have a grievance with like your you know uh like a provider yeah yeah

no no you did say that we'd be reconnected by Tuesday that's just going to get you angry But do something else why because it gives you a different Insight it refreshes things you take you save time by doing something else rather than investing on that kind of problem so here is a piece of code that um Burke was looking at in fact this is not the piece of code book was looking at this is the piece that after he refactored it the first time so it must have been quite frightening the first time He took

some code he said okay let's cook it down and that's the important thing a lot of people stop here they do the kind of the cooking down they kind of a little bit extract meth a little bit of tidying up the logic a few renames and a bit of movement but they haven't actually challenged or the the the the Assumption of where the code is and sometimes you can't do that immediately that's fine but that's why he you know put the mouse Down and stepped away from the keyboard but you can see there's a lot

going on here and in fact you know the the thing I want to point out is there's a dot dot dot here there's a lot more of this stuff this is relentlessly imperative we're trying to parse a string to see if it contains a valid 12-hour time it's a brutal way of doing it so anyway he steps away from the keyboard I suddenly realized wait a minute This is a pack magic problem why am I why am I doing all of this this is a really painful way to do it again I refer you to

large amounts of code in the world now of course there is the idea that sometimes people say you know I had a problem I solved it with a reg X now I have two problems or Star problems if you're being incredibly accurate but sometimes it's just the right thing and what's great is if you even if you Don't know reg X's it's really easy to explain so I can take my younger son he's 17. you know as python I can walk him through this Java he will have lost interest before we reach the dot dot

dot just what do you think what's the explanation sound like he's seen exceptions before all this kind of stuff in fact probably you say Dad why didn't they do it in Python and I'll say son I don't know python solves surprising number of problems it's not perfect but when it comes to string manipulation Java is one of the most painful ways of doing it um it's like putting needles in your eyes just not as much fun um but here I don't think my son knows reg axes but I can walk left to right I'm trying

to find out where this string Matches oh well there we go immediately a grouping of zero followed by one to nine or one followed by zero to two and then account because then height zero followed by zero to five and then zero to nine fight okay um repetition legitimizes um now the point here is I've just read that left or right that's the property of Declarative code in many forms of declarative code showing the data structure you just literally described the shape of the problem then all you need is a little icing a for Loop

or an appropriate method and that does the thing this is the kind of thing that we need to be encouraging ourselves but notice there is no name to refactoring for this I've changed the design by having to I've jostled the existing design around Probably through automation automated refactorings I've jostled it around and then eventually break now so that brings us onto the home straight and the need for coffee because I realize I have overrun by five minutes I took you back in time let's take you back further let's go back to the 19th century this

is Isabella Beaton who died sadly very young not even 30 I don't think but um she wrote a series of Columns um on household management that got collected into a book and her Mrs beaton's book and Mrs beaton's cookery book were actually kind of they survived well into the 20th century as a kind of a byword for how to think about you know actually the engineering and the engineering of the processes of your of your home um but when it came to kitchens it turns Out that she was an early adopter of refactoring there is

no work like early work how we live our lives is of course how we spend our days clear as you go model makes more model yeah she was talking about code but Babbage had not yet invented the Difference Engine so she was forced to talk about kitchens instead not to wash plates and dishes soon after using makes more work yeah see the word See it's all about refactoring cleverly coded but also if we relate the activity of writing code to the active other activities of writing Ernest Hemingway left us with the simplest advice the only

kind of writing is rewriting thank you very much okay I don't have any time for questions so I could have the mic up okay I don't have any time for questions or other I Do but well let's take those offline I'm around for coffee and all the rest of the day but yeah have a good rest of day