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.

Natural expansion

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.

Comment Stream

3 years ago

Would love to read some thoughts & examples from your own paths on when it's ideal to have two solutions coexist.

3 years ago

Right on, yo. I always like to say that *software is a living organism*. There is rarely ever a point when software is "done" -- great developers understand [kaizen]( and that there will most always be requests for new features and improvements. If not, we'd all still be using Word 97, and that's just software used to put text on the screen. 😃

When you get into the habit of continual improvement and mastery of the domain and your craft, your realize software is about helping users communicate with computers. The easier you can make that translation, the more people will intuitively want to use your software.

Great code is refactored in small steps, so you should never have to do the mega rewrite. *The mega rewrite is a sign of a system that has stopped speaking the language of its users*. Software like that was built with speed-to-market as the number one priority, assuming less cost equals more value. I prefer quality-to-market, the end-goal being long-term value through easy maintenance, knowing that it's more important to understand that software _will_ change, not so much _how_ it will change.

By leaving the campfire cleaner than you found it, you're saving the next developer the time it took you to understand something -- you're removing that wasted time (negative value) so that the time saved can be spent on innovative or creative solutions (positive value) to solve actual problems. In other words, you're focus is not to create the perfect system that will never need to be changed -- your focus is to develop software to the best of your understanding, and then refine it as needed as your knowledge of the problem domain increases. The faster the feedback loop, the faster the software can adapt.

Open in New Window