• Members of different teams often follow a rigid "start [this] only after [that] has been completed" development path that isn't necessary.

    For example, when developing the data model and stored procedures for a new database, I'll shortly provide the application developers with prototype stored procedure calls that have input/output parameters and mockup resultsets that closely match what the final version will have. Of course, this works much better when the app developers are only making procedure calls and don't have direct access to tables. The stored procedures provide the necessary abstraction layer required for unit based development.

    Likewise, when I need to interface with tables on a remote database owned by another team, I'll mockup my own local tables or procedure calls based on the design specifications they are currently working from. Once their end is ready, I only need to make a few minor retrofits to the datasource and programming on my end.

    I've found this to be more effective than sulking, nagging, and raising a stink.

    "Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho