Friday, March 23, 2012

You've got an ugly baby: How to "sell" refactoring

Look, nobody likes to be told that they have an ugly baby.

If you are new to an existing corporate project, you are fairly likely to find a code base that could use some improvement.

If you happen to be fortunate enough to have the project manager tell you that they have amassed significant technical debt and need to work on reducing it, then you don't need to read the rest of this post. Attend my 360Flex presentation or check back here for my slide deck in a couple of weeks to learn how to refactor responsibly.

But for the rest of us, telling the client that the code base is not usable and needs to be massively cleaned up, is like telling a parent that they have an ugly baby. They won't hear you.

I've tried using the reduces maintenance costs / increases bug fixing time arguments too. And frankly, when faced with a looming deadline, some clients have outright said "I don't care about maintenance."

Now I disagree. If you are working on a marketing campaign that has an expected 3-4 week life.... fine. Get 'er done and life is good. But when you are working on a project that has an expected life of years, or even in this case a decade or more... then it is insanely short sighted to not care about maintenance.

Clearly, timing is important... Don't propose an immediate refactoring initiative a month before a major deadline. Do however propose it for immediately after the deadline.  From my experience, if you are not "agile", then your deadline is a major milestone... maybe even a release. This could mean that there will be a period of QA testing, acceptance testing, approvals, etc. For us, this was a time that the developers were supposed to work on documentation, as the code was "frozen". (I disagree with both of these statements).

This is the perfect time to refactor. If you need to "document" your code, then you need to refactor. Well written code is self documented. I'd also argue that writing unit tests are the best form of documentation that you can have.

But I digress, this post isn't intended to be about refactoring, it is intended to be how to talk about refactoring so that business will listen.

If you find that concepts like refactoring, technical debt, or maintainability are not working for you in terms of buisness buy-in, we've had some success with some others.

  • "Future BIG IDEA" enablement

For us, it was the "new backend framework enablement initiative". This "sold" incredibly well. We were granted a 5 week sprint for enablement (refactoring)

It was during this "enablement" sprint, that this next idea really proved itself.

  • Training / ownership

In my case, I'm a consultant. I have two main responsibilities: Help the team with some new code, and train the (soon to be maintenance) team. During the refactoring iteration, the team learned more about their code then I could ever deliver myself. No matter how many presentations, diagrams, code reviews, etc. I gave, nothing would compare to getting the team to improve their own (team's) code.

As a developer, refactoring is wonderful!

  1. The requirements are perfectly clear (do exactly what it is already doing). 
  2. The end state is self defined (I can stop refactoring at any time that I've made any level of improvement, assuming that nothing has changed).
  3. Identifying what  to change is clearly describable to any level developer ( code smells )  
Actually, the results of this sprint were amazing! And I'm obviously not talking about functionality, as true to our intent -- nothing changed. But now, the transformation in the team was astonishing.
  • Junior developers had dozens of light bulbs / ah - ha moments regarding their own and future coding standards. 
  • Everyone felt responsibility and ownership in the code base, which previously was more a lay blame / obligation. (see responsibility model )
  • We all had fun. It was unanimously voted the" best time" in all of the project's duration
  • The team of developers had transformed into the "team" (performing, in the Tuckman's_stages_of_group_development)

So if you need it... it is no longer "we need to rewrite this code". 

Let, "we need to increase team ownership by enabling [The next big thing], before we start the next phase." -- be your next refactoring battle cry.


Wednesday, March 14, 2012

Refactoring and Respecting the Team

So I'm working on my 360Flex presentation and I realized that there was a very important lesson that I've learned about refactoring and team respect that is unlikely to make it into the actual presentation.

So if you are not going to read the whole backstory coming up... here is the quote from the retrospective prime directive that illustrates my point perfectly:
“Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.”

And now for the back story.

A couple of years ago, I was brought onto a team as a senior flex developer. One of my first tasks was to mentor the team in best practices. The novice flex team had been writing flex code on their application for about 6 months and, as might be expected, there were lots of areas for improvements.

But there was one section of code that I came across, which absolutely blew me away. I couldn't believe how bad this code was.

There was a view component that created an alert. Within the alert callback, within the same view component was a switch statement. This switch statement evaluated the width(!) of the alert to determine the business logic of what should happen next.

It looked something like this:
    case 341:
       //do approval workflow
    case 354:
       //do normal workflow
    case 362:
        //do cancel workflow
As I said... I was completely flabbergasted. I couldn't imagine how anyone, novice or not, with any coding experience, in any language, could think that this was a good idea. Didn't they realize that width's are arbitrary and volatile?! And this was critical business logic, nevermind that it was contained in the view, but business logic based on width!

Clearly this still agitates me.

So I created my best-practices presentation, with this code as my shining example of bad code and the need to refactor. I was feeling particularly proud of myself and how much value I would be adding to the team, as if to say -- if this is the code that they were writing, I could bring them up many many levels.

So I showcased this example, hand waving madly why this was so bad. Nearly immediately, the technical architect / my mentor / team lead, stood up and proclaimed that this was his code.  My first thought was "clearly this isn't his code, this is the code of a total..... oh *$#^&, someone in *this* room wrote this code that I'm totally tearing apart."

So after lots of backpedaling, apologizing, focusing on better ways of organizing the code in general, and blaming the tech architect for such bad code <wink>, the presentation was favorably received.

But, boy, was that a slap in the face for me... and certainly a lesson that I'm not going to forget nor repeat.

It wasn't until just a couple of weeks ago that I found the above retrospective prime directive, but it perfectly sums up the philosophy that was thrust upon me in that moment.

That moment that completely altered my course.
That moment of supporting the *team* first.
That moment of respect.