Refactoring Legacy Assets With Agile

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.

Like this post? Subscribe to RSS feed or get blog updates via email.

add to Digg it : post to facebook: Stumble It! : :

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: