Systems Can Coexist
A look into an engineer's mind when it's time for change.
Preamble of sorts
This was inspired by Tackk's editor widget refactor & that feeling that rewriting "all the things" is needed but the timing is not ideal.
The Brains of the Operation
This was the day I started implementing a new api.js file into Tackk. Its primary objective would be to deliver all requests to our server-side API from the browser, marking the beginning of a new system in our codebase. The old system is comprised of a bunch of random jQuery.ajax calls & Backbone.Model save's. But why do this now? The task at hand was to lay the groundwork for Tackk Stream.
Recently, we needed to make a global change for all AJAX requests to include a security parameter. Which we accomplished by modifying global jQuery ajax settings in our core.js file. That worked well because Backbone uses jQuery's AJAX method.
However, the old approach is a bit limiting. With this new approach using api.js as a proxy will gain much more flexibility when handling our requests & responses from the API:
- Errors can be handled in one location. This eliminates all of the error code needed to handle the failure of every request spread thru-out. And it forces all API endpoints to respond in a uniform fashion.
- Allows us to modify universal parameters like the APIs location or security code in one spot.
- Logging or recording API activity is also easy & simple now that it's all centralized... (well, not quite yet).
With so many obvious benefits it'd be foolish & lazy to not implement this new idea. But the question must cross your mind: "Is the juice worth the squeeze"?
The old method is spread throughout the codebase. Turning everything over to the new system would quickly evolve into a much larger project. Not only will the client-side API requests & response handling all need updated but some endpoints on the server-side will need to be tweaked as well.
If you're not a programmer, stick with me. We've all had moments like this in our jobs whether we work with codebases or spreadsheets, plywood or scrap metal. There's always an opportunity for change to make operations run smoother & more efficient. There's always a chance to set yourself up for success tomorrow and a hesitation that it's not worth it today.
In my world, systems like this can and will coexist. The key is how and when to let them coexist, then killing the old one when the time is right.
The How & When
It's never as difficult as you think to implement a new idea. How? Goal setting is a major key. It sounds boring but it's highly effective. One of my favorite TV shows of all-time was LOST and I believe it was so much better than other shows because they had an end-goal in mind. It provided focus and allowed for steady progress.
The funny thing about setting goals is that it affords you a certain amount of freedom. Consider budgeting money for a moment. When you proactively plot your income & where it is going to be paid, you gain a huge amount of freedom in where you spend the rest of your money. With a plan, you never feel regretful or panicked about a purchase. The same goes for budgeting your time.
Set your goals. Chunk the workload into sections. Decide which are the most important & which tasks are deferrable. Then you have the freedom to implement this new idea or system alongside the old system until the old system can be properly disposed of.
It's very easy to let your mind run wild with the potential of your new idea but you have to be able to limit yourself and learn how to say "no" to yourself. Good ideas can be implemented on a minimal scale so that it does not add barriers to your overall progress. In fact, when done correctly you're rewarded with steady progress.
If you remember the task at hand & focus your efforts, you'll remain on-point while bringing a great new idea to life. And soon enough if the idea is as good as you believe, it will spread like a wildfire and naturally consume and destroy that original method you set out to replace.
When implementing the new idea of api.js, I did not go outside the walls of the task at hand. As a result, it was implemented in perhaps 5% of its potential use-cases. Shortly after implementation another job was necessary that could use api.js, and so it was used. The number grows to 6%, 10% & still growing.
As my good buddy Neil Armstrong once said, sometimes "one small step" forward is, in actuality, a "giant leap" in the big picture. That said, you must walk before you can run.
So, "when" with the new? In short, it's always a good time for a good idea.