One example in the current project is adding a new file. Refactoring old code and writing new code often involves adding new files. But when that involves doing a full update from the version control software, checking out the project, adding the files, checking that it all builds, checking in the new files, checking in the project, and re-applying any local amendments to the global project, you tend to be wary of doing it too often.
Similarly, localisation can be an issue. You have to think twice about adding more text to the game when that means you have to think up a unique identifier, check out the localised strings data, add in your new identifier with the associated text, run the exporter tool to update the data files, test that it builds, test that it shows the correct text, and check the lot back in.
(It's worth noting here that these methods are imposed upon us in order to interoperate with another company.)
It's these problems that Big Upfront Design models like the waterfall method were designed to fix. After all, if you can plan all your classes before you start coding, you won't ever need to add files to the project later. And obviously your string database can be done first too, making localisation later easier. These are examples where software development is like traditional engineering - making changes is slow and costly, and therefore should be planned for meticulously.
Unfortunately the vast majority of software development is not engineering, and never will be. If you could rebuild a car or a bridge to make a minor change in 2 minutes, you can bet that traditional engineering would be done vastly differently. We also have to react to market and design forces more rapidly than most engineers do - some of this is a problem with management, but much of it is inherent to the industry. You have to be able to adapt to shifting requirements. Computing power can double in the time it takes to complete a project and expectations can rise with it. Software development, and especially game development, needs to be agile.
But how do you mix developmental agility with lumbering systems that require so much effort that they actively discourage their own use? Things like source control and localisation are necessary evils of course, and there are probably better ways to do them, but there are many smaller scale issues of a similar nature, such as generation of graphical assets, getting sounds into a game (anybody used the Sony tools? ouch.), etc. I'm sure many of our problems come from the tasks that turn out to be far more resistant than they should be.
