Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Forcing Functions in Software Development

coderefinery.wordpress.com

Post reply on HN
Print view View original

11–20 of 52 posts

Re: Forcing Functions in Software Development

#11

Post by dkersten »

inopinatus wrote: post #7
stingraycharles wrote: post #6

Earlier quoted context omitted.

Yeah I don’t get that obsession with “pluggable databases”. Abstractions have a real cost, and they typically complicate a lot: I would advice to just make sure you centralize the access to your database in a single module / class / whatever, but other than that, swapping out databases seems like a non-goal to me. How often do people really migrate to a different database? Even when doing so, migrating the existing d…

It's more a concern when shipping library/platform code. Applications can be as tightly coupled as they like.

Should library code really be relying on a database? If its a database library, then ok, maybe it can stick to a subset of database features that works across all supported databases, but in that case, testing against these databases is no longer a "Forcing Function", but a core part of the libraries test suite to ensure correctness.

The same goes for platform code, really. If you are advertising your platform to work with databases X, Y and Z, then you really need to be testing against those and not just as a Forcing Function to see if any brittleness crept in, but as a core part of ensuring your platform does as advertised.

Re: Forcing Functions in Software Development

#12

Post by pydry »

stingraycharles wrote: post #6
dkersten wrote: post #2

> Try to add support for a completely different database. Details of your current database that have leaked into your data layer abstractions will soon become obvious Well, details of Postgres have leaked into my database queries and schemas, but it was a conscious decision to use Postgres and its features. Sure, it seems nice to be able to swap one database for another, but you lose out on a lot of what a database c…

Yeah I don’t get that obsession with “pluggable databases”. Abstractions have a real cost, and they typically complicate a lot: I would advice to just make sure you centralize the access to your database in a single module / class / whatever, but other than that, swapping out databases seems like a non-goal to me. How often do people really migrate to a different database? Even when doing so, migrating the existing d…

I've been considering moving away from azure postgres to azure SQL server coz azure postgres runs at a snails pace.

Re: Forcing Functions in Software Development

#13

Post by swyx »

auggierose wrote: post #5
xupybd wrote: post #3

Who has time for this? I've always been on under resourced projects where every hour had to be signed off. Everything is a rush and quality is required but never budgeted for.

Time to change jobs then.

HN resorts to the "just quit your job lol" far too easily. people are in all sorts of different situations. you don't know if they are struggling to find work and this is the one shot they have been given. you don't know if they are in extreme demand and get paid well to fix bad situations like this. you just don't know. and telling people to blithely change jobs when they can't or don't want to isn't helpful

Re: Forcing Functions in Software Development

#14

Post by [deleted] »

MaxBarraclough wrote: post #10
dkersten wrote: post #2

> Try to add support for a completely different database. Details of your current database that have leaked into your data layer abstractions will soon become obvious Well, details of Postgres have leaked into my database queries and schemas, but it was a conscious decision to use Postgres and its features. Sure, it seems nice to be able to swap one database for another, but you lose out on a lot of what a database c…

Agreed. It makes little sense to try to write your SQL queries to run fine on multiple different DBMSs. Different SQL DBMSs should be treated as different languages. Presumably the idea is based on an analogy to code portability: it can be good to ensure your C++ code compiles fine with multiple different compilers. Really though, it's more akin to writing code that compiles as both C# and Java; clearly madness.

[deleted]

Re: Forcing Functions in Software Development

#15

Post by speedgoose »

pydry wrote: post #12
stingraycharles wrote: post #6

Earlier quoted context omitted.

Yeah I don’t get that obsession with “pluggable databases”. Abstractions have a real cost, and they typically complicate a lot: I would advice to just make sure you centralize the access to your database in a single module / class / whatever, but other than that, swapping out databases seems like a non-goal to me. How often do people really migrate to a different database? Even when doing so, migrating the existing d…

I've been considering moving away from azure postgres to azure SQL server coz azure postgres runs at a snails pace.

Azure is ridiculously slow unless you ask for decent IOs performance but then it's ridiculously expensive.

Re: Forcing Functions in Software Development

#16

Post by mjburgess »

swyx wrote: post #13
auggierose wrote: post #5

