In recent weeks I have come to the conclusion that private methods can be an indicator that a class needs to be refactored. The more lines a private method contains the stronger the indicator. Please be aware that I'm not arguing against private methods or that I consider them harmful, quite the contrary. A private method which encapsulates a condition to be used in another method of the class can be really helpful when it helps to keep the same level of abstraction in this other method.

However, such little methods seldom have more than 1 to 3 lines of code. When your private method starts to have five lines of code or more it becomes an indidator that it does things which shouldn't be done in this class in the first place. It should be done in one of the collaborators the class already has (i.e., one of its dependencies), either in a public method or as part of other operations in one of these collaborators. Alternatively, if it fits into none of those existing collaborators, it could give you a hint that you need another collaborator.

In case you already have 3 or more, or it doesn't really fit into the existing ones, it might even be a sign that you have to rethink the design of your collaborators. I'll get back to that shortly, but let's talk about the implications of that on your development first. When you stumble about this problem you might be very far in the project and there's not much time left. That is the point in time where it is perfectly ok to leave it in a private method. I also don't think it's necessary to mark it with a FIXME or something similar. From my point of view a code smell is obvious here. The reason why I think it's ok to leave it as it is is that you might be on the trail to a larger refactoring which can take quite some time.

Why could it take some time? The thing is, you have found that something is wrong with your class design. You don't have a better place for the code you put into the private method, but it also shouldn't be there where it is right now. That poses an interesting question: do your classes really resemble the business domain in which they should solve a problem? Do you have a correct understanding of the business domain? From my experience, most often this is the crux of the matter. You might have missed an important keyword or part of the concept, and because you missed it there's no representation of this in your code. Turns out, that is the reason why you don't have a good place where you can fit the code from the private method.

You should take the time to think about the business domain, talk about it with a colleague, or maybe even talk to a domain expert. This will help in spotting what's missing, and it will give you the neccessary input how you need to restructure your code. Luckily, this solves two problems at once: you will get a better representation of the business domain, and you will have a place where the code from your private method fits better.

So, listen to what your code says. Even if it's a private method and it doesn't cry as loud as public methods, interfaces or APIs do: it's still worth listening.