I believe software development, and the resulting products, would greatly improve if we thought of “tech debt” and “refactors” as V1/V2/etc.
Feature releases should occasionally happen alongside a code evolution (aka refactor). This evolution shouldn’t be thought of as low value nor as a nice to have; it is the core of what we do in software and tech!
This may sound weird, but a great parallel to this is what SpaceX does. They are constantly doing V1/V2/etc. of rockets and engines and so on. Sometimes the new version is being developed before the previous version is even done!
But software is “continuous” and “hidden”; a highly abstract and intangible thing. This nature makes it hard for us to see when (and for managers, why) a refactor is needed, and hard to appreciate the change when it happens. The SpaceX Raptor 3 engine, on the other hand, is clearly different!
This disconnect between the internal reality and the user interface leads to us calling a new look V2, while overlooking a new feature that comes with an overhauled foundation, a foundation that unlocks new possibilities.
The better approach is to treat a given code foundation as V1, use it to develop features you need, and then when the time is right, rework the foundation and release a V2, even if on the surface not much has changed.
V2 becomes necessary due to insights gained developing and using V1 that reveal shortcomings, due to changing requirements such that the V1 architecture is no longer ideal, or due to deliberately skipping known-good things during V1 because of resource constraints (e.g., time/money/expertise/etc.).
A V2 signals to the team and users that something big has happened, that progress has been made, and that better things are coming, which is greatly motivating for everyone!
Both V1 and V3 Raptor engines fly, but it still feels like a step function improvement, even if we laypeople don’t understand why.
It should be noted this only applies to things that matter within your product. If your app has just 10 buttons, you probably shouldn’t spend a month refactoring your renderer.
Care should also be taken to keep this meaningful. Jumping versions every week will make them completely meaningless to both your team and users. You will lose all excitement and sense of progress, and you will be seen as incompetent, or even a liar. Can you really gain significant new insights, and revamp a foundation, every week?
I have started to shift my thinking in this direction with @theoverlordcorp , and I can say it’s been very positive, both mentally and from a product perspective.
You are no longer demotivated by a big required refactor. You more clearly see the step-function improvements in the product that were hidden to even you before (because software is so continuous), and you are more motivated and excited by future versions of every part of your product!