Earlier quoted context omitted.

Time to change jobs then.

HN resorts to the "just quit your job lol" far too easily. people are in all sorts of different situations. you don't know if they are struggling to find work and this is the one shot they have been given. you don't know if they are in extreme demand and get paid well to fix bad situations like this. you just don't know. and telling people to blithely change jobs when they can't or don't want to isn't helpful

Indeed, I encounter this anti-pragmatic personality a lot in tech people.

It's an extreme intolerance to imperfect circumstances: a preference for nothing at all over compromise.

The issue is that tech attracts the mathemetically-minded who reasons from universal principles. Rather than the empirically-minded who start with cases, and abduce to provisional principles from those.

To a aximoatic mind: when a universal principle is violated, the situation is declared Bad.

To the case-base mind: when a tolerable situation seems to violate a principle, declare the principle Inapplicable.

Of course both types of thought are helpful in different contexts, I suspect 'the management of one's life, day to day' however, should be a matter of case-base reasoning to rough principle.

Re: Forcing Functions in Software Development

#17

Post by vagrantJin »

At an agency, we used to run our web apps on some crappy 08 model laptops running on a gig of memory with outdated browsers. If the webapp ran there without major hitches, it was considerd good enough. It made everyone on the team think hard about optimizing even before a single line of code was written. It really did force excessive simplicity and not jumping on new libs/frameworks just because we can.

Re: Forcing Functions in Software Development

#18

Post by Kiro »

dkersten wrote: post #9
stingraycharles wrote: post #6

Earlier quoted context omitted.

Yeah I don’t get that obsession with “pluggable databases”. Abstractions have a real cost, and they typically complicate a lot: I would advice to just make sure you centralize the access to your database in a single module / class / whatever, but other than that, swapping out databases seems like a non-goal to me. How often do people really migrate to a different database? Even when doing so, migrating the existing d…

> How often do people really migrate to a different database? Well, I have been part of a migration from MySQL to MariaDB, which was a lot more effort than one would expect given that they're meant to be more or less the same thing. It was a ton of effort and the abstracted ORM logic didn't actually help with this. So if it doesn't really help that much for a simple case like that, then it doesn't seem like there's m…

I've done the same migration and I'm curious of what issues you had. For me, it was truly just plug'n'play with no additional work whatsoever.

Re: Forcing Functions in Software Development

#19

Post by barrkel »

dkersten wrote: post #2

> Try to add support for a completely different database. Details of your current database that have leaked into your data layer abstractions will soon become obvious Well, details of Postgres have leaked into my database queries and schemas, but it was a conscious decision to use Postgres and its features. Sure, it seems nice to be able to swap one database for another, but you lose out on a lot of what a database c…

I don't significantly disagree with you, but let me take the devil's advocate approach.

Adding support for a different database doesn't mean restricting yourself to the lowest common denominator. It means using different techniques, more appropriate for the different database, that may optimize other parts of your data access and modification path, while pessimizing stuff your current database does.

More importantly, it means extracting hard database dependencies like raw SQL or custom ORM fiddling from your business logic and entities, and pushing them behind a module or service boundary.

Raw leverage of the database, if it's dispersed throughout your application, will limit your ability to change your schema (e.g. denormalize an attribute, split or join tables, convert a parent-child relationship to embedded JSON or vice versa) and address performance problems as you scale up. It'll also stop you having a single point of data access where you can partition or duplicate your data into different stores with different capabilities more suited to their access and modification patterns. These kinds of things become really important when the database becomes a bottleneck in your system.

Re: Forcing Functions in Software Development

#20

Post by LandR »

dkersten wrote: post #2

> Try to add support for a completely different database. Details of your current database that have leaked into your data layer abstractions will soon become obvious Well, details of Postgres have leaked into my database queries and schemas, but it was a conscious decision to use Postgres and its features. Sure, it seems nice to be able to swap one database for another, but you lose out on a lot of what a database c…

I took this to mean be able to swap in and out your persistence layer.

So my app can make calls which will persist data to a SQL database, or I can swap that layer out with another that persists to NoSql storage in the cloud. Possible because the persistence layer exposes an API or interface that is agnostic to the actual implementation of the layer

???

Post reply on HN