My code was calling a certain method on a certain object. I was passing all the right parameters and the method was returning garbage. What the hell.

It turned out that I needed to call another method of the same object first.

An object that depends on its methods being called in a specific order is a bad idea. There's no language that I'm aware of that supports defining ordering dependencies for the methods of an object. If I make calls in the wrong order the compiler or runtime can't tell me I've made an error. I can't treat such an object as a black box. It's leaky. I'm forced to learn something about its internals. It defeats part of the point of encapsulation. Objects should be able to handle method calls in any order.

For the code I was writing I couldn't change the offending object. It's technical debt but it wasn't my call. The best I could do was add comments so the issue wouldn't be a hidden surprise for the next developer.

A minimal fix would have been to enforce the ordering constraint by having the method call fail if the prerequisite method hadn't been called. This is crude but effective.

Since this tactic implies keeping state in the object to track if the prerequisite method has been called, it might be nice to simply call the prerequisite if it hasn't been already. If the object has a method that is a prerequisite to a large number of other methods there would be this little bit of check code duplicated across all the dependent methods. That's a little ugly. And it's not DRY. (It's one of the reasons I don't like two stage construction.) So using object state as the principal means to solve the issue may not be the best solution.

A different approach might leverage the object design. Maybe these methods shouldn't all be on the same object. The 'prerequisite' method could be a factory method that returns an object that contains the other methods. If appropriate the factory could cache the last computed object.

In a well behaved object order dependencies among methods should be either designed out or encapsulated as an implementation detail.