OO, Patterns, UML and Refactoring

[Shantha Dodmane]

I might have followed wrong designing. But it is resulting in right functionality. There is a need for refactoring still?

[Junilu Lacar]

Probably. Correct functionality is not all there is to software development. Software should be maintainable and flexible. It should be clear and concise. The majority of the effort spent on software is not in its initial development but on its enhancement and maintenance. Anything that impedes the ability of developers to enhance or maintain software is a candidate for refactoring.

And remember: refactoring should be done continuously and incrementally. Ideally, you refactor at least once for every 10 lines of code that you write.

[T. Sharma]

An industrial software keeps changing due to changing/new requirements and bug fixes. A working software with not so good design will not be maintainable very soon in such a context. The Cost of Change will keep increasing for such a software if it is not refactored regularly.

[Shantha Dodmane]

Thank you Junilu Lacar and T. Sharma.

Here is another question-

Say M Mr. X is a very good design follower.
Now he joins a new project which is there since a long time. He sees that the project doesn't follow any good design practices.
He estimates that refactoring of that entire project is going take very long time(say 3 months!!!)
No management will agree for such proposal unless there are some functionality issues.
What should be Mr. X's next step?

[Stephan van Hulst]

Mr. X shouldn't propose to refactor everything in one huge step. When Mr. X needs to maintain a specific part of the project or improve upon it, he can identify parts of the project that can be modularized, and propose to do that. Modules can be refactored without a strong impact on the rest of the project.

Management will be much more likely to OK small refactors that will take a few hours to a day or two. Using this approach, over the course of time you can improve code quality while at the same time adding features or hunting down bugs.

Note that many people confuse "bad design" with "not the way they would have designed something themselves". When you join a project that has been around for a long time, often choices were made in circumstances that you do not know of. Old projects naturally become messy. This is a direct result of developers not knowing exactly what they needed at the time they started building new features. A solution is to "throw it all away and start over", but this should be done by the team that designed the old project, not newcomers to the project.

These two articles by Martin Fowler might be good reading:

http://martinfowler.com/bliki/MonolithFirst.html
http://martinfowler.com/bliki/SacrificialArchitecture.html

[T. Sharma]

Stephan has already answered the question correctly. Still, here are my thoughts:

In the financial domain, if one has a large loan (say, a home loan), it is unlikely that the person could repay the whole loan in one instance; however, it is definitely easier for the person to repay the loan by paying EMIs (Equated Monthly Installments). In the same way, it is unlikely for a project team to repay huge technical debt all at once; however, repayment in the form of small installments is quite feasible and practical where a small portion of effort in each iteration is dedicated to refactoring.

[Junilu Lacar]

Stephan van Hulst wrote:Management will be much more likely to OK small refactors that will take a few hours to a day or two.

I agree with the other points about avoiding large refactorings but this thing about management being "OK with it" points to something that's wrong in the development culture. Developers should not have to ask permission from their managers to do the right thing. Developers should be honest in their estimates and transparent about what they are doing and they should be willing to make compromises to a certain extent. I think it's our responsibility as developers to educate managers about technical debt and its impact on the long-term viability of software. Help them understand that neglecting to make incremental refactoring will cost more in the long run. Tell them you NEED to spend some time paying down technical debt, don't ask permission to do it.

Here's a synopsis of how it usually goes otherwise:
1. Developer sees a need to refactor
2. Developer asks for permission
3. Manager says "No, we don't have time."
4. Developer gives estimates based on "ideal" situation
5. Developer is hampered by poor design / bad code that hasn't been refactored
6. Developer takes more time than he/she estimated in #4
7. Manager is not happy, puts more pressure on Developer
8. Developer makes more poor design/code decisions and choices
9. Developer finishes late and with low confidence in his/her work
10. The vicious cycle continues...

We developers need to take responsibility and reverse this vicious cycle. Make refactoring an integral part of the work that you do. Don't ask permission to do it.