• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Re-engineering Legacy Software: Lot of resistance for cleaning up/refactoring...

 
Ranch Hand
Posts: 69
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Chris,
There is one some what non-technical hurdle I have encountered again and again...
For whatever reason - cleaning up/refactoring code, adding tests where there are none - is kind of frowned upon...
One - it is an uphill task - especially for software which is already in production - there is so much of cruft left behind -
people are afraid of touching it in case something breaks - and then slowly the work starts becoming just a job we need to do
only because we get paid... And the deadlines always there.. ;-)
The passion for clear code (easily maintainable code - less cost - nothing fancy there) is somehow not well understood by
far too many people - and these people matter :-(

I think there is a very big "mind set" side to all the legacy business - and it is tough to accommodate - however good one is
at the techniques...
 
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
See this thread: https://coderanch.com/t/643484/patterns/refactor-ruthlessly-relentlessly

Stakeholders understand risks and costs. It's up to the developers to frame the conversation about refactoring around risks and costs of not investing in that activity. If the stakeholders think that the risks and costs of not doing it is acceptable, then fine, but we would be remiss in our duties as developers if we didn't help them get an idea of the potential consequences of ignoring the need to improve the quality of the code and design.

My spiel would go something like this:

"We've spent a lot of time trying to add these new features but the current design is preventing us from testing properly. Without tests for the new features, we run the risk of breaking things that work now or having bugs in the new things we put in. We want to spend some time refactoring first, so we can add the new features cleanly and test properly. If we do this, we can continue to add more new features in the future much more easily as well. In the long run, you'll get more out of us than you would if we kept having to bang our heads against this inscrutable and hard-to-maintain code."

And then I'd pull out some timesheets to show exactly how much time we've spent so far just trying to wrangle the code into submission. To highlight the costs, I would add up all those hours and assign a $ figure to it that they can plainly see.
 
Author
Posts: 18
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Atul, I'm glad to see you've noticed that the human side is often the most important thing to tackle when dealing with legacy code. This is a problem that most developers are reticent to discuss. Without consensus in the development team about how we should be writing and maintaining code, the legacy code will never be fixed.

There's no easy solution to this problem, and fixing it will take a lot of time and patience. Try to think of yourself as a 'code quality evangelist', and make it your mission to get other developers interested in code quality and motivated to improve it.

Often the problem stems from two causes: a lack of communication and a lack of motivation.

Lack of communication: If developers are talking to each other regularly about the code, they are more likely to treat the code as something that they built together as a team, and something to take pride in. You can try a few things to get developers talking more, including code reviews, pair programming, daily stand-up meetings, dev lunches (where you get together and play with a new technology for an hour while eating lunch) and hackathons.

Lack of motivation: If you're faced with a huge legacy codebase, it's easy to think that it's impossible to improve it. There's just so much code to be fixed! If you can find a way to split this huge, unsurmountable problem into small chunks, developers will be more motivated to start fixing things. They can fix one small thing at a time, and it's easy for them to see that they are making progress. Tools like FindBugs and SonarQube can help you to find 'hotspots' of poor quality in the codebase, making it easier to decide where to focus your refactoring efforts.
 
atul khot
Ranch Hand
Posts: 69
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Chris,
Very true! Will try the things you suggested...
To add, I think it is also something to do with trust/confidence building...
The one lesson I learnt pretty early was never ever propose refactoring when you have joined a new team!
Or propose very small once... (Rename method, extract method etc...)
As these are simple - and directly supported by Eclipse (and other tools) - people kind of feel it is okay - and at least
listen to
what you are saying
I then learnt to undertake the most complex piece (algorithm/design/jpa wise) - and do it all test first - While not disturbing the existing code
as much as possible (you don't want to break anything already working ;-).
Soon the difference is all there for the team to see - the new code is all very readable, predictable - far easier to change, and they
can see the confidence with which you build more and more on the existing stability of the new, refactored module/code/sub-system
OTOH they are already witness to the morass they are used to - and how hard it is to predict anything...
And then it all starts making sense - takes some practice however - the stake holders then start buying it ;-)

 
What? What, what, what? What what tiny ad:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic