In AI search algorithms, one of the biggest challenges is creating an algorithm that reduces the amount of time spent searching. Search algorithms are navigating a search space that is too large for brute force search (...else we wouldn't need the AI). By nature, in order to accomplish this, we must search only a fraction of the space. The reciprocating challenge to that of course is to search the right fraction so as not to miss an optimal solution. Most of these search spaces are multi-dimensional. That is, they have more than one variable that must be tweaked, often a multitude of them, the combination of which creates an output. In a constraint satisfaction problem (CSP), this output must meet specific requirements in order to be a satisfactory solution. For a CSP, one of the most common techniques in reducing the search time is to search the most constraining variables first, called appropriately the "most constraining variable first" heuristic. (If only all names were that self-explanatory...)
As a software developer, what I find is that that same heuristic can be applied directly to engineering software, particularly in the case where it is difficult to foresee the correct engineering solution. I'm experiencing this now while building (with a recursive irony) an AI. And we're not even talking a Max Headroom AI. Just a search problem that requires more than, well, non-AI (though there's that annoying philosophical question of where to draw the line between the two...). When designing and coding a solution, there are some engineering needs that are easy to foresee, and consequently it is easy to design a solution immediately that will not need much alteration in the future. But in complex cases as we're discussing here, there are also those needs that are practically impossible to foresee until you start solving it. Often even a typical engineering problem can feel this way. In those cases you find yourself molding, refactoring, sometimes even rewriting the solution as you work through it. Partway into it, you realize a new constraint you did not see before, which requires some rethinking and rework.
Now suppose you also solve the easy solutions along with these, as we might do by default. Sometimes the new realizations will require not only a change in the complex solutions, but also the changes break the expectations of the easy components. You end up building a roof on a house whose floor plan is being reconsidered. Just wait for the floor plan to solidify. Now we start to see that ideally we first solidify the solutions that are most difficulty to foresee, then create and integrate with the simple problems. This might also relate to the good managing principle of mitigating scheduling risk by addressing the biggest unknowns first. But I think the "most constraining variables first" heuristic applies even better. It's not that we don't end up finding the solution without it. We do. Eventually. But we can limit the search to a smaller fraction of the space by applying it.