We follow this rule (about two dozen services with in total ~100k loc of Python):
By default, use the version 1 release below the latest.
I.e. we currently run 3.11 and will now schedule work to upgrade to 3.12, which is expected to be more or less trivial for most services.
The rationale is that some of the (direct and transitive) dependencies will take a while to be compatible with the latest release. And waiting roughly a year is both fast enough to not get too much behind, and slow enough to expect that most dependencies have caught up with the latest release.
I'm maintaining an internal change-data-capture application that uses a python library to decode mysql binlog and store the change records as json in the data lake (like Debezium). For our most busiest databases a single Cpython process couldn't process the amount of incoming changes in real time (thousands of events per second). It's not something that can be easily parallelized, as the bulk of the work is happening in the binlog decoding library (https://github.com/julien-duponchelle/python-mysql-replicati...).
So we've made it configurable to run some instances with Pypy - which was able to work through the data in realtime, i.e. without generating a lag in the data stream. The downside of using pypy was increased memory usage (4-8x) - which isn't really a problem. An actually problem that I didn't really track down was that the test suite (running pytest) was taking 2-3 times longer with Pypy than with CPython.
A few months ago I upgraded the system to run with CPython 3.11 and the performance improvements of 10-20% that come with that version now actually allowed us to drop Pypy and only run CPython. Which is more convenient and makes the deployment and configuration less complex.
If it's domain logic, like calculating the total for a shopping cart then you gotta follow DRY. The risk of application inconsistencies are too high. But if it's anything else then I go with KISS.
I really think DRY is far more important for business logic than it is for infrastructure logic. If you calculate what taxes someone owes in two different ways that's terrible. If you serialize two different things in your application in two different ways, probably doesn't matter.
The thing about DRY is it's not just "don't repeat this code," it's "don't repeat this code that has the same execution assumptions and maintenance expectations." You can make those assumptions broader with parameterization, injection, etc., but there's a limit before you either make it too complex to reason through or end up pulling in diverse maintenance expectations.
In my own niche, software test automation, this can be a huge problem because the meat of every test stands alone from all other tests, otherwise it wouldn't be a unique and interesting test. Applying DRY naively in that kind of situation often leads to a bunch of non-cohesive "do everything but this, and based on this flag do this one different thing" type code.
You really have to jump back a level and look at things more in context of their usage. This is one of the reasons that there's debate about even sharing things like setup methods, never mind test bodies.
Sounds like the evolution of different flows described has a lot in common with this. You have to look past the lexical.
Usually there's some sort of engineering manager / lead engineer who's in charge of deciding how the product is built from a technical point of view. He's the main collaborator of the product manager/owner and they need to get along well.
Thanks for the writeup - very helpful. It's always good to get a view of how others are solving the same problems oneself has.
That said, the article does come off a bit as trying to be authoritative, but at the same time it doesn't leave enough room for possibilities where alternative approaches may have merit as well (i.e. "this is how to do it" vs. "what worked well for us, ymmv").
Newbies that read this article will think that the principles described are the canonical way and even try and apply them in scenarios where alternatives may prove superior.
We're looking for a skilled frontend developer who will help maintain and extend our angular.js application with focus on maintainability and performance. Bonus points if you're not afraid of touching backend code, too (Python for us).
Backend Developer - Help developing our backend services and daemons (mostly Django and Tornado), work with many Terabytes of data in PostgreSQL.
Python Infrastructure Developer - Your job is to continue automating our development and operations processes. You help built and maintain the tools to develop, deploy and run our applications on AWS.
Javascript/Frontend Developer - You help maintain and extend our frontend application (AngularJS, React) and are not afraid to venture into touching the backend code as well!
Python Infrastructure Developer - Your job is to continue automating our development and operations processes. You help built and maintain the tools to develop, deploy and run our applications on AWS.
Javascript/Frontend Developer - You help maintain and extend our frontend application (AngularJS) and are not afraid to venture into touching the backend code as well!
Backend Developer - Help developing our backend services and daemons (mostly Django and Tornado), work with many Terabytes of data in PostgreSQL.
Python Infrastructure Developer - Your job is to continue automating our development and operations processes. You help built and maintain the tools to develop, deploy and run our applications on AWS.
Javascript/Frontend Developer - You help maintain and extend our AngularJS application and are not afraid to venture into touching the backend code as well!
Backend Developer - Help developing our backend services and daemons (mostly Django and Tornado), work with many Terabytes of data in PostgreSQL.
Python Infrastructure Developer - Your job is to continue automating our development and operations processes. You help built and maintain the tools to develop, deploy and run our applications on AWS.
Javascript/Frontend Developer - You help maintain and extend our AngularJS application and are not afraid to venture into touching the backend code as well!
I.e. we currently run 3.11 and will now schedule work to upgrade to 3.12, which is expected to be more or less trivial for most services.
The rationale is that some of the (direct and transitive) dependencies will take a while to be compatible with the latest release. And waiting roughly a year is both fast enough to not get too much behind, and slow enough to expect that most dependencies have caught up with the latest release.