DevOps Zone is brought to you in partnership with:

Cody Powell (@codypo) is the cofounder and CTO of Famigo. Famigo's main offering is a cross-platform recommendation engine for mobile content, helping families find things like the best android apps, best iPad apps, and free apps. He's a graduate of Trinity University, an ardent supporter of the Texas Rangers, and he makes a mean mojito. Cody is a DZone MVB and is not an employee of DZone and has posted 25 posts at DZone. You can read more from them at their website. View Full User Profile

It's Not Refactoring, It's Untangling

03.19.2013
| 4142 views |
  • submit to reddit

Recently, I was catching up with a former colleague. He mentioned a service that I wrote years ago, and how it has since become known as the Career Killer. Basically everyone who touched the Career Killer ended up leaving the company. If the company wanted to have > 0 developers, the only solution at this point was to take a few months and refactor this service completely.

I have two things to say about this.  First, that code was at 85% unit test coverage when I left so don't go blaming me.  Second, this huge refactoring?  It's not going to work.

Every codebase has at least one component that is widely hated and feared.  It does too much, it has too many states, too many other entities call it.  When it comes time to pay down technical debt, you should definitely focus on this component.  However, if you have an incomplete understanding of this component and you stop everything to completely rewrite it, your odds of success are low.  That component, as scary and complex as it appears, is actually way more scary and complex than you think. 

How do you think that component got into this unfortunate shape?  Is it because the company hired a nincompoop and let him run wild in the codebase for years?  Or is it because the component was originally a sound abstraction, but its scope of responsibilities had grown over the years due to changing requirements?  (For the sake of my ego, I'm hoping the Career Killer is the latter.)  In all likelihood, this component arrived at its current, scary state via smart people with good intentions.  You know what you are right now?  Smart people with good intentions.  If you proceed with a big refactor, you'll trade one form of technical debt for another.

In order to truly pay this debt down, you need to untangle the complexity around the problem.  You need to spend time looking at all the clients calling this component.  You need to spend time talking with your colleagues, learning more about the component's history and how it's used.  You need to make a few simplifying changes around the periphery of the component and see what works.  Each week, you spend a little more time and untangle the problem just a little bit more.  Given a long enough timeframe, you'll eventually untangle all of the complexity and brought a teeny bit of order to the universe.

Practically speaking, what do you do here?  Rather than 3 full months on a complete refactor, spend 25% of your time over the next year.  It's the same time commitment either way, but with the 25% plan, you get time to analyze and plan.  You get time to untangle.

Published at DZone with permission of Cody Powell, 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.)

Comments

Lund Wolfe replied on Sun, 2013/03/24 - 7:23pm

I've been on the opposite side of that situation.  The last developer cited stress as the reason for leaving.  I was a previous maintenance developer of the Java client application that had all the mysterious business logic in stored procedures since the main original contractor was a database developer.  It was brittle and had reached its scalable size and performance limits.  Part of the problem may have been that the original three VB developers were told last minute to build it in Java instead due to a corporate policy shift.

In any case, the later maintenance developers either lacked the stored procedure scripting experience or the business requirements knowledge to reverse engineer the legacy app into a proper client server app.  There was also little or no money budgeted since the app was basically functional and there was little additional profit to be obtained from it.

The effort should have been made to find the knowledgeable users and rewrite the app and migrate the database to a new structure if needed.  Sometimes it's a huge job, and it shouldn't be attempted without sufficient resources (skills, time, money).

Comment viewing options

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