Explaining Refactoring to Management
- Share
-
- |
Read later
Reading List
How can one justify refactoring to a CEO, and to other people with a non-technical background?
In a discussion with the topic "Refactoring Justification Language", Adam Sroaka, Agile Coach with BigVisible, said: “Refactoring is essential because requirements inevitably change and therefore code inevitably changes to satisfy them. When code which adheres to principles of good design is changed it may no longer adhere to those principles. Refactoring is a technique that allows us to improve the design of the code once we have changed it.”
Michael James, Certified Scrum Trainer with CollabNet, focused on refactoring while coding test first. He explained that our initial attempt to write new code is almost always a little bit messy so he and his pairing partner take the time to clean up.
Ron Jeffries, one of the XP founders, explains in a post entitled "Why is Refactoring a “Must”?" that given we can’t deliver all the infrastructure necessary for a Scrum Project in a two week sprint, we must be prepared to refactor in order to improve, otherwise we will end up with a mess that will slow our project team down. He also points out that a fundamental assumption of Scrum and any other Agile approach is that requirements will change. If the requirements change then the code needs to be refactored to clean up the loose ends that are left over.
On the same "Refactoring Justification Language" thread, Michael James added that even in a word of static requirements refactoring would still be required because we never write the code perfectly the first time.
Mark Woyna suggested we should look at the auto industry where every year manufacturers update their cars with many small changes only some of which are end user requirements. Sometimes they change a component to improve lifespan or reduce cost.
This reporter suggests that refactoring isn’t even something we should be talking about with management. It should just be a little part of our daily work ethic. First thing in the morning we do a rename or extract method just as a personal warm-up before moving onto other work.
Rate this Article
- Editor Review
- Chief Editor Action
Submit
Submit
Hello stranger!
You need to Register an InfoQ account or Login or login to post comments. But there's so much more behind being registered.Get the most out of the InfoQ experience.
Tell us what you think
Community comments
I've tried that 4 years ago.
by
Sake .
Posted
Re: I've tried that 4 years ago.
by
Sake .
Posted
Re: I've tried that 4 years ago.
by
Harry Simons
Posted
Re: I've tried that 4 years ago.
by
Alexandre Poitras
Posted
Re: I've tried that 4 years ago.
by
Julien Bérubé
Posted
Re: I've tried that 4 years ago.
by
Matti Hjelm
Posted
Re: I've tried that 4 years ago.
by
Peter Bell
Posted
Refactoring is a normal part of writing code
by
Hibri Marzook
Posted
Re: Refactoring is a normal part of writing code
by
Sake .
Posted
Re: Refactoring is a normal part of writing code
by
Hibri Marzook
Posted
Re: Refactoring is a normal part of writing code
by
C Curl
Posted
Re: Refactoring is a normal part of writing code
by
Jason Gorman
Posted
Which "Refactoring"
by
Adam Sroka
Posted
Re: Which
by
Peter Bell
Posted
Forget about when requirements change...
by
bruce b
Posted
I've tried that 4 years ago.
by
Sake .
I used these algebraic transformation to illustrate how putting things in "well factor form" can hugely result in simplification.
[1] ⇾ (3 ⋅ 8) + (7 ⋅ 8) + (7 ⋅ 2) + (3 ⋅ 2)
[2] ⇾ ( (8 + 2) ⋅ 3 ) + ( 7 ⋅ (2 + 8) )
[3] ⇾ (3 + 7) ⋅ (8 + 2)
[4] ⇾ 10 ⋅ 10
[5] ⇾ 100
With analytic eyes, the problem can be solved with much less effort than brute force calculation. Invest some time & effort moving things around forming into comprehensible concept can result in productivity and morale boost. I still believe it's worth doing if you have analytic and empathic boss that want to cooperatively work with you as a team.
I did not work in my case though. :)
[1] ⇾ (3 ⋅ 8) + (7 ⋅ 8) + (7 ⋅ 2) + (3 ⋅ 2)
[2] ⇾ ( (8 + 2) ⋅ 3 ) + ( 7 ⋅ (2 + 8) )
[3] ⇾ (3 + 7) ⋅ (8 + 2)
[4] ⇾ 10 ⋅ 10
[5] ⇾ 100
With analytic eyes, the problem can be solved with much less effort than brute force calculation. Invest some time & effort moving things around forming into comprehensible concept can result in productivity and morale boost. I still believe it's worth doing if you have analytic and empathic boss that want to cooperatively work with you as a team.
I did not work in my case though. :)
Re: I've tried that 4 years ago.
by
Harry Simons
When the mgt is too dumb to consider quality, even such clever illustrations would be no good. (Personally, I liked your style very much, and will try it also... but I know it won't work before a bunch of dumb MBA, Excel-proficient bosses.)
Re: I've tried that 4 years ago.
by
Alexandre Poitras
Exactly if your boss is not hands on, you're in deep troubles anyway.
Refactoring is a normal part of writing code
by
Hibri Marzook
Do you have to explain and justify to management why you need to write for loops ?
Refactoring is the same, its something you have to do all the time, while writing code.
Asking management for permission is lame.
Refactoring is the same, its something you have to do all the time, while writing code.
Asking management for permission is lame.
Re: Refactoring is a normal part of writing code
by
Sake .
A sizable refactoring activity require slot in time and budget. It's always better for a team leader to be aware of the cost and benefit it target for.
Refactoring often result in change in system design, for which any person responsible for the project should aware of.
Refactoring often result in change in system design, for which any person responsible for the project should aware of.
Re: Refactoring is a normal part of writing code
by
Hibri Marzook
I've had success with small, incremental refactoring activities done continuously. It's a better practice to make smaller incremental, reversible changes to a system's design, unless the system is in such a bad state.
Refactoring is more meaningful when done in the context of normal work. Get rid of the code smells in the area that is being currently worked on. Make it easier to implement the current feature.
Would a specific refactoring slot fix all the problems in your system ?
Why waste time refactoring something, when it might be made redundant by another feature down the line ?
Refactoring is more meaningful when done in the context of normal work. Get rid of the code smells in the area that is being currently worked on. Make it easier to implement the current feature.
Would a specific refactoring slot fix all the problems in your system ?
Why waste time refactoring something, when it might be made redundant by another feature down the line ?
Re: Refactoring is a normal part of writing code
by
C Curl
I agree.
I stopped explaining why we're doing refactoring to clueless managers a long time ago. If they get it, they get it, if not you're waisting your time, and will probably just antagonize them, which is no help to anyone. You may also possibly be accused of being a primadonna. You'll have to deal with all their management insecurities and huffing and puffing, while trying to explain calmly and rationally the purpose of moving tiny methods around in the comfort of your IDE.
Refactoring is a basic technique which everyone should master. It ought to be done continuously and best in small increments. Only if it affects public APIs, or a component that affects people outside your circle of trust, may it warrant a separate timeslot in The Plan. If you're doing agile, throw it into the product queue, and if such items never get prioritized, then something is wrong with your Product Owners, so go ahead anyway and make the changes that maximize the value you get while minimizing discomfort to others, in the time you have available. Ultimately, if your team delivers, any manager is not going to care that you've done a ton of refactoring. If they are smart, they will probably take it to their benefit and highlight it as a "major improvement" in the delivery to their own seniors.
I stopped explaining why we're doing refactoring to clueless managers a long time ago. If they get it, they get it, if not you're waisting your time, and will probably just antagonize them, which is no help to anyone. You may also possibly be accused of being a primadonna. You'll have to deal with all their management insecurities and huffing and puffing, while trying to explain calmly and rationally the purpose of moving tiny methods around in the comfort of your IDE.
Refactoring is a basic technique which everyone should master. It ought to be done continuously and best in small increments. Only if it affects public APIs, or a component that affects people outside your circle of trust, may it warrant a separate timeslot in The Plan. If you're doing agile, throw it into the product queue, and if such items never get prioritized, then something is wrong with your Product Owners, so go ahead anyway and make the changes that maximize the value you get while minimizing discomfort to others, in the time you have available. Ultimately, if your team delivers, any manager is not going to care that you've done a ton of refactoring. If they are smart, they will probably take it to their benefit and highlight it as a "major improvement" in the delivery to their own seniors.
Which "Refactoring"
by
Adam Sroka
I think it is important to make a distinction between the small continuous refactoring we do as part of TDD and the way that the majority of the community at large use the term -- medium to large scale system restructuring and redesign (Refactoring may or may not be one of the techniques involved.) I agree in principle that the former is part of "how we make the sausage" and not something to discuss with management. The latter, however, can have a significant impact on promises that we have made. We must discuss it with everyone involved.
It's also worth considering that if we do a lot of the former we can do almost none of the latter.
It's also worth considering that if we do a lot of the former we can do almost none of the latter.
Re: Refactoring is a normal part of writing code
by
Jason Gorman
Hibri's right (. The problems start when folk talk about "refactoring" phases or "refactoring tasks" in front of people who will simply never get the need for it. Project mgrs are often not rational in their motivations. If you tell them the cars costs $10,000 with wheels, they'll ask you how much it will cost without wheels. If you need time to do more ongoing refactoring on your legacy code, build it into the overall cost and do not offer it as an optional extra. Indeed, don#t mention it to mgrs at all.
Re: I've tried that 4 years ago.
by
Julien Bérubé
Hi,
I was in the same kind of situation as yours a while ago. I read this article, which changed my perception of the problem at hand.
It didn't solved the problem, yet it helped me to understand how I could have a better attitude towards it.
I was in the same kind of situation as yours a while ago. I read this article, which changed my perception of the problem at hand.
It didn't solved the problem, yet it helped me to understand how I could have a better attitude towards it.
Re: I've tried that 4 years ago.
by
Matti Hjelm
I just show them how the most effective way of programming is done by programmers every day: copy-and-paste. Everyone understands that its fast... in the short term. I then explain that after 50 more copy-and-paste sessions the code will be hard to change, because you have to change at 50 places. Or maybe only in 25 if its not the same change everywhere. They quickly understands the implications, and when I tell them its the normal way of programming for 90% of all programmers they become really frightened. I tell them also that the copy-paste rate increases with higher pressure from management to meet impossible deadlines
Re: Which
by
Peter Bell
I think this is an important distinction to make. Incremental refactoring should not be discussed - it's just part of the job. I also agree that large changes need to be talked about.
A distinction Eric Evans makes is between incremental development (adding new features a few at a time) and iterative development (being willing to make substantial changes to the structure of your code base as domain understanding grows). Many agile teams are incremental. Few have the management support to be truly iterative.
A distinction Eric Evans makes is between incremental development (adding new features a few at a time) and iterative development (being willing to make substantial changes to the structure of your code base as domain understanding grows). Many agile teams are incremental. Few have the management support to be truly iterative.
Re: I've tried that 4 years ago.
by
Peter Bell
Nice was of explaining things. I'll have to try that and see how it goes down!
Forget about when requirements change...
by
bruce b
...when requirements are well known in advance, we often pretend YAGNI is true to simplify the early sprints, knowing full well, a re-factoring will be necessary when the YAGNI bit is toggled.
