At Collaboris we are constantly debating the Technical debt issue (http://martinfowler.com/bliki/TechnicalDebt.html). The questions are always the same:
- Shall we release this new bit of functionality quickly to get customer feedback or shall we spend a decent amount of time designing it before we release?
- What if we spend too much time designing something and the customers don’t like it? Have we wasted all that time?
- What if we release something messy with little design but the customers love it (I can hear the sales guys saying “ship it” )?
- What if we decide to ship that messy new feature because we need the extra quick revenue that it will bring (but you know it was only supposed to be a prototype)? How much is it going to cost to refactor in the future?
Answers are not easy and my feeling is that they lie somewhere between the two extremes.
What are your views on technical debt and how do you address it?
Can’t remember who said it now, but “If you aren’t embarrassed by your first release you left it too long”. (I don’t think it was the guys on the Silicon Valley show either :))
I agree Hugo, it’s a huge point of debate. We are always going to be torn between the needs to keep the bank balance healthy and having a genuine need to produce an application based on an elegant, scalable, secure, flexible architecture.
I’ve complained to many managers about this. Sometimes, you have to use a “bandaid” fix. I get that. If you don’t, you can miss contractual deadlines and kill the whole project then and there. But you can’t spend all of your time holding your code together with thumbtacks and bandages, or your new fancy stuff will never come out.
MVP it is all the way 🙂
Hi Nick. Yep totally agree, the problem is that temporary bandages often become permanent and it’s difficult to convince the people holding the purse strings that they should be spending some money in replacing them with a more permanent solution.
At a certain point, you need to decide “hotfixes only,” and roll any new features into a new release.