Often, we’re called upon to deliver last-minute fixes or features to satisfy a need from the client. The best solution is to work with the client to deliver a solution that works for them with enough time to properly design and execute. However, the client may not have the time to give. It’s not an option to take the time to engineer the best possible solution. You can only engineer the best possible solution at the time.
When the client is in a critical situation, we want to help them. Our job is to make them a success. Circumstances may be beyond the control of the client. They may be under pressure to deliver a feature or connect to a data provider or any number of things in order to even minimally operate. They may not have the time or ability push back on their clients to “do it right.” I’ve been in military exercises where the provider of a data feed was changed at the last second. It wasn’t an option to not switch to the new data feed. To meet the needs of the client so we must go into technical debt.
Technical debt is the idea that to support the needs of the client, we pull out the usual stops. We need to deliver a feature or fix or something to the client in a hastened fashion. We may skip a proper code review or writing thorough unit tests. We may not be able to refactor the code to cleanly insert our needed feature.
When implementing emergency procedures, its important to document what we’re doing and try to make it easier on ourselves later to refactor the hasty code. Things will be done in haste. Trying to write our code as clearly as possible will allow us to refactor more easily later.
Going into technical debt isn’t necessarily a terrible thing. Continuing to stay in technical debt though puts us into technical deficit. A project in technical deficit will be more difficult to maintain and modify. Changes are harder and riskier to implement. The cost of allowing a project to go into technical deficit is that all development is going to be costlier in terms of time, money, and risk. And, ironically a project in technical deficit is in greater risk of needing more technical debt.
Ultimately, as our software matures, it should become cleaner, more robust, and more modular. Contrary to popular belief, software should become more spaghetti like as it ages. However if it is spaghetti-like, we’ll go into techniques to get out of technical deficit next time.