Software is such simple stuff. A little bit of code, and you can make the machine do amazing things. Calling other little bits of code, and you can multiply the power by the power of that other code. You can also exponentially increase the complexity, in doing so.

Every time you call other code, or use objects or data structures defined by other code as parameters, you create a dependency on that other code. If you're not careful, you'll end up with a tangled mass of dependencies that will slow you down, at best, or tempt you to throw away your code and start over.

Think about the granularity of your code. Break it up into understandable chunks. Just because two things happen to be done at the same time by the code, that's no justification for lumping them into the same piece of code. (Temporal Coupling is an anti-pattern.) If they represent different things, keep them separate. (See Robert C. Martin's [http://www.objectmentor.com/resources/articles/srp Single Responsibility Principle] pdf.) Break them into separate modules, both called by a higher-level module that represents the process requiring them both to be done.

Remember, the major organizing rule of all software development is to maximize cohesiveness and minimize coupling.

Resources:

• Object Mentor's [http://www.objectmentor.com/resources/publishedArticles.html articles] on Design Principles (and particularly the [http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf Principles and Patterns] paper by Uncle Bob).

• [http://www.regdeveloper.co.uk/2006/06/27/getting_together_time/ Building cohesion into programming] by Kevlin Henney.