“That code should be in a common library, but we're too busy right now trying to meet this deadline because of the extra 20% the customer forgot to mention when we quoted. Maybe we can do it later in the project when things are less busy and all the common code is more obvious.”
Under the pressure of deadlines, it is easy and practical to leave splitting out common code until some future time, so it rarely gets split out at all. Worse, during a project, the source tends to get more polluted with specific dependencies.
One easy way is to use Eclipse and have both the common library project and the new development project open at all times. Any changes to the common library are immediately visible in the dependent project.
You can of course commit changes back to source code control as you go, giving everyone else access to the new and improved library goodness.
Tip: At the very least you can reserve a set of packages in your codebase for common library candidates, even if they never quite make it into a separate JAR file or separate build. Keeping a separate package will logically group them and make it easy to judge and move to a common library at a later date.
