|
|
|
|
|
|
by michalc
2665 days ago
|
|
|
I like the analogy, but it slightly suggests that you're always powerless along the way and that the debt is inevitable. I think there _is_ a technique that is possible in a lot of situations: not putting in abstractions/complexity that don't really do any of transformation/transfer required of the underlying requirements. The reason why this is often possible, is that it's _less_ work to start with compared to adding in the layers... ... and then when unexpected requirements turn up, there is less complexity to deal with, there are fewer layers to work/hack around, and refactoring those that _are_ there to be more suitable to the current set of requirements is often easier, and so more likely to fit into time constraints. I like to think of it as: > Just about everything is cheaper than the wrong abstraction (With a clear nod to Sandi Metz) |
|
|
We are, and it is.
>I think there _is_ a technique that is possible in a lot of situations: not putting in abstractions/complexity that don't really do any of transformation/transfer required of the underlying requirements.
That's no good, because we can pile debt even when we don't put in "abstractions/complexity" that are not required.
Plus, the abstractions we built (that were 100% necessary) 1 year ago, can impact a big debt into the requirements we have now.
Debt comes from (a) the mismatch between the cleanest/fittest implementation and what we have done instead (which would always be there), (b) things set rigidly, even if they were OK for then (c) changing requirements that force us to work around our imperfect and rigid implementation.
So, it's multifold:
1) We'll never be able to write the cleanest implementation (due to time/skill/etc. constraints)
2) Even if we get close to the cleanest implementation, we'll never be able to foresee all kinds of future needs (and if we try to plan ahead for "possible cases" before we know what they actually are, we're just making things more verbose and rigid if we were wrong).
3) When the new requirements actually come, we won't have time to rebuild everything, and thus we need to build on top of what we have, adding things that go to new directions and for which our previous structures are not ideal
Rinse and repeat.
The only way to avoid debt is to work on smaller, constrained problems, that don't change and which doesn't have to adapt to changing environments much either (e.g. write the 'grep' program). This gives us all the time to polish our implementation, rewrite everything we want, etc.