Nice article, Jos! It's a rational perspective to ask the question about how much quality you want to pay for. I also liked the 3NF comment. :-) Keep em coming!
Oh, and Google is certainly not “the Germany of [software] engineering”, nor was it ever. I still feel bound by my moral NDA, so I won't discuss the specifics; but as a seasoned developer on the day I joined, I found that the only thing Google excels at, is performance (QPS). For everything else, we were somewhere between “mediocre“ and “good enough” — which I guess is on-topic for the discussion at hand.
It's quite amazing to me how much folks feel they need to avoid "vendor lock-in" or "database lock-in". YAGNI never seems to apply. However, since I started worrying less about these things and just apply the right patterns where they are truly needed, I personally feel I've been much better off. "Oh no! Your repository pattern bleeds the database transaction detail!" Correct, because I don't see a world where we aren't actually going to have a transactional rdbms under us in the next 5 years and bleeding that transaction means we can compose those repositories instead of push the details down.
Nice article, Jos! It's a rational perspective to ask the question about how much quality you want to pay for. I also liked the 3NF comment. :-) Keep em coming!
Oh, and Google is certainly not “the Germany of [software] engineering”, nor was it ever. I still feel bound by my moral NDA, so I won't discuss the specifics; but as a seasoned developer on the day I joined, I found that the only thing Google excels at, is performance (QPS). For everything else, we were somewhere between “mediocre“ and “good enough” — which I guess is on-topic for the discussion at hand.
You absolutely do want an ORM. You need a good one, though. (That rules out all the ones written in Python, I'm afraid)
Related: could you please write an essay about abstraction, its need and its excesses? I shall come back and comment on that 😈
Here's a 8 min audio version of "Quality is fitness for use" from Wednesday Wisdom converted using recast app.
https://app.letsrecast.ai/r/e2a46ae1-8796-4983-b507-c701e1819be7
It's quite amazing to me how much folks feel they need to avoid "vendor lock-in" or "database lock-in". YAGNI never seems to apply. However, since I started worrying less about these things and just apply the right patterns where they are truly needed, I personally feel I've been much better off. "Oh no! Your repository pattern bleeds the database transaction detail!" Correct, because I don't see a world where we aren't actually going to have a transactional rdbms under us in the next 5 years and bleeding that transaction means we can compose those repositories instead of push the details down.