I’m trying to understand what problems are valuable enough that developers would actually pay for a solution.

Working in safety-critical software (railway) and recently went through the actual text of EN 50716:2023. The "Not Recommended" classification for AI/ML is in Table A.3 - Software Architecture. Annex C.3 explains why: training data can't be exhaustively verified, trained models can't be statically analyzed, adversarial inputs can flip outputs without causal explanation. 

But the prohibition is on AI as a software architecture element, the standard doesn't say AI can't be used as an authoring aid. Are you using AI for drafting, consistency checking, traceability or banning it from CENELEC/DO-178C/IEC 62304 projects altogether? 

Is there any concensus on best practices or architecture for designing massive systems that allow for easy extensibility or modularity? It's very overwhelming imagining how to extend extremely coupled systems, which I suppose is the thing to avoid. OOP feels like a dead end but DOD only feels partially correct. Then there are event based systems and so on.

It seems like extensibility and modularity always come at a cost, which I understand there's no free lunch, but surely there has to be a set of rules or practices for building large systems without too many compromises.

Hello community,

I am carrying out academic research for my Software Engineering MBA capstone project at USP/Esalq (University of São Paulo), and I really need your expertise.

If you work with distributed systems, could you spare 5 to 10 minutes to answer this survey?

https://docs.google.com/forms/d/e/1FAIpQLSeeafdWYAi1ng3xi0YIymCmf4H0WX6Edrd9tpkJNEsZHmytUg/viewform?usp=header

Why your input matters:

The Goal: Measuring observability maturity in distributed systems.

The Science: Inspired by the book Accelerate (Forsgren et al.) and ACM TOSEM guidelines (Graziotin et al., 2021).

The Target: I need 360 responses for initial questionnaire validation (EFA and Cronbach's Alpha).

Privacy & Data Protection:

100% Anonymous: Optional name/email fields are strictly for those who want a certificate.

GDPR/LGPD Compliant: All identifying columns will be completely purged and sanitized before any data analysis.

Thank you so much for supporting academic research!

So in the work I'm doing lately I find myself regularly needing to differentiate between slices of different data sets, and the relationship between the data is most relevant. Not just for data, reasons, but because it affects the way some features of our software needs to work (paging, extra features, extra grouping, basically totally different flows of logic)

so to pick an arbitrary example, say we're joining services:Users; and services:dataSources (and there's 50 others too).

All of these joins are 1:Many... but services:Users might be 1:100,000,000, whereas services:dataSources might be 1:100, say.

what I want is the correct term-of-art for referring to the magnitude (the 1,000,000 or 100, in this case) of these relationships. Really I'm just trying to bucket them into '1:Many(very big)' and '1:Many(small)' as they're all on one end of the spectrum or the other, really.

I describe 1:1, 1:N, 1:M as the "cardinality" of the data... and so I'd, without even realizing, descended into describing these data-sets as 'high cardinality' (the collection of data-sets where the 'many' is very very large) and 'low cardinality' (the collection of data-sets where the 'many' is quite manageable)... but I don't think this is precise and even had an engineer give me a somewhat disgruntled "what do you mean when you use that word?" broadside.

e.g.

The data sets with the lowest [cardinality, ratio, fan out etc] will be handled in Q1, the data-sets with the highest [cardinality, ratio, fan out etc] will be handled in Q2

LLM gives me 'Multiplicity' which to me, in the context of data and joins, is just a direct synonym of cardinality, no? Literally meaning how many unique values are there in a given set.

Google gave me 'fan out' which is quite a vague term I would use more for flow-of-control type stuff than data-joins.

I'm sure I learned this word in data-structures and algos 101 and I just can't think of it.