Forcing Functions in Software Development
coderefinery.wordpress.com
Forcing Functions in Software Development
1–10 of 52 posts
Re: Forcing Functions in Software Development
#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 can do if you stick strictly for the lowest common denominator of features. I use Postgres partly because of its feature set, so I am going to use these features. This does mean that its unlikely I will ever run my software against a different SQL database, but I'm ok with this.
I guess an important note is that you should be aware of it and it should be a conscious decision, rather than something that crept in over time.
But I suppose that's a tangent and not the articles point. Forcing Functions is about unearthing the brittleness that has crept into a codebase over time and I absolutely agree that is a helpful and worthwhile exercise. I've seen plenty of codebases that were meant to be database agnostic, but porting them was still not painless.
Re: Forcing Functions in Software Development
#3Who 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.
Re: Forcing Functions in Software Development
#4> Delete the project from your development machine, clone the source code and set it up from scratch.
Very good advice. This was obviously never done in my org, leading to newcomers (me included) wasting weeks to get started on some projects. Once it was fixed, a newcomer can start working in an hour.
Re: Forcing Functions in Software Development
#5Who 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.
Re: Forcing Functions in Software Development
#6> 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 data always is a lot more tedious than migrating the code, in my experience.
Re: Forcing Functions in Software Development
#7> 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…
It's more a concern when shipping library/platform code. Applications can be as tightly coupled as they like.
Re: Forcing Functions in Software Development
#8> Delete the project from your development machine, clone the source code and set it up from scratch. Very good advice. This was obviously never done in my org, leading to newcomers (me included) wasting weeks to get started on some projects. Once it was fixed, a newcomer can start working in an hour.
actually having a newcomer install everything and fix the documentation while doing it is even a better option, cloning has some of the dependencies but other might have been installed by the developer for example global packages for NPM or Python, setting of system wide environment variables etc.
Re: Forcing Functions in Software Development
#9> 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…
> 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 much point in my opinion, as porting is going to be work either way (in a non-trivial application with non-trivial data access patterns, at least).
Re: Forcing Functions in Software Development
#10> 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.