A way of life
Let me give you some context, it might not make much sense to begin but bear with me. I grew up in a country where inflation reaches double digits. There is a continuous race between salaries and cost of living. It has suffered a few economic crashes. Yet, people manage to lead a “normal” life or, at the very least, a routine. The one thing everybody in my country is quite proficient is debt finances. I approach technical debt in the exact same way and I want to share it with you.
The plague befallen on our project
Nature of the problem
It is not uncommon to hear people speak of technical debt as something that happened to them. A tragedy that hit them for external reasons. Something they cannot control and was unexpected. Software projects, at least those who are driven by profit or in the context of a business, are the product of two very distinct worlds. On one side is engineering, a discipline that, with enough planning, can produce a fitting solution to most issues that will outlast the problem and the engineer. One usually hears tales about ancient software running on no longer made hardware, still working, for companies and processes long gone. On the other side, there is business, which is also traversed by market opportunities and commercial trends momentum. Trying to amalgamate a craft that can increase its deliverable quality by honing the tools and planning for as long as necessary with another that can reap great benefit of timely events and delivery will, almost always, lead to compromise.
We are all on the same ship
An engineering team will set sail for a given trip, load supplies and assume that by working on the trip, their deliverable will be ready by the time they reach port. The business team will spend the trip signalling ports, studying maps, talking to crossing ships and at some point, will decide that next port is the new destination. A clash of wills happens at this point, where the reality of the business dictates that best profit will be obtained if the product is sold mid trip. This is how technical debt is born most of the time.
Back to my roots.
I have been that sailor.
I can’t say this never happened to me. In our analogy I have been mid trip with sales pointing to shore and half a product in my hands that needed “completion” in an unrealistic timeframe. I have patched with duct tape and believed I would have time to complete it, according to original plans, later.
Reality hates plans
No matter how well planned a product is, it will change once it touches the customer. Thinking that a plan is so good that the customer will receive a product that will fit them so perfectly that completing it as planned is the best path, is a lie we like to tell ourselves:
- Time changes the context of the product
- Time changes customers
- Contact with customer creates new needs
More anecdotes
Returning to my introduction, this is how we dealt with the weird economic reality we lived in: By making predictions on how our income would follow inflation (the context allows this to some degree) we could infer which credit rates were going to produce 0 loss and, sometimes, even positive outcome. At some point in my life, it would make sense to pay the monthly grocery shopping in 12 monthly instalments. Using financial instruments that reduced the interest rate below inflation, one could expect to have the total price of the goods to signify a smaller percentage of one’s income by the time the payment is completed than if paying cash. If this is hard to grasp, think it in the context of a more normal economy. You might have enough saved money to buy a brand-new car. Your bank might have a nice offering where you can get a loan to pay for the car at a low interest. If you can think of a way to make your money generate, at least the same interest than the bank rate, you should get the loan:
- You might find a better loan to refinance in the future, saving you money
- You might need that liquidity later for better investments or something else and it would be readily available
- Inflation might go over your loan rates and if your income does too, your car would be cheaper.
And now in tech
The above explanation is quite analogous to how I approach technical debt:
The initial design of the product contains a high load of business goals and intentions in it. There is much more input of the desired effect than the intended solution to be provided.
Every new feature is planned as if it is due for completion in the first port. Without being careless (Security and stability are a concern always, scalability not yet) I plan to build most of my product out of minimal and fast components. A list of priorities is made and then, with each port we do not dock into, that list is consumed by completing items.
I almost never delay delivery for completion, perfect is the enemy of good.
I never let scope grow without a realistic concern (again, stability or security). Once something reaches a customer it is bound to change so the less we build the more our future work will be building and not remodelling (which is significantly harder).
Before Starting each new feature or large chunk of work on a project, I check how the existing debt will affect the project at hand. I always choose to pay the debt if it affects it, new project can be used as re-financing, but piling debt on top of debt is a recipe for disaster.
Use potential low times for paying debt. If properly kept, the ledger of technical debt should be prioritized. Ordering criteria should be according to whatever is important to the team but also estimate time of fixing should be calculated. One should take from the top of priority when time permits or just solve the faster ones if not possible
A happy arrival to port
Finishing the sailing analogy (It is clear by now I have no clue about sailing). This methodology has kept me afloat for several trips. I am hardly overloaded with tech debt. One way of thinking that I would like to use to close here and that has helped me so far is: We should not think about software projects as something with a beginning and an end. I conceive my software as if I was selling service leases, I provide a development service and, if we are in business, you will always get fresh software for the need at hand. Focusing on a periodical deliverable helps ease anxiety for completion.