In Software Development, if you have a problem to solve, you break it down into smaller, easier-to-solve problems.

Does this always hold true? I imagine there are situations where you can't do this. I would need to see different perspectives.

In general yes - kind of.

It's fine, just make sure you don't reach the quark stage then you'll have bigger problems

The obvious situation where it doesn't hold true is a small problem.

But I'd also say it doesn't hold true when a rethink, rearchitect, is needed. There have been times when I just needed to rip everything out and start from scratch. Sure, then *that* can be broken down, but the base idea of what it should be replaced with isn't something that can be done piecemeal.

You definitely need to understand the problems that are trying to be solved in order to effectively build the tool to solve the problem.

I have long since ceased being challenged by implementing things, it's the part where I have to understand what the client wants that gets me now.

I was taught in school that unless you understand the input and output stages, there's no way you can build the processing stage.

There is a whole subject named "approximation algorithms" that deals with this exact question.
Because those big fancy NP-Hard problems can not be efficiently solved by divide-and-conquer... optimally.
That is to say, you can get a "pretty close result" using some method that is not guaranteed to find the best of the best results, often by breaking the problem into subproblems.
How "close" is that result? Approximation algorithms theory answers that question as: "within log(N)/4 of the best possible result for N" or something like this.

Ex: find the *longest* path in a graph, without any cycles in the path (in other words, find the diameter of a given geaph)

So, yes, in practice, we often can break any problem into subproblems. But if we ever find yourself into a discussion with a complexity theory nerd... be careful, always put the "in practice" caveat in your comments.

breaking things down into smaller problems has always been weird advice to me. it's basically saying nothing? like wow to get a cup of water you get up and walk and stretch out your hand and grasp around the cup and then pull the cup towards you. I think you realize what the steps are when you mention the action

now what actions do you need? that's the real question

I need to understand the whole system, then I find re-occurring patterns and put those into components. breaking down into "smaller" pieces has always been odd advice to me. I bet lots of people just get stuck doing it. you'll have end-tools but you won't be able to glue them together. you're not really making something when you break something down into smaller pieces, you're just destroying kind of neurotically... you're going down the stack, instead of up the stack

but hey I don't know. just always been my problem with it when people mention that. I'm not an expert on their way of life, but how it looks to me

@JsonBoa and don't let a chemical engineer who doesn't understand effective resolution decide qualification parameters.

@Demolishun chemical engineers are effective, cheap, and easily available. They are the good-at-math kids whose mothers reeealy wanted them to be doctors and didn't let them play with computers.
That being said, ok, they are a bit... analog when evaluating exact solutions. They need a more... through review.

@JsonBoa they have way more decimal points in their values than any sane person should have.