Speed vs Reusability
Listen to this post on your podcast app under: Gregory Schmidt, or on YouTube:
Theory
Over the last few months, I’ve been a part of a conversation about the tradeoffs between speed vs reusability. I’d like to highlight this as a two-by-two graphic.
Below is a two-by-two grid. On the horizontal x-axis is speed. Moving from slow on the left, to fast on the right. The vertical y-axis plots reusability. This moves from non-reusable on the bottom, to highly-reusable on the top. (note: the term reusability, can also be substituted with other terms, such as automation, or generalizability).
Many existing organizations, and new startups find themselves in the bottom left quadrant; existing in a state of being very slow and non-reusable. The goal is to move to the top right quadrant, where things move fast and are highly reusable.
Moving quickly and having high reusability go hand in hand. Past posts have discussed the benefits of modularity and reusability, in the ability to do things quicker and more cheaply.
However, how one moves from the bottom left quadrant (slow and non-reusable) to the top right quadrant (fast and reusable), involves two potential routes.
Route One, has a primary movement along the horizontal x-axis from slow to fast. One starts in the bottom-left quadrant, moves through the bottom right quadrant up towards the top right. This comes with the more immediate benefit of speed. The tradeoff is not achieving early reusability, and this may result in more efforts later on to achieve reusability.
Route Two, has a primary movement along the vertical y-axis from non-reusable to reusable. One starts in the bottom left quadrant, moves through the upper left quadrant, and then right towards the top right. This comes with the benefit of higher reusability early on. The tradeoff is lower speed at the beginning, and this route may be more resource intensive.
Examples
The above framework has been rather vague, to make it applicable to many settings. Let’s make it more specific.
Example 1: Typical startup
In startups, the debate between reusability and speed is often a discussion between technical considerations and product development considerations. From a technical perspective, it may be preferable to write code that is more reusable from the start. However, product development may prefer to ship products faster, to help test if the product is the right thing (think the The Lean Startup).
In theory taking route two - reusability - may achieve a net productivity savings in development resources. However, the reality is this savings only is possible if a clear pathway of what should be developed exists. If there is uncertainty in this area, as is common in many industries and new ventures, there may be benefit to first shipping products faster and improving the product-market fit over reusability.
The tradeoff between reusability and speed is an alternative take on Paul Graham’s classic post: Do Things that Don’t Scale. Doing something that ‘scales’ (eg. more automated, reusable, generalizable), is closer to route two. However, as Paul Graham’s suggestions generally favour first doing things that don’t scale, which I believe is often closer to Route 1.
Example 2: Reusability as fundamental to business success
This does not mean that Route One is always correct. For instance, in the case of SpaceX, the core business proposition is one based upon rocket reusability. Being able to position themselves in the upper quadrants of high reusability, SpaceX could drop the per-launch cost of spaceflight.
Taking route two is certainly possible, and at times required; however often more upfront initial resources are required to make it happen.
Example 3: Competing hypothesis
Currently, I am working within an open-source enterprise software project. There are two competing hypothesis that require testing.
Hypothesis One: is from the technical side. The hypothesis is that building an environment that makes it possible to achieve high reusability of the codebase will increase developer and team collaboration. This in turn will increase the speed that products can be built, making it possible to more efficiently build, test, and deploy new products.
Hypothesis Two: is more from the product side. The hypothesis is that prioritizing new product development (speed) will produce a better understanding of what should be built, and this ‘tangible product’ will increase shared developer resources and team collaboration. Which will in turn make it possible to dedicate more resources to achieving high reusability of the codebase.
How to best balance these questions remains to be seen.
