..or, how not to paralyze your future self.
When we talk about technical debt, we’re talking about paralysis. It means an organization can’t do something good today, because it handcuffed itself in the past with a poor decision.
There is nothing inherently bad about old code. Over time, coding styles, architectures, and environments may change, but code can often be operational and maintainable for a surprisingly long time. In many cases, tech debt is a treatable condition. It might slow you down, but it needn’t paralyze you.
The pressure to beat a competitor to market or hit a deadline mandated by a partner or vendor can be very real, so it is understandable that some steps might get skipped along the way. At early stage startups, in particular, this is often the case. It is reasonable that a programmer may be forced to skip some practices that would otherwise make their code easier to work with in the future, such as unit tests, avoiding globals, and good organization. Tests can be backfilled when the capacity allows, inefficient procedures can be optimized, code can be refactored or replaced over time.
The tech debt that is hardest to treat, however, is some of the easiest for a programmer to create, because the practices they’re skipping can seem so unimportant at the time.
The three practices that I think should never, ever be skipped are:
- descriptive, accurate names for methods and variables
- docblock that explains the purpose of the method
- comments that explaining complex business logic
Each one is a version of the same thing: communicating intention. They are such simple steps, it is easy to overlook their importance, but their impact on maintainability is massive. It’s very hard to repair, adapt, supplement, or replace an old code base when the intentions of the original programmer were not made clear. Even if you are the original programmer, you may not remember a year from now (or two, or ten…) why you did $x = $x + 4.
When we write code, longevity is not always top of mind. Will this feature be a hit, or a dud that gets scrapped? Will the product find market fit? Will my startup fail to get its next round of funding? It’s key to prepare for success though. Just as it’s important that your code can scale with regard to load, it’s important that your code can scale with regard to maintenance over time.
If you must compromise the standards of your code, make sure you at least adhere strictly to these practices, and you’ll avoid paralyzing your future self.