Growing up in an environment where people shamed my quest for elegance with the attitude "It ain't broke, why are you pissing me off and wasting my time and money fixing it," the case for elegance and intuition are quite refreshing.
Also completely unprofessional. If it ain't broke, you don't "fix" it. Not for the reasons mentioned but for the obvious risk that the fix will have side effects that are neither elegant nor easily predictable. Your desire to fix working systems for beauty is basically just the amateurish hubris that you can predict exactly what your solution will do and that it's actually better than the solution of somebody else that you just don't like.
Did some note of Martin's talk as take away. "Workflow of Refactoring" by Martin Fowler @OOP2014 Two modes of code development 1) adding functions and 2) refactoring (including performance improvements). Rule of thumb: Separating refactoring keeps work focused Mindset of refactoring: when you see something yuck you do something to fight against it. Scenarios of refactoring: 1) Litter-pickup Refactoring (Something yuck but easy to address): Refactoring it to a green state then start your feature work. 2) Comprehension Refactoring (Complex logic you spend time to understand): Refactoring if possible or adding comments on how you understand that piece of logic and queuing tasks with enough context. 3) Preparatory Refactoring (Refactoring is benefiting your feature work) Then refactoring first. 4) Planned refactoring. Try to avoid such unless it has economic purpose and become necessary evil. a) First break it into small pieces. b) Then developers to tackle those piece by piece whenever touch that scope of code. Refactoring is not unwanted wasteful rework if it has economics purpose - improving agility / not slowing developers down.
This talk was very focused and clear. Like the audience or managers already know the idea but this hammers it out with the reasons that sometimes get lost in longer talks. Made some points make more sense to me to convince others.
So this video confirmed that my workflow isn’t that messy after all. I usually start with a rough sketch of a requirement by writing/drawing them down. Then i try to build the feature asap. I more or less ignore all the rules that are in my code, which mostly results in a big class with everything in it. After everything works i than clean up my new code by refactoring it. 🙏🏻🙂
Refactoring is usually the admission that you got it all wrong on your first try. I had projects where I gave up refactoring in the middle of it and I just wrote the entire thing from scratch by reusing just the bits that actually worked great. The final result was always much better than what the refactored code could have been under the best of circumstances. I am not even bothering with refactoring anymore. When I see an architectural flaw I go in and fix it completely.
when i was adding an icon to a list of things i found very overly complex code, but had no time to fix it. How should one deliberately schedule this work, when the management would never justify the extra time.?
It's difficult if you have metrics based on number of features added, but possibly the best way is to do it in small chunks as part of your day-to-day work, and discuss it in terms of keeping the code in a state where it's easy to add features. As long as managers can see that what you're doing is supporting the goals they have, and not competing with those goals, it's easier to justify time spent refactoring.
I liked the last slide: When you talk about Refactoring, Don't talk about the Quality, Clean-Code, Professionalism, Right-Thing etc. Just think and talk about Economics.
All these refactoring and TDD talks are great, but they are missing out one thing. Not everyone in team agree on what and how clean code is, or even agree on test is a thing to do in software dev. Some people just prefer long, long, Long messy procedural code in 1 method, (people see their own mess as fine) while other think refactored code is too complicated and hard to read as they scroll. (like private helper method is unnecessary) Some senior lead even punish you if you refactor even one small section of code under the belief on _"if it ain't broke, don't fix it"_ and _"we got to deliver the feature by Tuesday."_
Mentor those folks to help them see themselves as professionals who take pride in their work (this will only work if there are unit tests you can trust for every piece of code you touch - which means you have to write them, making this approach infeasible). If they insist on being IT hacks only there for a paycheck, get another job where your superior skills are valued; if you stay you will soon be buried under their technical debt and "next Tuesday" will become "next year".
what about legacy code, where there are large swaths of bad code that warrant deliberate refactoring with no new features directly being added immediately, but would definitely prepare for easier addition of new features later.
Harlan Mills' editor - himself a CS Professor at NYU who taught me data structures - told me that Mills' approach was terrible. For example, he hardcoded everything. In the NY Times project, the resolution of the 5" screen on the terminals appeared throughout the System, which affected screen layout, records, field sizes, etc. Shortly thereafter, the Times moved to larger monitors and the entire System had to be rewritten.
The idea of evolutionary design is cancerous because that it gets people to believe it's better to focus on the immediate task at hand and stubbornly ignore the obvious issue that will hit you one year down the road. Many times I heard developers saying "oh don't worry about the data layout too much, you can always change things later if you need to". Turns out, some things are much harder to change than others, especially when you're working on data-intensive applications.
Watch Fowler's talk on Agile Architecture, which is designed to specifically address this characteristic of Waterfall. Uncle Bob's talks on the subject give more details
why not just do it right the first time? why rush out crap and then go back and redo it? customers don't care about your process, they care that they get a quality product
Mary McGloin because new ideas come along that don't fit into the old way the code was written. e.g. statistics charting application becomes interactive with animated transitions. The original chart app may well have worried about preparing data sets and putting them on a chart. The new app needs to correlate datapoints from one state to another and animate on a chart. Probably need to introduce some new objects and then refactor across them.
Mary McGloin Exactly. Add the new feature; lots of new code and gain an understanding of how it interacts with the existing code till you get it to work (warts and all). Then, refactor the code to update the patterns/interactions to meet the new need. I have found that mixing refactoring and new functionality takes a very long time and you have long periods where everything is up in the air and mistakes are made.
+Mary McGloin There are lots of reasons why code needs to be changed. First, customers will choose a product they can use--even if it has some bugs--over a product that hasn't been released because it isn't perfect yet. And sometimes the code works perfectly well, except it can't easily be modified to add new features. It's not that it wasn't "right" the first time, it's that the definition of "right" has changed.
I'm aware of that. I'm speaking of when code is shoved out quickly into production with hacks and known issues to adhere to a very inflexible "agile" process, the idea being one can "iterate" fixes quickly. Reality is, you end up with an unstable, unreliable product (lose customers) and driving your dev and QA team nuts because you're always in fire mode
He refactored his older talk.
Nice one.
Growing up in an environment where people shamed my quest for elegance with the attitude "It ain't broke, why are you pissing me off and wasting my time and money fixing it," the case for elegance and intuition are quite refreshing.
Also completely unprofessional. If it ain't broke, you don't "fix" it. Not for the reasons mentioned but for the obvious risk that the fix will have side effects that are neither elegant nor easily predictable. Your desire to fix working systems for beauty is basically just the amateurish hubris that you can predict exactly what your solution will do and that it's actually better than the solution of somebody else that you just don't like.
Even though I find this gem 7 years late, it is still a big help. Thank you for the superb explanation
Did some note of Martin's talk as take away.
"Workflow of Refactoring" by Martin Fowler @OOP2014
Two modes of code development 1) adding functions and 2) refactoring (including performance improvements).
Rule of thumb: Separating refactoring keeps work focused
Mindset of refactoring: when you see something yuck you do something to fight against it.
Scenarios of refactoring:
1) Litter-pickup Refactoring (Something yuck but easy to address): Refactoring it to a green state then start your feature work.
2) Comprehension Refactoring (Complex logic you spend time to understand): Refactoring if possible or adding comments on how you understand that piece of logic and queuing tasks with enough context.
3) Preparatory Refactoring (Refactoring is benefiting your feature work) Then refactoring first.
4) Planned refactoring. Try to avoid such unless it has economic purpose and become necessary evil.
a) First break it into small pieces.
b) Then developers to tackle those piece by piece whenever touch that scope of code.
Refactoring is not unwanted wasteful rework if it has economics purpose - improving agility / not slowing developers down.
thanks a lot,it saves me time to take a note!
Great talk . "Clean code allows you to go faster"
This is super amazing. Strangely, it has a pretty low view count. I wish more devs watch this stuff.
This is a great talk on how to approach your day-to-day work. It was needed for a long time.
Very wisely thoughts about why refactoring matters and how it makes difference.
Thank you Mr Fowler for the education.
This talk was very focused and clear. Like the audience or managers already know the idea but this hammers it out with the reasons that sometimes get lost in longer talks.
Made some points make more sense to me to convince others.
So this video confirmed that my workflow isn’t that messy after all. I usually start with a rough sketch of a requirement by writing/drawing them down. Then i try to build the feature asap. I more or less ignore all the rules that are in my code, which mostly results in a big class with everything in it. After everything works i than clean up my new code by refactoring it. 🙏🏻🙂
Great talk by one of the titans of software engineering. Who better to discuss refactoring than the guy who originated it.
Refactoring is usually the admission that you got it all wrong on your first try. I had projects where I gave up refactoring in the middle of it and I just wrote the entire thing from scratch by reusing just the bits that actually worked great. The final result was always much better than what the refactored code could have been under the best of circumstances. I am not even bothering with refactoring anymore. When I see an architectural flaw I go in and fix it completely.
Great talk.
Very well expressed! Great examples
when i was adding an icon to a list of things i found very overly complex code, but had no time to fix it. How should one deliberately schedule this work, when the management would never justify the extra time.?
It's difficult if you have metrics based on number of features added, but possibly the best way is to do it in small chunks as part of your day-to-day work, and discuss it in terms of keeping the code in a state where it's easy to add features.
As long as managers can see that what you're doing is supporting the goals they have, and not competing with those goals, it's easier to justify time spent refactoring.
I liked the last slide: When you talk about Refactoring, Don't talk about the Quality, Clean-Code, Professionalism, Right-Thing etc. Just think and talk about Economics.
you can still think of them, only as effects/benefits of a job well done
Great examples
All these refactoring and TDD talks are great, but they are missing out one thing.
Not everyone in team agree on what and how clean code is, or even agree on test is a thing to do in software dev.
Some people just prefer long, long, Long messy procedural code in 1 method, (people see their own mess as fine)
while other think refactored code is too complicated and hard to read as they scroll. (like private helper method is unnecessary)
Some senior lead even punish you if you refactor even one small section of code
under the belief on _"if it ain't broke, don't fix it"_ and _"we got to deliver the feature by Tuesday."_
Mentor those folks to help them see themselves as professionals who take pride in their work (this will only work if there are unit tests you can trust for every piece of code you touch - which means you have to write them, making this approach infeasible).
If they insist on being IT hacks only there for a paycheck, get another job where your superior skills are valued; if you stay you will soon be buried under their technical debt and "next Tuesday" will become "next year".
what about legacy code, where there are large swaths of bad code that warrant deliberate refactoring with no new features directly being added immediately, but would definitely prepare for easier addition of new features later.
I'd start by writing tests from the outside in. Get all tests written, then start refactoring as required, writing new tests if necessary.
As he said, you don't have to refactor everything but at least do something. Extract out some logic or even just create a test
Tfw this is part of my curriculum.
Very engaging
How are there comments 3 months old on this when it says Published on 14 Jul 2014? :-D
Bravo
I would like to see the likes of Martin debate the ideals of Harlan Mills directly.
Harlan Mills' editor - himself a CS Professor at NYU who taught me data structures - told me that Mills' approach was terrible. For example, he hardcoded everything. In the NY Times project, the resolution of the 5" screen on the terminals appeared throughout the System, which affected screen layout, records, field sizes, etc. Shortly thereafter, the Times moved to larger monitors and the entire System had to be rewritten.
3 dislikes? that's interesting!
The idea of evolutionary design is cancerous because that it gets people to believe it's better to focus on the immediate task at hand and stubbornly ignore the obvious issue that will hit you one year down the road. Many times I heard developers saying "oh don't worry about the data layout too much, you can always change things later if you need to". Turns out, some things are much harder to change than others, especially when you're working on data-intensive applications.
Watch Fowler's talk on Agile Architecture, which is designed to specifically address this characteristic of Waterfall. Uncle Bob's talks on the subject give more details
@@BangsarRia what characters of Waterfall?
why not just do it right the first time? why rush out crap and then go back and redo it? customers don't care about your process, they care that they get a quality product
Mary McGloin because new ideas come along that don't fit into the old way the code was written. e.g. statistics charting application becomes interactive with animated transitions.
The original chart app may well have worried about preparing data sets and putting them on a chart. The new app needs to correlate datapoints from one state to another and animate on a chart. Probably need to introduce some new objects and then refactor across them.
But then it's just a new feature.
Mary McGloin Exactly. Add the new feature; lots of new code and gain an understanding of how it interacts with the existing code till you get it to work (warts and all). Then, refactor the code to update the patterns/interactions to meet the new need.
I have found that mixing refactoring and new functionality takes a very long time and you have long periods where everything is up in the air and mistakes are made.
+Mary McGloin There are lots of reasons why code needs to be changed. First, customers will choose a product they can use--even if it has some bugs--over a product that hasn't been released because it isn't perfect yet. And sometimes the code works perfectly well, except it can't easily be modified to add new features. It's not that it wasn't "right" the first time, it's that the definition of "right" has changed.
I'm aware of that. I'm speaking of when code is shoved out quickly into production with hacks and known issues to adhere to a very inflexible "agile" process, the idea being one can "iterate" fixes quickly. Reality is, you end up with an unstable, unreliable product (lose customers) and driving your dev and QA team nuts because you're always in fire mode