Don't let the publication date (1996) put you off. The advice here is as salient now as then, maybe more. You might think for a moment that faster processors, more cores, and a hundred gig of RAM would solve any scaling problems they had back then. And you'd be right, for some kinds of projects.But software has gotten bigger since then, and libraries have proliferated, and languages have grown far more complex. Build times for big projects can easily run to hours, or more. It's hard to run the "daily" build when it takes more than a day to process all those millions of lines of code. Now, as a programmer, think about what that means when you fire off a compilation at your desk.That's the kind of problem this book addresses. And really, the basic issue isn't hard to grasp: there's just too much stuff in the code. Not just your little C module of a few thousand lines, but all the symbols and declarations in its include files, and in the files they include, and ... well you get the idea. Even just "hello world" might define a huge number of symbols, all of which take up memory, and vanishingly few of which end up in your runnable program. The include files and libraries unique to a big project just take the problem to a whole new level.So, at its core, this book is about data-hiding. I don't mean in the sense of OO encapsulation and private variables. If anything, they're part of the problem: the compiler sees and processes them, in all of your include files, even if your program can not and does not actually use them.The real goal is to hide all those definitions and declarations from the compiler. This book is about pruning the tree of dead-wood dependencies, accessing only what the program really needs, and squashing the "everything depends on everything" problem that might otherwise seem unavoidable.And, if you really believe the safety and reliability benefits of normal data-hiding, this takes it up a notch. C++ offers things like "friend" declarations, const_cast, and some flavors of "using" that can expose hidden data or strip safety attributes. It's not this book's goal, but the techniques here can prevent even those back-doors from granting unwanted visibility and access to your code's innards.The details get fussy and perhaps a bit repetitive. But, if you work on really big projects, you have problems that small-scale development never prepared you for. This book won't solve all of them, but it's a clear and applicable solution to a large class of the technical issues.-- wiredweird