>For example, A/B testing, anomaly detection and merge queues. A/B testing is arguable a product based thing. It can be called "engineering" but it's not stric

>For example, A/B testing, anomaly detection and merge queues. A/B testing is arguable a product based thing. It can be called "engineering" but it's not strictly a software thing. It's associated more with UI. I've never seen anomaly detection used with software development. Looks more like a data ML thing. Merge Queues are just a collaborative tool. I mean you can use this on any document outside of software engineering. Say, for example, CAD drawings where a bunch of people work collaboratively. I don't think your examples are focused enough to be strictly things that are part of "Software Engineering" in the same way agile isn't strictly "Software Engineering." >Software processes are designed with mathematical/statistical backing when needed. This is rarely done. Very little statistical methods make it into the dev process or are even influenced by the dev process. When it does make it in there's no common methodology either as it's usually just some data driven behavioral changes based off of some analytics. The reasoning behind why it's like this is clear. At it's core software is deterministic. Code is simply a series axioms and theorems that can be logically proven correct. Statistics is for unknown processes and is usually employed at the intersection of software and real world stuff like the failure rate of ssd drives. A passing unit test does give more confidence that a program is correct. This is a statistical phenomenon, but hardly anyone tries to actualize it from a statistical quantitative standpoint. >does it work and is it cheap? In software, both of these are usually non-issues so things can vary a lot more. I disagree. These are issues and we do use methods to mitigate these things. We want our software to work and we want to build it at a certain cost. Agile and measuring velocity is a way to monitor costs and working software is verified through mostly testing. But most of this stuff isn't engineering. It's done out of necessity. There's no mathematical modelling going on as it's hard to even quantify the costs of software or even correctness. Hence why it's all arbitrary processes made up by managers. >I suspect you will call this arbitrary, but I see these process decisions as conscious choices. The fact these aren't grounded in mathematics or statistics is not a big deal to me because the goals/focus are more complex than does it work and how much does it cost. All decisions made in any field even say plumbing is a conscious choice. The difference is in engineering we use science and mathematics as much as possible to optimize these choices. We don't in software. Mainly because it's hard to model it. >In software everything is a tradeoff rather than having an absolute answer. Everything in life is a tradeoff. It's like this in fields OUTSIDE of engineering as well. The thing with engineering is you try to optimize your choice using math and science as much as possible. In software no such optimization procedure exists.