At Absolute Software we would classify ourselves as I2C and SPI programming experts. We have implemented dozens of projects using these technologies and are aware of most of the pitfalls and strengths of the two design routes. If you're having problems with your design, why not give us a call; we'd be happy to share some of our experience with you.
When making a choice between the two buses, the first consideration must be whether or not a hardware synchronous serial port is available and, if so, does it support SPI or I2C (or both).
I2C programming can be tricky even if there is a hardware port. For a start, the hardware port may not be fully I2C compliant. Whilst in the research phase, you should find out: what speeds does the port support? does the port support multi-master? do you need mult-master support? does the port support clock-stretching? do you need clock-stretching?
Another area of I2C programming that can be troublesome is slew rates. It can very difficult to get your pull-up resistor values correct. Remember to allocate time in your schedule for 'playing' with these, particularly if the I2C bus connects between a number of boards.
If you're programming a software I2C port (ie bit-banging) then bear in mind that both the clock and data lines must be bi-directional. Also bear in mind that it is not really practical to support multi-master mode with a software I2C port.
SPI programming has its own set of pitfalls. The single biggest problem that we suffer from regarding SPI programming is the lack of official specification. For example, if you have two SPI devices provided by different manufacturers, then the chances are that you will not be able to hang them off the same bus.
There are many variables in SPI programming including: clock polarity, clocking on rising or falling edges, timing of Slave Select lines, number of bits, time between bytes. These variables can mean that two SPI devices can be totally incompatible. For example, if one part is 8-bit and another is 16-bit, then the 16-bit part will get its shift register out of sync each time an 8-bit command is issued.
Given the choice I would bit-bang an SPI port rather than use a hardware synchronous serial port, as it SPI port programming is so straight forward and it gives you ultimate flexibility regarding the factors just mentioned. The only reason for not doing it this way is if you need really high data speeds.
SPI programming is more reliable than I2C because I2C tends to be more susceptible to noise, as the lines are not always driven. Although SPI programming requires more port pins which is not always practical.