Agile Zone is brought to you in partnership with:

Vijay Narayanan is a systematic reuse evangelist building reusable data services and business process automation components. He has worked on several software projects ranging from single user systems to large, distributed, multi-user platforms with several services. He is a technologist focusing on software reuse, agile development, and Service Oriented Architecture (SOA). Vijay is a DZone MVB and is not an employee of DZone and has posted 43 posts at DZone. You can read more from them at their website. View Full User Profile

Refactoring Legacy Assets With Agile

  • submit to reddit

Working with legacy assets can be difficult. You will start out with fear, uncertainty, and doubt (aka the FUD factor) and you will probably question if it is worth going through the trouble of touching old code. It might be tempting to just leave a legacy system alone and just write new code for what you need. Initial estimates for understanding and making code changes to legacy modules are likely to be gross underestimations. Good news – this won’t be the case forever. You will find that as you add regression tests and pay down technical debt in your legacy systems become the number one place you go for reusable assets. The inertia against making code changes will be high initially but over time this feeling will diminish. Your ability to refactor legacy code and analyze legacy processes improves over time.

You are doing right if…

  • Your refactoring tasks are prioritized with the rest of your tasks for the iteration (maybe your coach or tech lead can help you with this).
  • You identified the legacy asset changes, implemented them, and reviewed them iteratively. Getting the changes right with a legacy asset the first time isn’t realistic for most teams.
  • Is there a single place to find all reusable assets? Is it accessible by all team members? If you have a geographically distributed team can they get to this?
  • Do you have a plan for how this asset is going go be packaged, deployed, and consumed?
  • Everyone in the team is aware of the new reusable asset and they know how to use it
  • Every reusable legacy asset is either refactored fully or wrapped and consumed

Warning Signs
Here are some warning signs to watch out for while building reusable assets from legacy systems:

  • More time is spent documenting what is wrong with a legacy asset rather than coming up with the refactorings needed.
  • It takes weeks for you to identify what the legacy asset does or what it is coupled with (hint:  ask your team for help. You could be surprised how much undocumented knowledge is locked up!).
  • The refactoring tasks are completely irrelevant to what your team is working on for the iteration (hint: the refactoring is either a waste of your time or your team isn’t communicating).
  • The legacy asset changes are made without creating automated tests.
  • The newly crested reusable asset has no documentation. No one knows what it really does.
Published at DZone with permission of Vijay Narayanan, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Raja Nagendra replied on Thu, 2013/10/31 - 2:18am

Vijay, I complete agree to this simple tips provided.. however..

My definition of legacy is the code produced each hour and each day.. let us not forget that, we are professionals and we do produced bad code each day and each hour.. as we keep learning new things with time.. nothing wrong bettering it as we learn... 

Pl. think like one is writing the code which can act like you (Program which can replace you).. - Programming the Programer..Which means, you tend to automate most of your repeated talks.. so that one is seeing the next challenge.. 

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.