Another classic example is data scientists trying to model biological processes (or answer questions about processes while ignorant of which components regulate others). Systems biology has a long history of largely clueless attempts to predict outcomes from complex processes that no one understands well enough to model usefully. The biologists know this but the data scientists do not.

It's much worse than that. If you dare to ask that a team speak with the problem owners - mechanics, managers, etc, you will get booted right quick.

Since the 2010's data science has gone from scientific based curiosity in solving problems to pure technicians work. There's a set of algorithms they follow, no exceptions allowed. Kaggle is a horrible anti-pattern.

NB: I am a data scientist.

huh. I'm a professional data scientist, and my masters was in signal processing. In one class the final exam required us to transcribe fourier transforms of speech into the actual words. In another the final exam required us to perform 2d FFTs in our head.

Please be careful about generalizing.

I agree that many 'data science' programs don't teach these skills, and you certainly have evidence behind your assertation.

Yet I suspect that mechanical engineers are not writing software for companies in the large. There are software developers doing so.

I suspect that they should be consulted by data science folks as domain experts.

That said won’t AI replace both? ;)

i confess, i've read both of your comments on this - your analogy and a deeper explanation of the analogy - and i still have no idea what you are saying. i'm not stupid. so first, my feedback here is, it sounds like you are an educator or in an education-adjacent role, and you should focus on making more sense haha. like lay out your beefs clearly, it sounds like you have a beef with interdisciplinary work, specifically between some STEM departments and especially with humanities and STEM departments, which is subjective. you don't have to be objective about everything. you can just say, "i don't like this design thinking thing because i don't like the people involved" or whatever. but i don't know! i cannot figure out what you are saying.

it sounds like your point is: "some ways of solving problems are superior to others." i've heard this take a million times. one perspective i'll offer to you is, math is not the only way to solve problems. it's not even the best way in many cases. not everything can be solved by defining a narrow goal, and then having a dispute about the methods, and then picking some objective method and then applying it very optimally, or whatever. this is also on you, as an educator, to understand! i could give a bajillion specific examples.

but first, you have to concede: an analogy nobody understands is bad, and you have to own that, and two, it's not really clear, what exactly is your dispute with Design Thinking? it doesn't have anything to do with user interfaces... so why the hell are you talking about it? why "Design Thinking people"? What is your beef here?

Traditionally you use a lot of paper and experiential prototypes to iterate on, which doesn't cover everything but helps refine assumptions (I sometimes like starting with mocking downstream output like reports and report data, which is a quick way to test specific assumptions about the client's operations and strategic goals, which then can affect the detailed project). When I can, I also try to iterate using scenario-based wargaming, especially for complex processes with a lot of handoffs and edge cases; it lets us "chaos monkey" situations and stress-test our assumptions.

More than once early iterations have led me to call off a project and tell the client that they'd be wasting their money with us; these were problems that either could be solved more effectively internally (with process, education, or cultural changes), weren't going to be effectively addressed by the proposed project, or, quite often, because what they wanted was not what they actually needed.

Increasingly, AI technical/functional prototyping's making it into the early design process where traditionally we'd be doing clickable prototypes, letting us get cheap working prototypes in place for users to test drive and provide feedback on. I like to iterate aggressively on the data schema up front, so this fits in well with my bias towards getting the database and query models largely created during the design effort based on domain research and collaboration.

I’d retort that software developers aren’t domain experts either. At the end of the day you either luck out if domain experts and actual users are involved in eliminating toil (in the sense that Google defines that) and optimizing the user experience, while reducing friction in applications and providing insights into data.