4 ms·

Most devs prepare for the abstraction nirvana. I see a lot of fellow devs creating complicated code, because "in case we need to switch out the database down th

Most devs prepare for the abstraction nirvana. I see a lot of fellow devs creating complicated code, because "in case we need to switch out the database down the road" or "what if we want to run the web app in CLI" In 20 years of programming I maybe seen one or two times a large application switched database engines and I've never seen a client want to run his/her web application in CLI... The art in programming is to decide whether you need that abstraction or not.

Double_a_92 7y ago
> in case we need to switch out the database down the road I would still kinda consider that. But the solution wouldn't be to create some massive abstraction. Instead I'd try to separate logic from database access code. I.e. avoid reading data from the database while you are in the middle of some calculation, or in the GUI somewhere. If you need the data do it beforehand and pass it in a generic data format.
Vinnl 7y ago
It's not just programming, though. A large part of it is defining the product roadmap: code can get a lot better if a product team has the guts to unequivocally say that some features are not going to be part of the product, ever, such as running the web app in CLI. That's not just a programming decision - though I guess influencing the product roadmap could be seen as part of the art in programming as well.
- downtide 7y ago
  Yeah I had a manager that was quite good at throwing out functionality. Didn't like it at the time, but they were mostly right - of course they were just trying to save money.
  - james_s_tayler 7y ago
    I like this. Because time after time after time I have seen the opposite. Managers saying "but we might need it again later" and... We. Never. Have. And even if we did... its still under source control if you really want to dig it out.
    - codr7 7y ago
      Second that, after 34 years in the game I'm always on the lookout for dead or dying code. Every line I can put out of its misery is one less to deal with in the future. And I find that removing dead code often unlocks further improvements that become obvious without the noise. Even if the functionality is needed down the line, it tends to require massive rewrites to catch up.
schwurb 7y ago
Of course it all depends on the application at hand, but databases and other system endpoints are something I treat as volatile. However, I don't commit to the madness of replicating a whole database interface in our codebase. Instead, I find it sufficient to bundle all database access in a single point. (i.e. by using a singleton class). That way, later change is much easier and it's a very low investment in maintenance.
james_s_tayler 7y ago
I agree, but with a caveat. I think more often than not, you're right, worry about things like that just tends to be a waste of time, because while it might happen it mostly doesn't. Vendor lock-in is a good example. Probably not worth losing any sleep over. However, I definitely see value in making code easy to throw away. That's something slightly different than making something easy to swap out. Entire front-ends being re-written is something I've seen a couple of times. But when they were super-glued to the back end that was very, very expensive to do. They were hard to throw away. I think clean separation between boundaries means when you want to throw something away you can. Doesn't mean it will be easy, but a heck of a lot easier. You don't necessarily always want to replace certain things either, sometimes you just want them gone.
UK-Al05 7y ago
I find the benefits of abstracting away database, isn't so you can swap. It's that' the high-level business logic does not have any low-level unrelated persistence code in it.
nabnob 7y ago
I'm not sure that was the best example to use of an abstraction that leads to more complicated code, with database code I feel like it's way simpler to have it separate from your business logic. That way, there's fewer places where you need to make changes anytime there's a schema change. Abstracting away the database also makes it easier to write unit tests for your business logic.

Double_a_92 7y ago

> in case we need to switch out the database down the road I would still kinda consider that. But the solution wouldn't be to create some massive abstraction. Instead I'd try to separate logic from database access code. I.e. avoid reading data from the database while you are in the middle of some calculation, or in the GUI somewhere. If you need the data do it beforehand and pass it in a generic data format.

Vinnl 7y ago

It's not just programming, though. A large part of it is defining the product roadmap: code can get a lot better if a product team has the guts to unequivocally say that some features are not going to be part of the product, ever, such as running the web app in CLI. That's not just a programming decision - though I guess influencing the product roadmap could be seen as part of the art in programming as well.

downtide 7y ago
Yeah I had a manager that was quite good at throwing out functionality. Didn't like it at the time, but they were mostly right - of course they were just trying to save money.
- james_s_tayler 7y ago
  I like this. Because time after time after time I have seen the opposite. Managers saying "but we might need it again later" and... We. Never. Have. And even if we did... its still under source control if you really want to dig it out.
  - codr7 7y ago
    Second that, after 34 years in the game I'm always on the lookout for dead or dying code. Every line I can put out of its misery is one less to deal with in the future. And I find that removing dead code often unlocks further improvements that become obvious without the noise. Even if the functionality is needed down the line, it tends to require massive rewrites to catch up.

schwurb 7y ago

Of course it all depends on the application at hand, but databases and other system endpoints are something I treat as volatile. However, I don't commit to the madness of replicating a whole database interface in our codebase. Instead, I find it sufficient to bundle all database access in a single point. (i.e. by using a singleton class). That way, later change is much easier and it's a very low investment in maintenance.

james_s_tayler 7y ago

I agree, but with a caveat. I think more often than not, you're right, worry about things like that just tends to be a waste of time, because while it might happen it mostly doesn't. Vendor lock-in is a good example. Probably not worth losing any sleep over. However, I definitely see value in making code easy to throw away. That's something slightly different than making something easy to swap out. Entire front-ends being re-written is something I've seen a couple of times. But when they were super-glued to the back end that was very, very expensive to do. They were hard to throw away. I think clean separation between boundaries means when you want to throw something away you can. Doesn't mean it will be easy, but a heck of a lot easier. You don't necessarily always want to replace certain things either, sometimes you just want them gone.

UK-Al05 7y ago

I find the benefits of abstracting away database, isn't so you can swap. It's that' the high-level business logic does not have any low-level unrelated persistence code in it.

nabnob 7y ago

I'm not sure that was the best example to use of an abstraction that leads to more complicated code, with database code I feel like it's way simpler to have it separate from your business logic. That way, there's fewer places where you need to make changes anytime there's a schema change. Abstracting away the database also makes it easier to write unit tests for your business logic.