Speed vs Shipping

Should we sprint to the next mountain top or plan a bit before we move ahead?

Justa.io is in the middle of a transition. The stated goal is a refactoring of nearly our entire technology stack. Why should we take the time to rewrite an entire website from scratch? Especially considering that Justa is already fully functioning in production.

More importantly, at what point (if ever) do we decide to throw out the old stack and make room for the new stack?

Let’s frame this debate between the following factors: 

  • Shipping is critical and necessary to move a business forward.
    • “Shipping” meaning we have effectively provided some deliverable (a feature or a full project) to our clients.
  • Speed is critical and necessary to move a business forward.
    • “Speed” meaning we can effectively finish a feature without burning our development budget or over-running our schedule.

Okay, speed vs shipping, who wins?

Speed wins. Why? Our ability to ship is based on our ability to effectively develop quality improvements for our product. If we are going to “effectively develop”, we will need our code, stack, deployment process, etc… to be under control. Technical debt implies that those things are out of control and ultimately a liability to our productivity.

Our ability to ship is a function of our ability to effectively (and speedily) develop.

Our ability to effectively develop is a function of our technical debt (also skill and experience level play a large role, but let’s focus on technical debt which can easily outweigh both of those!).

Technical debt is a function of …?

We have a ridiculous number of options to reach our development goals. But, what gets lost in the noise is the fact that these options exist to help us save time, not waste it.

Technical debt could be coming from any or all of the following:

A few poor engineering choices can easily snowball into a vicious cycle of “let’s do this for now” where “let’s get this right” gets lost in the noise. What’s more are the external factors of management, budgeting and market pressures which can exacerbate the above factors into years (or even decades) of wasted capital that could have otherwise been spent on improvements, polishing and building market share.

Shipping is non-negotiable

Despite all of the above, we must ultimately ship our product in a reasonable timeframe. This is, after all, the reason we get paid.

The terms “vaporware” and “development hell” exist for a reason. Delays, budget constraints, office politics and unforeseen external factors can easily derail the most carefully planned projects. How can we push through when these issues arise?

  • Communicate with our stakeholders
    • Does management grasp the necessity behind the project or feature being worked on?
    • What’s the perceived value of what we are doing? Has that been fully communicated?
    • What’s the story that anyone (but especially management) would take away from our efforts if viewed objectively?
  • What are the worst case scenarios for our current efforts?
  • Cut corners if you have to. Lose battles to win the war.
  • Sometimes there are just a handful of misunderstandings preventing an ambitious project or feature from getting through the pipeline. Try to close those gaps!

As Justa moves forward

At Justa, we are in the process of improving our systems with our eyes on being a competitive hiring platform that results in great experiences for our candidates and our clients. Reducing our own technical debts and shipping a newer, higher-quality Justa.io is on the horizon, and we hope you’ll stay with us for the journey. Stay tuned folks!!

By Jay Melo

Comments are closed.

Create a website or blog at WordPress.com

Up ↑

%d bloggers like this: