Ever wonder about the inner-workings that make Harvest tick? There are a lot of continual updates to our codebase that our users never see. In the lull before our next update to Invoices Overview, we thought it a good chance to give you a sneak peek into the behind-the-scenes work our developers do to make Harvest run better and faster. In this post, our developer Pez gives you a first-hand glimpse into his work to improve the code for Invoices Overview.
Here at Harvest, we like to ship new features, but also take great care to continually improve existing functionality.
We launched Harvest back in 2005, before Rails had hit version 1.0 and Ruby was still at version 1.8. That means we have our fair share of legacy code. Recently some of the legacy code had started to become a blocker to our aim of continual improvement.
When we decided to update the Invoices Overview screen, we had a choice: develop new functionality on top of the existing code, potentially making the problem worse, or rewrite our code.
We decided to take a step back and re-architect this section of Harvest. This meant we could bring the area up to modern standards with feature parity, and then start implementing a few new features to make the section even more useful.
What’s the Problem with Old Code?
Why is legacy code such a bad thing? If it isn’t broken don’t fix it, right?
While it’s true that features written in legacy code will work, legacy code can eventually become a barrier for improving existing functionality for a few reasons:
- It often has less test coverage, meaning it’s easy to break things without realizing.
- It’s usually harder to understand, having drifted from the originally engineered design.
- The additional complexity makes it harder to debug and more complex to add functionality to.
But why does “legacy code” exist in the first place? Continue reading…