Dr. Dobb's Journal December 2002
I remember a stage in my evolution as a programmer when books by IBMers used to annoy the heck out of me. They always seemed to be focused off in the distance from where I wanted to concentrate. I was looking for full-frontal technology. The IBMers wrote books that were about the success of the mission. These were not feel-good managerial books; rather, they were profoundly technical. But the emphasis was never tech for tech's sake.
Framework Process Patterns, by James Carey and Brent Carlson, is one of those books. It's not about redescribing, for the nth time in computer science, a DO-LOOP, this time as a design pattern. It's about recognizing the patterns in the collective artistic life of the project itself, as it lives and grows in the minds and hearts of the project team members. It's a patterns book applied to a domain to which patterns are genuinely applicable—that is, to the project itself. Nowadays, this sort of thing speaks profoundly to my soul.
Carey and Carlson are two IBMers who garnered the material for their book while on the now-assimilated IBM San Francisco Project, which was to have unified everything everywhere for all time (or something like that). They divide Framework Process Patterns earnestly into chapters reflecting aspects of the project; for example, Requirements, Analysis, Design, Documentation, Social Aspects, Framework Use, and the like. But listen to some of their patterns:
When you hear the names of the patterns, you're torn between the desire to read the chapter immediately and the conviction that you don't need to read the chapter because you have lived it! Luckily for those who read the chapters, they're well written and the authors know just what they are talking about. You can't fake experience and insight like this. This is the real world, and they're right about what they know. I cringe as I read it because it makes me relive the agonizing incidents that taught me these lessons.
This is a really, really good book for programmers who are starting to look up from the keyboard and ponder whether they could do it better if they were leading the team. If this is you, buy this book now.
I'd read anything Fernando Pereira was involved in: He was one of the authors of the first PDP-10 Prolog compiler and has been a leading light on paper, in the lecture hall, and on the Internet for information on AI, Prolog, and a raft of other computer-science subjects. But The MPEG-4 Book, edited by Pereira and Jouradj Ebrahimi, is as lavish an indulgence in a narrow groove as you could wish for.
The worst aspect of browsing such a comprehensive treatment of a single subject is that you finish the opus more aware than you would be from lighter works that you've only scratched the surface! MPEG-4 and its close cousins are becoming a whole specialty in our industry, witness such terms as "codec" (meaning a coder/decoder). The field is rife not only with technical difficulty but with legal landmines, some of them carrying the threat of terms of up to five years in federal prison. Hit the index, and sure enough, "patent pools" is a term.
Golly, what am I supposed to tell you about this book? The table of contents alone would be two or three monthly installments of Dr. Dobb's "Programmer's Bookshelf." The MPEG-4 Book is everything you could possibly hope to gather in a book about MPEG-4. Articles, papers, articulation, and speculation by more than a dozen authors; designs, timing charts, bibliographies, specifications, analyses, case histories—you name it, it's all here. If sentences like:
The MPEG-2 AAC SSR profile permits the definition of decoders with lower maximum signal bandwidth and complexity by discarding the signal processing for higher PQF bands.
get you breathing heavy, this one's for you.
DDJ