Live data from Hacker News

Technical Debt Is Like Tetris

medium.com

1–10 of 32 posts

Re: Technical Debt Is Like Tetris

#8
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)

Re: Technical Debt Is Like Tetris

#9
Is tech debt subjective? I've worked on different teams that call anything from wrong grammar in comments to incorrect capitalization of a var name tech debt. Wondering if it follows that more code = more debt because more people have opportunities to disagree about how something was done.

Asking for a friend.

Re: Technical Debt Is Like Tetris

#10

This might be captain obvious to some, but I think it still needs to be said: Technical debt is like any other debt and needs thorough analysis and some business strategy applied before things can and do get better.

You're saying tech debt is a business strategy problem?
Post reply on HN