You’re banging your head against the desk. You need to access some data member and you have to jump through ten hoops just to get to it. You finally do and then realize you can’t make the changes you need to without making thirteen more calls to get the other data you need.

Burn it all to the ground.

In a previous post I talked about how to get the OK to refactor your code. Now I want to convince you that you should.

About twice a month, I’ll get someone coming to me to ask for career advice. I’m starting to collect the more common questions and my thoughts on them. I’m putting these together as a series of blog posts under the tag CareerPlusPlus.

What’s the Problem?

When I see this, it usually falls into one of two categories:

• The architecture doesn’t fit the needs of the program or project
• The engineer doesn’t understand the architecture

For the second – it’s okay to not be familiar with every single architectural design. If you have a degree in computer science, there is no way you’ve been exposed to every approach out there in industry. If, like me, you’re not a computer science grad then how will you have seen every pattern until you encounter them? I suppose you could go read a book about design patterns. Personally, I haven’t.

For example, I was working on a project using the Unreal engine. I had an engineer on this project who was extremely senior – a decade more experience than myself. They could write embedded code that would run circles around anything I came up with. They also wrote some code in this Unreal project that was a complete train wreck. We sat down and discussed the design approach of Unreal, including the use and purposes of blueprints, how sessions are handled, etc. Once they learned to stop fighting the architecture because it wasn’t build the way they wanted, their productivity skyrocketed.

If you’re in this camp, my suggestion is to stop reading this post, and go learn about the design intent of that system. If it’s a well established product there are probably good resources out there to explain it. I’d suggest trying to go in with an open mind and not see the faults with what you want from it.

Let’s assume for the rest of this post that you’re in the other category – you do understand the system design and it doesn’t meet the needs of your project.

Don’t Anchor Yourself

One of the most common roadblocks I’ve found to changing architecture to fit your needs is that people see something that exists and they can’t help but try to force all of their ideas to fit into that existing approach. It’s not unlike the anchoring effect in this comic:

In practice, I think people often feel that the best way is to always try to make non-disruptive changes. The reasons vary – sometimes they think it’ll be easier to get the reviews through. Sometimes they’re uncertain a big change is really worth the effort. Sometimes they think it’ll be simpler. And you know what? Sometimes that’s right!

But usually when you find yourself banging your head it’s not the case. When the changes can be made simply, then you would do it and not need to read this.

My biggest advice in this post is this: Don’t constrain yourself to what exists now. Break some eggs.

What to do instead

Try as much as possible to set aside what you already know about how the system works. Ask yourself this: “In a perfect situation, how would it work? What would the interfaces or approaches be? If someone had written the original code exactly as I need it right now, what would that look like?”

I can’t give a one size fits all answer, but I can suggest that you try to diagram out what a perfect world would look like. Then ask yourself, “what design patterns fit my needs?”

What’s a design pattern? Oh, that’s a long question to answer. This wiki article looks unimpressive but has a decent covering of some of them from an architecture perspective.

Anyways, draw out what it would look like. Maybe that’s a block diagram. Maybe it includes some API rough sketches.

Then show it to someone else who is interested, but uninvolved. Get a second opinion of why you need something different. Usually they can help you either identify some rough spots or come up with alternative approaches.

Burn it Down!

The biggest advice I can give you is: Do not be afraid to burn the whole code base to the ground. It’s counter to what I’ve heard throughout my career. However my biggest advances in my career have usually occurred because I was willing to ruthlessly cull anything that wasn’t of value.

Just because someone (maybe even yourself) spent time working on something does not mean it needs to be preserved. If it doesn’t meet the company’s needs, cut it dispassionately.

Yes, people may complain. Yes, you may get push back.

I have never once regretted making a major breaking change. I have regretted code that I allowed to linger for months (or years) beyond when it should have been cut.