Whenever real estate technology vendors rewrite some of their code — tearing it apart and then rebuilding the same features immediately afterward — that’s called a refactor. Most commonly, the term isn’t referring to rebuilding the entire application, but rather is a focused rebuild on a single feature at a time.
Real estate brokerage technology changes rapidly, and proper code maintenance is an absolute must. Although refactors can be daunting undertakings, real estate technology vendors should embrace them! But all too often, you see real estate tech that is outdated, slow, and no longer best serves their real estate brokerage clients. Having the right vendor in place that’s willing to make long term commitments to keeping their code updated is an important step – take a peek at our Checklist for Working with a Real Estate Brokerage Platform Vendor.
Why refactors become necessary
- The current code structure no longer meets real estate brokerage client needs
- The tool has become slow
- The app has become overly complex
- It becomes difficult to add new features
- It’s hard for other vendors to connect to the platform
- The system can’t be rapidly scaled for client growth
- The tools/frameworks/integrations the app uses are outdated or producing errors
- Developer happiness while working on the product has gone down
Any of the above items can put a strain on a real estate brokerage technology product and their team. As soon as they spot new feature development hitting snags or stalling out completely, or if the app requires much more time on maintenance than they can commit to new builds; it’s definitely time to recommend that the vendor consider the possibility of a refactor.
Learn About Our New Ads and Leads Program - TRIBUS Engage
Things to avoid during a real estate brokerage technology refactor
Before a vendor dives in, they must be knowledgable about this process. Every refactor will require all team members to exercise restraint, and that’s where a great project manager comes in — their role is to keep the team focused, and say no a lot. It’s not always the most pleasant role to play, but the end result will definitely be worth their while. Here are more specific elements a real estate tech project manager will often need to say no to:
- New features
All feature development should be frozen during a refactor. Staff will naturally get excited at the idea of a fresh start, and each member will begin to envision their ideal version of the product with many new bells and whistles, but this isn’t the time for those conversations. To make this extremely clear, at TRIBUS, we don’t even scope out new features while a refactor is in progress, because so much is changing that it will produce outdated documentation that may never be used. Once the refactor has been completed, they can jump back into feature-mode. - Bug fixes
The more time spent chasing down and resolving errors in the current code, the less progress will be made on the refactor. Unless the bug is an absolute emergency, it should be set to the side and tested again after the refactor is complete. The refactor’s purpose is to reduce complexity and produce cleaner code, so most bugs will be resolved automatically during the rebuild. And for those that aren’t, they should be much simpler to solve once the refactor is complete and live on production servers. - Spec with too much detail
A refactor must meet the current specifications in order to be successful, so they should already have the outline they need to begin just by reviewing the current product. I prefer to isolate a single module/product at a time whenever possible, which allows planning to be a more focused exercise. We start by making a visual of the current structure and compare that to our ideal structure, but without compromising any features. They’ll end up with a puzzle-like diagram instead of a lengthy written document, which our team prefers for this type of project.
Things to accomplish during a refactor
- Discuss backwards compatibility
Now is the time to decide if the real estate technology vendor will remove or change any core features (where any vendor should consider the Who Moved My Cheese principle), and how they’ll handle converting anyone using the old feature to the new. Will they need a migration script? Will they support both methods for a period of time, and if so, how long? How will they announce the changes and provide new documentation to everyone involved? If you’re the sole consumer of your product’s data/it’s fully under your own control, this is still a valid conversation because there may be other features elsewhere in your application that rely on the current code. - Do your research
Before making decisions, spend time on brainstorming and discovery. Development standards and tools change rapidly, so hopefully your vendor researches as many options as possible before they commit to a direction and approach. At TRIBUS, we’ll often break our dev team into groups of two, so they can hash things out together. This stirs up new ideas and raises more potential pitfalls than a single developer may have considered on their own. We’ve found that it’s always good to get another team member’s feedback before making large-scale changes, even if they don’t usually work on the exact same projects as you do (in fact, varied backgrounds can be helpful). - Make a schedule and stick to it
A refactor will take longer than they originally thought, because they will discover new obstacles and problems to solve as they go. We typically like to tackle refactors during our slow season when more of the team can be fully engaged. But it should be made clear to all of staff (and possibly customers too) that the vendor is going to enter a maintenance phase, and set expectations in advance. Hopefully they also schedule in much more time than usual for testing, since they’ve got to write and execute tests for everything that changed, as well as everything that interacts with code that has changed.
Consider the cost, time and value
Although some teams may have decided that a refactor is necessary, sufficient time isn’t always available right now. Timing is especially difficult when the team is small, because it will feel like everyone’s time is already fully committed. In those cases, vendors should be realistic with what they must develop versus what would be nice to develop, and consider the long-term effects before making a final decision.
Developer hours are valuable and a real estate brokerage technology refactor can take a substantial amount of time to complete, so the team leads must be careful that the timing makes sense and their needs actually warrant a rebuild of this scale. If they’re considering a refactor solely for neater code or to satisfy a perfectionist on the team, I would suggest holding off for now.
Even if the answer is no for the time being, there’s no harm in discussing refactors frequently — every time a vendor runs into a problem that their current structure makes it difficult to solve. Ongoing conversations are especially necessary if they manage an application where the feature set, customer base and/or development team is changing rapidly.
What if a real estate brokerage technology refactor won’t meet all needs?
If the vendor has many intertwined features and dependencies between various products; it can be nearly impossible to isolate a single module. In cases like this, a refactor may not get where they need to be and it may be time for a total rebuild. At this point, the discussion becomes much more serious with options like versioning their platform, creating a new API, or starting from scratch with a complete rewrite.
