Starting a Major Refactoring By Refactoring Myself

A few months ago, I started with Clear Measure and joined a project as the team lead. The project had been started about 2 years earlier, so it was not the elusive greenfield project. This project had changed hands a few times and, for a while, there wasn't anyone who was actively grooming it. The previous developer was alone for 6 months trying just to keep the project alive.

From a business point of view, this project is great. We've got 5 developers on the team, the client trusts us and actively works with us in the relationship. Most of the time, I truly feel like a partner with the client.

We have decent unit and integration test coverage. We don't have any working functional tests, though. We've got one step local builds with psake and a CI server that works. We don't have automated deployments, but the deployments are almost a one click story.

The project is adequately staffed. I've got the support from Clear Measure leadership and my colleagues.

The code, on the other hand, is not so pretty. There were some assumptions made a couple of years ago that just haven't panned out. What started out as onion architecture has turned into a mess of dependencies. There are currently 58 projects in an application that I think should have less than 10. Any boundaries found are mere suggestions of their former selves. There's a mix of domain language and generic terms. There's even a method called "ApplicationCreatedSaver". Business rules and domain logic are sprinkled around a very anemic domain model.

There's a plethora of things I can call out but suffice it to say, this is not the type of application I want to support; so, we are changing that.

I hold no ill will for the previous developers of my applications. There were a lot of business happenings going on and it is never fair to judge someone's code when you weren't in that situation at that particular time. I've made some horrible concessions in projects before when I felt I had no other choice. However, that doesn't mean I have to be content with the current status. I have the power and the ability to make these changes. I refuse to let 3, 6, or 9 months go by and still only gripe about the problems.

It'll take a while to get every part of the app into a state that I can be proud of, but I can do what it takes now to make sure every line I write no longer contributes to the suckage (technical term).

I'm excited about starting this refactor. I look forward to having a fat domain model and a well designed aggregate. I want someone to be able to open the application and reason about the business logic. My team and I have a ways to go. It won't happen over night or over a quarter. But we are going to continue to strive towards something to be proud of.

All of this sounds great. Yes, it's easy for me to get myself and my team fired up about the code base. We can talk about all of the things that are wrong with it and confidently say every thing that we want to do... But doing it is a whole different thing.

Here's the what happened: I would start working down one path and then get sucked into rabbit hole after rabbit hole after rabbit hole. Next thing I know, I've edited 24 files, deleted 13, created 7 and once I finally get it to compile, none of the tests pass. Then it goes on a branch and patiently waits for me to muster up the patience to try it again. In reality, it's never heard from again.

This happened several times.

It took a while to be honest with myself and admit I was overwhelmed. I knew I needed help, but I'm the team lead... I'm supposed to have all of the answers, right? My pride was in my way. I kept thinking that this was a challenge that I could (or should) solve myself.

I was afraid of asking for help. I was afraid that I would be exposed as a fraud. I suppose I suffer from the impostor syndrome. I was terrified that my peers would look down and judge me for being unable to do something they could do in their sleep.

After a couple of months, nothing was better. Out of all of the talks with my team, the only thing that ever surfaced was a few name changes and a lot of pessimism. I realized it was my pride and insecurity was holding us from our potential. So, I did the hardest possible thing I could do. I became vulnerable and said I needed help and I couldn't do this on my own. I explained to my co-workers that I was overwhelmed and I needed advice and perspective. I needed someone to help me set some priorities.

Can you guess what happened? No, they didn't laugh at me. They didn't judge me and they didn't call me a fraud. Instead, they offered to help.

I went out to lunch with Andrew Siemer, our Chief Architect, and we discussed some ways to establish some focus and visibility into the refactor. Justin Mason, a Principal Architect, gave me some great advice for engaging with the client and setting expectations around the refactoring. Gabriel Shenker, also a Principal Architect, spent some time giving some technical pointers and showing me some patterns he used to control complexity in a similar situation. James Kovacs gave more insight from his past experiences. Kyle Baley gave many suggestions and offered to work with me when I needed more eyes and a sounding board.

This was pretty much the opposite of what I expected. I feel stupid for being so worried about what would happened when I called out for help. I try to leave my pride at the door and be as humble as possible, but I still find that my ego grips desperately to corners of my character and can prevent me from achieving success.

As developers, we are called upon to be experts in our field and know all of the answers. It's nice to be reminded that it's OK to not have all of the answers. I needed to remember that we all struggle with it and those that ultimately find great success are willing to admit when they don't know what to do and ask for help.