top of page
  • Writer's pictureSylvester

Pass the Torch or Start Fresh? How We Use Preexisting Client Code

It is incredibly common for clients to come to us with an amount of their product already written. Naturally, one of their first questions is always:

“Can we keep what we have, or do we need to start over?”

This is a reasonable question - why spend time and money starting from scratch if you don’t need to? We agree with that sentiment.

Why We Don’t Want to Rewrite What You’ve Started

We Can Move Faster

Already having initial work completed is a great way for us to hit the ground running. With many of the basics handled, we can jump right into developing your most valuable features.

We Don’t Have Your Team’s Historical Knowledge

We don’t necessarily know WHY certain parts of your code were written a particular way, but you probably want to keep it working the way it already is. Past choices impact the code we are working with now, and starting over would mean losing the intention behind those choices. We would require a deeper understanding of your initial work in order to start from scratch than we would picking up where you left off.

Features May Be Lost

As the former code is analyzed and dissected so that it may be reimagined and rewritten, it is possible for current features to be missed and forgotten entirely in the new implementation. While this may be a good way to cull features that no longer provide value, it is also possible for an infrequently-used high-importance feature to be discovered as missing at an inopportune time.

Qualifying an Existing Product

We have some solid arguments to stick with the code we have - but the case isn’t closed yet. In order to use the existing code, it needs to check some important boxes. Allow us to introduce the following analogy: We’re shopping for a home and we know that whatever we buy isn’t going to remain as-is - we have BIG plans that will require some intensive renovation work. The following factors will play a big role in whether or not a particular home is a good investment. We’re looking for the following qualifications:

It is Well-Documented

If you’re planning structural changes to a home, having the original blueprints goes a long way. Similarly, code that is well-documented provides us a much better starting point than “mystery code”. Knowing what elements are “load-bearing” and how they connect to one another facilitates a smoother development process. Lack of documentation isn’t a deal breaker, but it does introduce risk that should be recognized and mitigated.

It is Scalable

A cracked foundation is a compelling reason to walk away. If the home is already showing architectural weaknesses, how are we going to add that third floor bonus room? Any work we do perform on the home without first resolving its foundational issues will fall into disrepair long before it is due. If the current code is built in such a way that continuing to build on it will cause it to ultimately default, it isn’t sustainable and needs either major rework or to be torn down and rebuilt.

It is (Relatively) Bug Free

If you are touring a potential new home and discover a major termite infestation, we sincerely hope you wouldn’t buy it (we sure wouldn’t!). If it requires a single trip from the exterminator, then it’s manageable - but you don’t want to take up residence in a home that has already been claimed by insects. If your code is so full of bugs that we would need to repeatedly delay features for fixes, it’s likely best to just let the bugs have it and start fresh somewhere else.

It isn’t Riddled with Unnecessary Features

So the house you’re touring has an indoor pool. Cool! Except we don’t want an indoor pool. So we have it filled in, but now we aren’t sure what future problems may be caused by the ghosts of pools past. Not to mention that sunroom (which we also didn’t need) is full of poorly insulated windows, so we’re having to pay extra to cool it in the summer and warm it in the winter. The garden out back is lovely but it’s full of high maintenance plants - we could let them die off, but now we’re left with an unsightly mess. Too many unnecessary features in your project can lead to similar problems - if there are enough, it may be easiest in the long run to move on.

It’s Time for a Change - Now What?

Let’s say we’ve made the choice that the current code isn’t suitable for the long term. There’s a number of ways we can proceed from this point.

When You Don’t Need to Start Over - Refactor

Sometimes we are able to complete all of our renovations while we are living in the home. There may be some inconveniences - work that creates a lot of dust or temporary inaccessibility to specific rooms - but nothing that compares to needing to move out while you gut the house and rebuild it. This is akin to refactoring, or modernizing, code. Refactoring refers to making incremental structural changes over time, with the intent being to update the internal structure of your code but not necessarily its customer-facing functionality. This process works best on smaller codebases that haven’t yet become overly complex. As your product scales, you will find yourself refactoring what you write now in the future - it’s a process that provides value throughout the life of your product, not just at the start.

When You Do Need to Start Over - Buy Time

If you are a startup, your first goal is to get your MVP in front of early adopters so you can get feedback and raise your next round of funding. If your existing work is good enough to get you that far even though it won’t scale later, use it! That valuable feedback may help you in laying the plans for your rewrite. It’s possible that a full replacement may be ultimately required, but that doesn’t mean we have to totally scrap our current code and start from zero.

Make Like a Tree and Get that Old Code to “Leaf”

There is a rewrite method called the “strangler fig” method. The name comes from a family of parasitic trees that grow on the trunks of existing trees; they begin life above ground and slowly grow their roots into the ground as their canopy grows up and out, eventually enveloping their host tree. The strangler fig method of modernizing code is a pretty direct analogy to its namesake trees - over time, elements of the existing code base are replaced with modern versions until ultimately none of the initial code base remains.

Image Credit: CM First Group

Doing What Makes Sense

Using your existing work whenever possible allows us to help you progress faster and at a lower cost, making it our go-to choice. Weighing the various factors that impact usability of existing code help us to determine the proper methodology to use, and the fact that we don’t have to make a binary “all” or “nothing” choice when it comes to retaining existing code gives us flexibility in how we proceed. Ultimately our goal is always to help you reach your next business goal.

About Mile Marker

Mile Marker is your strategic partner for agile software development. Created for founders, by founders, we offer strategic software at startup speed. We specialize in aligning your technical work with your business goals through collaborative planning, offering a multidisciplinary development team, and ensuring ongoing support for your software. If you’re searching for a software development company or need a technical partner, start the conversation with an introductory call.

bottom of page