Engineering Problems on Large Software Projects

Size matters.

If you are on a large software project, you are going to face a bunch of problems that you just won't see on small developments.

And by large projects I mean multi-programmer developments based on a library of modules written over a number of years.

I said, "based on a library of modules". If you don't make your code strictly modular, you've already failed. That isn't always easy, especially when it's the day before a deadline and it's far quicker to bodge in a fix.

Given that you have a bunch of modules, with different versions of them used over several products or versions of the product; maintaining a formal build process is essential. Builds should be numbered or labelled and it should be trivial to reproduce any previous build from you version control system (you do have a version control system, don't you?)

Some formal structure to record who has what build is also needed.

Code re-use generates code as structural patterns are needed to ensure your new module can communicate with the existing functionality.

And with all this extra interfacing code, finding the guts of a particular function or class becomes a real issue. Although Google intranet search tools can certainly help here.

If you've only ever hacked together 2-day projects in your bedroom, these issues will be alien to you. Anyone who's worked in a real software house should be familiar with most if not all of them.