I so like comparing incurring a tech debt to taking a financial loan: You borrow Quality, in order to buy Time.
There is a car I want to buy. But I’m already overdrawn in Bank.
- If I buy the car now I will overdraw my limit and the bank will nail me with additional fees (Bastards, don’t have enough). I’ll pay off later.
- On the other hand I can pay some debts off and buy the car next month (and in meantime enjoy super-sonic public transport brought to you by district line).
In life I would definitely buy the car and worry about debts later. So what I cannot drive it? (some say that food is more important than gas but I’m not so convinced). At least I can wax it.
In software buying a car is a functionality to implement and being overdrawn is like having a tech debt. What would you do? Would you plug the functionality first and then refactor the debt? Or rather first make the place in the system and then implement the story?
Some thoughts about pros and cons of both approaches:
- I can reliably measure the gravity of tech debt because I have to implement the story first and feel all the pain. I will know exactly what’s the interest rate for tech debt. It will be easier to make a conscious decision whether to pay it off or not.
- I will know better how to refactor it later since I did the story first. I will have all the information: code-wise understanding of the tech debt and knowledge about the story (technical requirements, code-wise problems).
- I waste time. Hacking in the story first takes long. Then the refactoring takes long. If only the refactoring was first the story could have taken 5 minutes…
- Let’s say I spend a day on implementing a story. Next day the business wants to know why am I refactoring piece of functionality that already works? I try to explain the tech debt and how easy will it be to implement future similar stories. Oups. Did I just forget about YAGNI?
- I may not be certain if paying tech debt off was really necessary. Perhaps implementing the story first was not too bad…
- It’s faster. Initial refactoring prepares a decent landing zone for new functionality. Implementing a new story after is blind fast.
- Let’s say I spend a day on refactoring. Next day It’s easy to tell the business that I couldn’t implement the story until some refactorings (paying the tech debt off) were in place.
Sometimes I can mix both ways but generally I prefer to refactor-first. It’s just faster and in my experience proved to be better. I hate to refactor-after because it leaves me the choice not to do it. I don’t like having choices – I prefer to fine-tune my approach/practices/process so that in front of me there is only one choice, one path. The right path of decent code.