3 ms·

One never knows what the future may bring. Long-lived OSS software is a relatively stable bet, but the point still stands.

rootsofallevil 6y ago
>One never knows what the future may bring. Exactly, so make the changes when you need them, otherwise you are relying on hitting the abstraction lottery
jacques_chester 6y ago
Maintaining database abstraction layers and the like is a real option used to hedge the risk of the holdup problem. But like any real option, it has a carrying cost. That means it's an economic question, there is no purely technical rule that can give you a robust answer to whether or not to abstract something away. I feel the industry has a long hangover from the 80s and 90s in terms of the holdup problem. Oracle, basically, created a massive externality of anxiety about vendor lockin that continues to impose drag to this day.
- TimTheTinker 6y ago
  Agreed. “Our software currently runs on Oracle but can be switched to MS SQL Server or DB2 with about a day’s work” used to be an admirable and economically valuable statement. In the majority of cases, I think a simple “runs on Postgres” is even more valuable today (unless your product is a database abstraction layer).
- fulafel 6y ago
  There are complexity limits past which we can't really build or extend applications short of big rewrites. I guess we can describe this in terms of economics but I feel it's not doing the issue justice. And it's often better to spend the complexity budget on domain problems.
pydry 6y ago
Decoupling your data model from postgres because you "might" need to swap database is a bet I've seen taken many times but it's never one I've seen paid off. This is a clear example of where YAGNI applies, I think. Extra work plus extra boilerplate to maintain. No payoff. That said, extra code + boilerplate is a great way to treat riskier software.

rootsofallevil 6y ago

>One never knows what the future may bring. Exactly, so make the changes when you need them, otherwise you are relying on hitting the abstraction lottery

jacques_chester 6y ago

Maintaining database abstraction layers and the like is a real option used to hedge the risk of the holdup problem. But like any real option, it has a carrying cost. That means it's an economic question, there is no purely technical rule that can give you a robust answer to whether or not to abstract something away. I feel the industry has a long hangover from the 80s and 90s in terms of the holdup problem. Oracle, basically, created a massive externality of anxiety about vendor lockin that continues to impose drag to this day.

TimTheTinker 6y ago
Agreed. “Our software currently runs on Oracle but can be switched to MS SQL Server or DB2 with about a day’s work” used to be an admirable and economically valuable statement. In the majority of cases, I think a simple “runs on Postgres” is even more valuable today (unless your product is a database abstraction layer).
fulafel 6y ago
There are complexity limits past which we can't really build or extend applications short of big rewrites. I guess we can describe this in terms of economics but I feel it's not doing the issue justice. And it's often better to spend the complexity budget on domain problems.

pydry 6y ago

Decoupling your data model from postgres because you "might" need to swap database is a bet I've seen taken many times but it's never one I've seen paid off. This is a clear example of where YAGNI applies, I think. Extra work plus extra boilerplate to maintain. No payoff. That said, extra code + boilerplate is a great way to treat riskier software.