Few days ago, I read a very interesting article from John Brondum and Liming Zhu: Visualising Architectural Dependencies.
Its title is all about visualising architectural dependencies, but its introduction is amazingly interesting (the rest is too, but it is more technical). First it will give you a very strong definition of what technical debt is:
“Technical debt has been used as […] a metaphor in situations where compromises are made for short term gains, at the expense of the longer-term viability of a […] system.”
“Technical debt at the architectural level is considered to be a debt that cannot be repaid through local code refactoring”.
But more importantly, it says: “Technical debt at the architectural level is considered to be a debt that cannot be repaid through local code refactoring”.
So, if you think that you have technical debt and are planning to fix it, start thinking about your architectural debt. What is architectural debt: it is everything that breaks your defined architecture, from a dependency that is implicitly created by another dependency to the absence of interface between 2 elements or a simple model that is used in all your layers.
I’m saying that for all those developers who are saying that it is normal to use a coordinator in the MVVM-C pattern to make dependency injection. You know those guys who can write inside a coordinator, in the init method:
var myModel = new Model(); var myViewModel = new ViewModel(model: myModel); var myViewController = new ViewController(viewModel: myViewModel)
because who cares that the Coordinator has a strong dependency to the Model, the ViewModel and the ViewController), or for those who are using a model used in the ViewModel and also in the ViewController, or for those who are still thinking that a singleton is something that should not be protected by an interface.
All of this will have to be repaid one day, and not by just rewriting a small piece of code or by reformatting a file with an automatic tool, it will have to be paid at the global level and potentially by hand writing…
Of course, if the lifecycle of your app is less than a few months or you are certain that your app will never change (never, never, never…), then forget what I just said and be dirty (and do not read any architectural paper).