Explaining Refactoring to Management
- Share
-
- |
Read later
Reading List

A note to our readers: You asked so we have developed a set of features that allow you to reduce the noise: you can get email and web notifications for topics you are interested in. Learn more about our new features.
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
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
I've tried that 4 years ago.
by
Sake .
[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
Re: I've tried that 4 years ago.
by
Alexandre Poitras
Refactoring is a normal part of writing code
by
Hibri Marzook
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 .
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
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 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
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
Re: I've tried that 4 years ago.
by
Julien Bérubé
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
Re: Which
by
Peter Bell
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
Forget about when requirements change...
by
bruce b