The "don't name negatively" is (more or less) in Aristotle in his discussions of classification. Hence Kevlin's advice has a very old pedigree. Also, functional requirements are often features, hence things, where as many of the "non-functional requirements" are properties (e.g., security, accessibility). Hence they are *metaphysically different*, and in particular, inseparable from the features they apply to.
But the world has abandoned Aristotle for errors from the likes of Kant, Nietzsche, et al., and that's why our industry is now miserable while everyone pretends that everything is just fine. Our industry right now (among other aspects of society) is literally the This Is Fine meme personified. There's a reason why you can easily find hundreds of talks and conferences about "No, this is how you program!" and not, "No, this is how you do !", and there's a reason why there are hundreds of programming languages, most of the new ones trying to solve other languages, while the older ones fail to properly solve software engineering, so the cycle of new programming tools is perpetuated because no one wants to address CSE. They're all trying to fix C, and then simultaneously account for the technical debt that should have never been incurred with regard to programming _discipline_ in the first place, hence why things like "Clean Code" (among other things) take off because people are frantically grasping for something solid (pun not intended) to guide them and make their code good all the time since by no fault of their own, they don't understand how their code gets bad in the first place, especially when everything is reduced to subjectivism!
This speaks to my heart. So often I've had other devs go on about this or that when my natural inclination is toward his descriptions here. Carefully understanding your problems and clarifying as you go.
I always think of refactoring as relates to "factors of production" in industry, rather than mathematical factors. The factors are the pieces that go into a product, refactoring in a sense changes the pieces of a software product without changing the product as a whole.
He's been giving the same old talk for years, but in a different way and repackaged up with different titles. You could say he's constantly refactoring it.
Refactoring can be as simple as renaming the conditions of an if-statement. If I see a complex if-statement, I'll almost always give it a local variable at the very least. It makes life easier for the next person looking at the code.
I think I don't quite like Fowler's definition of refactoring - I would delete the part about making it easier to understand and cheaper to modify, and say that a refactoring is simply any change made to the internal structure of software that does not change its observable behaviour. Then refactoring can be done for any reason, good or bad, and we don't have to know someone's motives to be able to tell whether what they are doing is refactoring or not.
I would change it "toward some stated goal" rather than remove it. That way you are codifying that refactoring is not just performing an operation and then its inverse, that you have some idea (even if loosely defined) of where you are going/why you are refactoring the code. With the trader example, that is "so I can better understand the logic at the point at which it is used, so I don't have to repeatedly add the same comment". It may also be something like "so I don' have unnecessary code" (like in the time regex example), or it may be "so I can lay the foundation to implement some new task/feature I'm working on".
@@barneylaurance1865 Maybe "toward some goal or outcome" is better. That is, you don't have to explicitly state the goal, just know the general direction to travel in. This is to in some way to codify the idea that refactoring isn't about repeatedly applying rename, extract, etc. refactorings, but applying them to achieve some goal (either implicitly or explicitly stated). Otherwise, your refactorings are aimless. Even though you are applying refactoring techniques (the noun), I wouldn't call that refactoring (the verb).
i need to write this comment down because i won't be able to focus on either this video or my work until i do ... the result of refactoring is often briefer, simpler code ... but it also often happens that new pathways are revealed for code execution that improve the performance of the code, and in some cases even open possibilities for new (QoL) features to be added
55:58 Because this is written in python I'm going to assume that it will run on a high performance CPU and not on a microcontroller. So this refactor might be appropriate, but still I would like to see some performance testing on it and not just "it does what we expect" unit tests. Because the original had a lot of branches there is a chance it performed poorly in today's highly pipelined architecture (though they have good branch prediction and speculative execution). Also because it is python performance probably doesn't matter and even if it wasn't it wouldn't. But please don't refactor code like this on 8 bit or even 32 bit micro controllers that don't have hardware multiplier or divider ! The original code design (written in C) would run perfectly fine on an 8 bit AVR, or a cortex M0 ARM, while the rewritten one will be slower and bigger. (And it might also be harder to understand.) And if you think this is premature optimization then you might be right but also don't be surprised how a modern text editor runs slower on current hardware than old ones did on much slower machines.
This guy questioned the term "Technical Debt", questioning the word "Technical" and completely ignored "Debt". The word "Debt" has far more reaching impact. How about using the word "Health" instead?
debt is bad. would you rather have debt or not? If you could, would you prefer to pay the house now and be done with it, or would you rather have your structured repayment for the next 50 years? Clearly debt is worse than the alternatives. Debt might be necessary to get your house, but it's not a good thing. You simply made the call that the house is worth more to you than the negatives of being in debt.
I think you missed his point and the point of debt, in general. Debt is _not_ bad if the utility gained from your expenditure is greater than the cost of the debt. If I get a car loan to enable me to goto school or a job, arguably that's good debt. If it's a choice between owning a house *now* or owning a house in 50 years after I saved up enough then the _loan repayments_ are arguably "not a good thing" but they are in service to me having a house now, instead of in 50 years. Put in moralistic terms, if you save my life and I say, "I am in your debt." I owe you my life, for me, I'd much rather owe you that huge debt of gratitude than be dead. In these ways, we find utility in debt. It's at the heart of ideas around reciprocity and I don't think it can be painted as always bad.
Debt is not bad, it is a liability. You take a debt to do something quickly (right now) instead of waiting. It will turn bad if you do not manage your debt. This is same with financial as well as tech debt.
Stopped watching after the Pascal rant: claims Pascal is a badly designed langugage, tries to support claim by presenting an improved algorithm that could be coded in Pascal just fine lmao
It's funny... I was looking at some old Pascal this morning and was thinking "oh look, in that module, a closure, and some STRONG typing.... doesn't it look like TypeScript?" .... no lambdas or monads though.
K. Henney is one of the very few speakers in the tech industry, whose talks one can be certain will be worth the time spent listening to.
Love this talk! Kevlin always makes these topics fun and interesting :)
Great talk that focusses on the true essence and origins of the Refactoring word.
The "don't name negatively" is (more or less) in Aristotle in his discussions of classification. Hence Kevlin's advice has a very old pedigree. Also, functional requirements are often features, hence things, where as many of the "non-functional requirements" are properties (e.g., security, accessibility). Hence they are *metaphysically different*, and in particular, inseparable from the features they apply to.
But the world has abandoned Aristotle for errors from the likes of Kant, Nietzsche, et al., and that's why our industry is now miserable while everyone pretends that everything is just fine. Our industry right now (among other aspects of society) is literally the This Is Fine meme personified. There's a reason why you can easily find hundreds of talks and conferences about "No, this is how you program!" and not, "No, this is how you do !", and there's a reason why there are hundreds of programming languages, most of the new ones trying to solve other languages, while the older ones fail to properly solve software engineering, so the cycle of new programming tools is perpetuated because no one wants to address CSE. They're all trying to fix C, and then simultaneously account for the technical debt that should have never been incurred with regard to programming _discipline_ in the first place, hence why things like "Clean Code" (among other things) take off because people are frantically grasping for something solid (pun not intended) to guide them and make their code good all the time since by no fault of their own, they don't understand how their code gets bad in the first place, especially when everything is reduced to subjectivism!
yap yap yap what's your body count
This speaks to my heart. So often I've had other devs go on about this or that when my natural inclination is toward his descriptions here. Carefully understanding your problems and clarifying as you go.
it helps to remember what "refactoring" actually means: re-doing which factors go into the solution. not renaming, lots of people forget that.
"don't name things negatively" should be "name things positively."
I always think of refactoring as relates to "factors of production" in industry, rather than mathematical factors. The factors are the pieces that go into a product, refactoring in a sense changes the pieces of a software product without changing the product as a whole.
He's been giving the same old talk for years, but in a different way and repackaged up with different titles. You could say he's constantly refactoring it.
Nice too see a speaker practice what they preach.
Refactoring can be as simple as renaming the conditions of an if-statement. If I see a complex if-statement, I'll almost always give it a local variable at the very least. It makes life easier for the next person looking at the code.
I just pull it out as a method and give it a very explicit name.
@@d7ffab979 If it's used in multiple places I do that too. Otherwise a local variable will be good enough.
I think I don't quite like Fowler's definition of refactoring - I would delete the part about making it easier to understand and cheaper to modify, and say that a refactoring is simply any change made to the internal structure of software that does not change its observable behaviour. Then refactoring can be done for any reason, good or bad, and we don't have to know someone's motives to be able to tell whether what they are doing is refactoring or not.
I would change it "toward some stated goal" rather than remove it. That way you are codifying that refactoring is not just performing an operation and then its inverse, that you have some idea (even if loosely defined) of where you are going/why you are refactoring the code.
With the trader example, that is "so I can better understand the logic at the point at which it is used, so I don't have to repeatedly add the same comment". It may also be something like "so I don' have unnecessary code" (like in the time regex example), or it may be "so I can lay the foundation to implement some new task/feature I'm working on".
@@msclrhd So what would you call someone making changes to internal structure without stating a goal?
@@barneylaurance1865 Maybe "toward some goal or outcome" is better. That is, you don't have to explicitly state the goal, just know the general direction to travel in.
This is to in some way to codify the idea that refactoring isn't about repeatedly applying rename, extract, etc. refactorings, but applying them to achieve some goal (either implicitly or explicitly stated).
Otherwise, your refactorings are aimless. Even though you are applying refactoring techniques (the noun), I wouldn't call that refactoring (the verb).
@@msclrhd what would you call it then? I'd just call it aimless refactoring. I might say "don't refactor aimlessly".
@@barneylaurance1865 That's a good name for that. I'd use that too.
I would like to live in a make believe fantasy world where code is clean and understandable, and where you sleep 8 hours/day every time.
I will follow your advice on playlist. I'm kind of locked on "know your ennemy"'s songs lately 😊
"Architecture is for developers to live in". I like that 😄
The regex at 1:03:38 doesn't consider leap seconds, which could be quite interesting... occasionally ;-)
i need to write this comment down because i won't be able to focus on either this video or my work until i do ... the result of refactoring is often briefer, simpler code ... but it also often happens that new pathways are revealed for code execution that improve the performance of the code, and in some cases even open possibilities for new (QoL) features to be added
He got me with the first IDE refactoring tweet 🙀
03:28 technical debt
05:50 technical neglect
55:58 Because this is written in python I'm going to assume that it will run on a high performance CPU and not on a microcontroller. So this refactor might be appropriate, but still I would like to see some performance testing on it and not just "it does what we expect" unit tests. Because the original had a lot of branches there is a chance it performed poorly in today's highly pipelined architecture (though they have good branch prediction and speculative execution). Also because it is python performance probably doesn't matter and even if it wasn't it wouldn't.
But please don't refactor code like this on 8 bit or even 32 bit micro controllers that don't have hardware multiplier or divider !
The original code design (written in C) would run perfectly fine on an 8 bit AVR, or a cortex M0 ARM, while the rewritten one will be slower and bigger. (And it might also be harder to understand.)
And if you think this is premature optimization then you might be right but also don't be surprised how a modern text editor runs slower on current hardware than old ones did on much slower machines.
Love this guy’s insights but I wish he would condense his talks better.
Wtf?... this guy's first few minutes is so funny so far...
24:24 Morshu, is it you?
This guy questioned the term "Technical Debt", questioning the word "Technical" and completely ignored "Debt". The word "Debt" has far more reaching impact. How about using the word "Health" instead?
Debt is something we have to pay back. In that context, it is more appropriate.
repetition legitimizes
debt is bad. would you rather have debt or not? If you could, would you prefer to pay the house now and be done with it, or would you rather have your structured repayment for the next 50 years? Clearly debt is worse than the alternatives. Debt might be necessary to get your house, but it's not a good thing. You simply made the call that the house is worth more to you than the negatives of being in debt.
I think you missed his point and the point of debt, in general. Debt is _not_ bad if the utility gained from your expenditure is greater than the cost of the debt. If I get a car loan to enable me to goto school or a job, arguably that's good debt. If it's a choice between owning a house *now* or owning a house in 50 years after I saved up enough then the _loan repayments_ are arguably "not a good thing" but they are in service to me having a house now, instead of in 50 years.
Put in moralistic terms, if you save my life and I say, "I am in your debt." I owe you my life, for me, I'd much rather owe you that huge debt of gratitude than be dead. In these ways, we find utility in debt. It's at the heart of ideas around reciprocity and I don't think it can be painted as always bad.
Debt is not bad, it is a liability. You take a debt to do something quickly (right now) instead of waiting. It will turn bad if you do not manage your debt. This is same with financial as well as tech debt.
Stopped watching after the Pascal rant: claims Pascal is a badly designed langugage, tries to support claim by presenting an improved algorithm that could be coded in Pascal just fine lmao
I still had to keep watching because I'm a massive KH fan boy.... doesn't mean I didn't get very cross indeed about what he said about Pascal though.
It's funny... I was looking at some old Pascal this morning and was thinking "oh look, in that module, a closure, and some STRONG typing.... doesn't it look like TypeScript?" .... no lambdas or monads though.
Hardly a rant, more of an aside. Let's not get our keyboards in a jumble.