do you have a CV driven software engineer(s) in your team/squad?
if yes, how do you deal with their dramatic changes in codebase every quarter?

Yes, rewrite culture and well supported.
about every 6 months there’s some major release or certification that provides an excuse and a reason to fill up the boards with tasks that no customer asked for, but is going to reluctantly pay for anyways.

Personally I just avoid voicing my opinions as that would likely cause them to downvote my task suggestions, which is usually revolving around managing technical debt and refining ux. The former is an easy candidate to shoot down, given the value return isn’t immediately obvious to management & customers

no, since we're all in it because we are nerds who enjoy creating good software.

not some capitalist pigs who do it for the "career"

@tosensei doing it to improve and keep things safe, I’m all aboard with.

But ppl asking for like introducing graphql as a layer on top of a pre-existing json api or move existing apps to serverless because “scale”..
Or because we use React, we must adopt and rewrite to Next.js and move to Vercel instead of our own servers..

Or my favorite: “let’s rewrite it to micro services for performance and future scale”..

@lotd "microservices" - the bane of good, performant and scalable software....

the only reason ever to even think about using microservices if you have too much budget and need a way to maximise dependency hell.

@tosensei good ol’ & oh so brittle distributed monoliths. Or just a big ball of entangled mud, if you prefer. Beloved child has many names 😂

@tosensei sounds like a skill issue to me

@lungdart it's just a natural result of "introducing many many interfaces between many many different applications which all have their own versioning - if any at all".

microservices literally introduce unnecessary complications.

in that regard, it indeed is a skill issue - no skilled software architect would ever opt for microservices.

@tosensei try working at scale without microservices.

Lots of skilled devs use them because they're necessary. Lots of devs with skill issues use them because it's a fad. Lots of devs who have never seen scale believe they're never needed.

@lungdart i agree that "splitting one big scaling problem into multiple smaller ones" is one possible solution, but it's far from the only one. or the best one. and additionally, most gains in scalability are usually more than compensated with the additional overhead as well as badly defined, inflexible architecture borders.

also, this approach of "divide and conquer" is neither exclusive, nor inherently intrinsic to microservices. those are just a current fad in management, because they work on a level that management can understand easily.

@tosensei hard disagree.

There are two ways to scale. Up and out.

If you're seeing millions of requests per second, scaling up is not feasible. You need to scale horizontally by duplicating services across multiple LBs.

If you have a stateless monolith, you're paying to scale components that aren't being utilized. If you separate the concerns into individual scaling objects, you can scale each separately, saving millions of dollars.

If you can't manage multiple smaller services correctly (maintenance, build, deployment, feature ads) without breaking everything, you have a skill issue. (The big you, as in your engineering department)

@lungdart " you're paying to scale components that aren't being utilized" - if they aren't being utilised, they don't use up any compute resources. therefore, except for the very miniscule amount to keep the code in storage, i am _not_ paying for it.

also: no, the skill issue you're talking about is not in engineering, but in management. as in "stakeholder A wants to have a feature X _now_ and doesn't care if that change breaks all other microservices until they actually _do_ break. in production."

which, as of today, describes 99% of my experiences with microservices, as the engineer that spots that things are broken in production.

@tosensei I don't know what to tell you. You must be right since you've never seen it work, vs myself who has done this successfully at scale with reduced costs.

It's impossible. Take the win.

I’m starting to hear about test driven development.
How does CV driven software engineering work? Does it have something to do with csv files?