This is about thew new starter cost.

When a developer joins a team, they will not be as productive as they have to learn the code, frameworks, libraries, the project purpose, the tooling, etc.. Often this impacts other members of the team lowering the entire teams productivity.

When you use productivity tracking (e.g. things like capacity planning) you will see the teams performance drop and it will take time for it to exceed the previous measured performance. This is the cost of adding a new starter.

So if it takes 6 weeks for a new starter to increase overall team producitivty then planning someone on a project for 4 weeks is pointless since the team will have a higher delivery rate without the extra person. This is typically why an organsation loses its ability to migrate staff between projects.

Code formating affects the layout of the code and our brains do all sorts of tricks around pattern recognition, so if your code formatting rules are too different a someone migrating between projects has to spend time looking for code and retraining their brain.

Its an additional barrier and a one within an organisations skills to remove (by forcing a common code standard).

Wikipedia lists all 12 subs as having Rolls Royce Pressured Water Reactors.

Your PWR reuse idea is is kind of where Rolls Royce is looking to go with Small Modular Reactors (https://www.rolls-royce.com/innovation/small-modular-reactors.aspx).

I suspect refurbishing decades old PWR reactors would be far more expensive than just building new ones, for example a SpaceX Merlin engine costs $1 million and a Blue Origin BE-4 costs $15 million. Nasa argued it would be 'cheaper' to reuse Shuttle components for the Space Launch System (SLS). Refurbishing Shuttle RS-25 engines has cost Nasa $50 million dollars per engine, restarting a production line is costing $100 million for each new RS-25 engine.

Maven has unit and integration test phases and there are a multitude of plugins designed to hook into those phases but there are constraints by design.

Trying to hook everything into the build management system is a source of technical debt, your using a tool for something it wasn't designed.

I would look at what makes sense within the build management system and what makes sense in a CI pipeline.

CI tools have different DSL and usually provide a means to manage environments. Certain integration and system level tests are best performed there.

For instance I keep system tests as a seperate managed project. The project can be executed from developer machines for local builds but I also create a small build pipeline to build the project, deploy it and run the system tests against it triggered by pull requests.

This is why I say the build management system doesn't really change, because you should treat everything as descrete standalone components.

The Parent POM gets updates once every six months, the basic build verification CI pipeline only changes to the latest language release, etc..

Projects which try to embed gitflow into a pom or integrate CD into the gradle file are the unbuildable messes I get asked to fix.

The admins to perform upgrades, monitoring, fixes, etc.. will require root access to the database. That means they can alter all your posts to say *blah blah blah" if they wanted.

Similarly passwords will be encrypted within the database and encryption algorithms have to be able to go in both directions. Normally they need a seed value to start random generation. The admin defines the seed as a result an admin can decrypt everything in the database.

@ergoplato I didn't suggest that.

Personally I don't think its ego. I think you have two issues.

The first is people go through stages learning DevOps. Stage 1 has people deploy a CI because its cool, they build a few basic pipelines and then 90% of people get bored. The 2nd stage is people start extending those pipelines, it results in really complex pipelines requiring lots of unique changes based on the opinion of the writer. You move to the 3rd stage when your asked to recreate/extend for a new project and realise how specific your solutions are.

Learning how to make minor tweaks and hook in a few key points to get what you want takes years. Without that most packagers will want to make big changes upstream which won't go down well.

The second issue, I have met quite a few developers who become highly stressed when the build system is doing something they haven't needed to do or understand.

A really simple example I have a Jenkins function which I tend to slip into release pipelines, it captures the release version and creates a version in Jira.

I normally deploy it first as a test before a few other functions to automate various service management requirements.

Its surprising how many devs will suddenly decide every problem (test failed, code failed review, sharepoint breaks, bad os update, etc..) is due to that function.

For me this little function is a test, if the team don't care I will work to integrate various bits. If they freak out, I'll revert decide if it is worth walking them through the process or walk away.

What a difference, thank you!

Its a responsive designed website, why do you need an Application?

It isn't surprising.

I tried to replace my gas boiler in 2020 (it failed), I reached out to 8 companies to get an estimate for a ground or air sourced heat pump. 5 didn't pickup/return emails. 2 told me they don't do residential.

The last qouted £21k plus installation costs, then told me if I had a gas boiler that would be cheaper to maintain/run.

I have just met someone to qoute for air conditioning, they told me you can use it for heating. The initial estimate is the same as a gas boiler.

Github stars is not a good metric, firstly because KBin is hosted on codeberg but mainly because a healthy project has lots of unique contributors and regular updates/enhancements.

KBin has 79 open Pull Requests, while Lemmy has 29. From a visual check PR's seem to be older than 2 weeks. Its hard to say one is "healthier" than the other, without scraping information into a spreadsheet.

Secondly Rust is new and has a lot of hype surrounding it, as a result you get a lot of people using it on random projects.

Languages have strengths and weaknesses and developer ecosystems build on the strengths.

For example if I was writing a web application with a database backend I would choose C#, Java or Node.js because there are loads of libraries, tools and frameworks to make it really easy.

Rust is gaining a lot of adoption by embedded system users (replacing C mostly). Lemmy is the only Rust based web server project I am aware of. Which means the level of work to do anything and to keep it updated falls on the Lemmy devs rather than spread out amongst a larger community.

Everyone loves to insult PHP but it has a niche in webservers and won't disappear anytime soon. KBin effort will thus be spent on KBin.

Stable.

Its work, I don't care about the latest drivers or application releases. Just security updates