Take two: rewriting a system from scratch
This month's IndieWeb Carnival asks us to write about “Take Two". What came to mind for me was something from my professional work as a software developer. As I am sure most people who have worked on larger development projects know, most things could get better if we could rewrite it from scratch.
In practice that rarely happens as businesses need to adapt to a changing market, while also maintaining legacy functionality and backwards compatibility. As a software developer you learn to work around these things, you try to design new features with possible unknown future changes in mind, but reality isn’t always what you thought it would be. That doesn’t necessarily mean that the system design made years ago was wrong, it was just the right approach with what was known at that time.
So when working on the same project for a long time, you get to build a pretty good mental idea of the “ideal” system design. This can be used to gradually improve things through refactoring when possible, and while any system will likely never achieve an ideal end form so to speak, it is a good thing to always want to improve the current codebase and not allow technical debt to grow out of hand.
My “take two” in this regard was that a few years ago, we got the chance at the company I work to write a system from scratch in an idealized version. Admittedly a simpler system focusing on the vital core functionality of our main product, without all the years of feature creep and odd decisions that naturally adds up over time. But since we already knew what worked well and what didn’t with our current codebase, we could relatively easily design and implement everything from scratch and deliver the project ahead of schedule.
Not having to deal with backwards compatibility or too many features made things easier, and it is not like this new system is absolutely perfect in every way, but it works as a solid foundation within my team and it has helped us improve our main product, by gradually incorporating the good architectural decisions back into the older platform.
The experience from working for years on the original product made us able to do it much better the second time, and it helps improve the original product along the way. There is some profound beauty in that I think.