Explaining Refactoring to Management

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. :)

Typo.

"It did not work in my case though"

:)

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.)

Exactly if your boss is not hands on, you're in deep troubles anyway.

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.

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.

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 ?

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 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.

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.

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 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

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.

Nice was of explaining things. I'll have to try that and see how it goes down!

...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.