Your code is your legacy
Why every developer is writing code that immediately becomes legacy and how to think software development, maintainability and technical debt in the long-term.
Do you still remember what you wrote yesterday? It is old. Not as old as your grandma, and not as old as in outdated, but old as it already is not the best you could do anymore.
Once you completed a task, not the code you created is the valuable thing, but that knowledge you gained while doing so. And if you were to do it again, right now, the decisions you’d make and the paths you’d take would already be dramatically different.
And thinking this a bit further, you will ultimately end at one of the basic laws of software engineering. You either go about your daily work and just add new features and fix bugs, or you change the architecture and rewrite your code base to keep it maintainable and reduce technical debt. Both ways, you’ll end up producing stuff that will not live up to the expectations in the near future, for any reasons.
That is why all your written code will eventually turn out to be legacy code and immediately is, actually. And to add another inconvenient truth: your software is in the constant process of dying.
Well, how do we deal with it? You can be very sad about it and deny everything I just wrote (you might want to google the five stages of grief now) or you can stare this evil rabbit directly into the eyes and confront it in an epic battle, going head first. I opt for the latter.
Here at COYO, we made a bold decision to complete rewrite our application anew and then migrate all customers to it in 2016. After some development pains and delays, this eventually worked out like a charm. It was a gutsy and smart one-time move to jump into the future by doing something from the past. But it is my heart-felt belief, that in times of cloud computing, we see that versions cease to exist, at least from a user’s point of view, and continuous deployments and feature delivery make gradual rewrites and architectural changes the only way to go.
So what does this mean for COYO? With our software reaching a more mature point in its life, as core components are now some three to four years old, we start so see an increasingly amount of libraries with end of lifetime on the horizon. That is something we have already dealt with in the past (AngularJS to Angular migration) but also leads us to taking precautionary measures for a technical more apt and sound platform, that is well-suited for all the latest technology rage yet to be invented.
So we are currently well underway to modularize our backend, upgrade ElasticSearch, finish the Angular migration and so on. But we have also taken a different approach introducing new features or add-ons. Why not have a micro service for it, written in a then to be determined language with a then to be determined technology stack, if there is a strong case for it?
Because once you have realised that your code can only be at its best in the very minute you wrote it, you will also start to think software development, maintainability and technical debt in the long-term and come to the conclusion, that even during the development of just tiny parts of the software, there are the ever more greater decisions looming in the backend.
Don’t make them lighthearted, because they can eventually affect the overall lifetime of your product. But at the same time, be curious, adventurous and bold about it, because the only future-proof direction is forward.
COYO has understood this well and gotten better and better over time to live this by example, and you will continue to hear from us about that journey in future articles. So long and thanks for your time.
