4 ms·
Technical debt should be quarantined, not structural. That's the one, most important thing to take away. A really messy view with tangled if statements and hack
by 3pt14159 8y ago
Technical debt should be quarantined, not structural. That's the one, most important thing to take away. A really messy view with tangled if statements and hacks to get things to work isn't great, but it's leagues better than a really messy controller because it isn't going to introduce ACL errors. A really messy controller is leagues better than a fucked schema / data model because it doesn't spread the poison across every endpoint in your application.
Some easy wins are to default to making something a "many", even if it is only a "one" or a "one or none" because it makes adding a second case much easier. For example, a user should have multiple roles at multiple projects by default, so business users can do fine grain control over permissions.
Another useful trick is to have default behaviour, but introduce a set of tables for custom settings. This makes it easier to make changes because you don't need to run a migration to add a column to a table, you just write a new record to the "user_overrides" table.
But at the very end of the day, taking on technical debt of any kind can be warranted. It all depends on the stakes. If you need to get something done in a week to close a company-saving deal, then fucking do it. Fix it later. The implied interest rate might be 1000%, but if it saves the company it is worth it.
- katnegermis 8y agoOne of my friends came up with a tongue-in-cheek name for your "default to many"-advice: https://theharemrule.com https://theharemrule.com After being given the advice couple years ago, I found it to be applicable to quite a number of scenarios me and my colleagues faced. In my experience its pretty solid!
- 3pt14159 8y agoYeah, it's one of those tricks that I find a lot of developers in their 20s haven't learned. There is another trick that I use when I don't control the dev team. For example, say the company has outsourced a pricing app to a third party dev shop, in this case any decision I can make that will make the app more "table-y" I make. So instead of defining control flow to determine price for any given object, what I do is I get them to make a "rules engine" that can operate on the major variables that are typically used to make decisions. That way fine tuning changes can be done on our side, and it doesn't rack up billables. I think this is called "table based design" but Googling for it isn't showing anything.