• 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

 
Ranch Hand
Posts: 462
Scala jQuery Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
how do people get buy-in from management to clean up the horrors you find in a legacy code base? Bad structure, lack of useful tests, crazy config set-up, etc
 
Bartender
Posts: 3225
34
IntelliJ IDE Oracle Spring Chrome Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I think it would come by experience. We would have to be ready with the facts - advantages of having tests, disadvantages of not having tests, effort in maintaining a systems with/without tests, effort required to increase the test coverage.
 
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
My response here: https://coderanch.com/t/643467/patterns/engineering-Legacy-Software-Lot-resistance
 
Junilu Lacar
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
There are environments where you have to be careful about suggesting improvements in the design and architecture of the application. In a way, the scene from Schindler's List where the prisoner with an engineering background gets shot for pointing out problems with a construction project is very real in some environments. They obviously are not summarily executed but sometimes it can feel as though that's what essentially happens to anyone who tries to get people face up to the pain of having to reengineer poorly-made applications.

Again, it's all about framing the argument in a way that's relevant to the stakeholder. In Bartender Winston Gutkowski's words, you have to present a very visceral opinion. Most stakeholders don't know or care about following design principles or having readable and maintainable code or what not. They care about getting value out of the software, of being able to get things done efficiently, of creating more opportunities for their business. If you can find ways to show how these concerns will be impacted negatively by not investing in reengineering or refactoring, then you have a better chance of getting buy in from them. Otherwise, you're just basically setting yourself up to be shot down (figuratively, of course).
 
Sheriff
Posts: 67746
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Obligatory Dilbert:

 
Author
Posts: 18
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Rule #1 is: Don't badmouth the existing code. Just complaining about the poor quality of the code is not very helpful and it can be dangerous. I vividly remember saying to another developer, "this code appears to have been written by someone who doesn't understand the basic concepts of Java concurrency", only to find out later that it was written by the person I was talking to. *cringe*

When trying to convince management/business side to allocate time for refactoring, you have to frame the discussion in terms they understand. As developers, the main reason we want to refactor is to make the code easier to work with, reason about and extend. In other words, to make our own jobs more enjoyable. Unfortunately, for the business as a whole, "happier developers" is not a primary goal. It doesn't directly generate value for the business. (Of course, having happier, more motivated employees has an indirect effect on the health and profitability of the company, but there's a long chain of cause and effect in between.)

So try to come up with a way to express the benefits of refactoring in terms that management can understand. e.g. "Without refactoring, feature X will take N weeks to implement. If we spend a week on refactoring beforehand, feature X will take 2*N/3 weeks to implement, and future development will also be faster." Or "The web app currently has hundreds of XSS vulnerabilities, putting our users at risk. If we don't refactor and we instead try to fix them one by one, it'll take a year to fix them all, and we might accidentally miss some."
 
Junilu Lacar
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

Chris Birchall wrote:Rule #1 is: Don't badmouth the existing code. Just complaining about the poor quality of the code is not very helpful and it can be dangerous. I vividly remember saying to another developer, "this code appears to have been written by someone who doesn't understand the basic concepts of Java concurrency", only to find out later that it was written by the person I was talking to. *cringe*


This is a tough one to follow and I have been guilty of breaking this rule many times in the past. But I agree. However, you can't not be critical about poorly written code. You just can't and shouldn't disparage the person who wrote it, whether or not your opinion about that person is justified is irrelevant.

I think the key is not making it about the person who wrote the code but about the attributes of the code that make it difficult to work with. Keep it about the code, not the person.

Prior to doing a code review and especially when people with whom I have never done code reviews are involved, I always make it a point to state that any criticisms should be addressed to what and how the issue will hinder our progress, not about the intelligence or lack thereof of the code's author. Admittedly, I sometimes break my own rule but that's usually when things get particularly frustrating and only when we know for sure that the guilty party is not in our midst. Hey, we're only human.
 
I'm not dead! I feel happy! I'd like to go for a walk! I'll even read a tiny ad:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic