Creating software is similar to making a building but it is also somewhat different. You do need to start with a strong foundation of understanding the business rules and users of the system you are creating. This is usually captured in some graphical modeling. But once you start putting the pieces together the process should feel more like you are doing the interior design of a modular office.
Especially if more than a single developer is doing the programming, you want to leverage the concept of "loose coupling". This is a series of techniques, cautions, and an awareness that enables components to gradually change without breaking the interconnections between them.
One way to do this is to persist intermediate results to a database or file. A great advantage to this approach is that it's easy to mock up test data while you're still developing so that your work doesn't hold up anybody else. This does cause quite a bit of overhead however for high-activity classes or processes.
You can also provide loose coupling by adhering to strict standards in your object-design methodology. The types used on return values for methods and property set and gets should be strictly defined and maintained. If you need to provide more information back from a method than a simple system-type then define your own structure, but avoid using weak data types.
To maintain loose coupling you also need to avoid changing types after you have "published" them, as I described in this earlier post about maintaining modular compatibility.
