Recommended Readings

October 10, 1998 - Jack Harich - Home Page

One of the most frequent, and certainly one of the most productive questions I get is "What books do you recommend for...?" Here's a reusable answer. By the way, I only learned 2 things at Georgia Tech:

  • How to work hard
  • How to learn.

We have organized the books into these categories:

Foundational Skills
Java
Object Oriented and Pattens
Process and Management
Difficult Areas
Leading Edge Areas

Foundational Skills

Code Complete, by Steve McConnell

This is required reading at Microsoft, and I can see why. The author very lucidly and patiently walks you through all major coding issues, down to the last little detail. This is not an easy read, but then again hitting excellence at the coding level is not easy either. It was this book that long ago showed me there was a greener pasture. Before I'd considered myself decent, but this book convinced me I was way below average unless I changed a few hundred practices. Of course, this is "average" at Microsoft.

Software Engineering - A Practitioner's Approach, by Roger Pressman

The third edition was published in 1992, but the author managed to include what is still considered leading edge today - Object Oriented, 4GL, Function Points, even the predecessor to RAD which was then called FAST, and much more. The book is content rich.

The average developer, myself included, has a large unknown number of blind spots. A book like this will knock the edge off most of them.

Page 29 has a 2 page review of Barry Bohem's 1988 "Spiral Model for Software Development and Enahancement" which as we all know, has become the core of all leading processes.

Page 66 has the gem "As structure increases... risk decreases."

Java In Wonderland

The Java Tutorial, by Campione and Walrath

Excellent, the perfect first Java book. This is the only book in this list I've not read and don't have, because when I started Java there were less than 5 books, but I've heard numerous good testimonials and it looks solid. Also online.

The Java Programming Language, 2nd Edition, by Arnold and Gosling

The perfect second Java book, or the perfect first one if you are coming from C++ and are up to speed on OO. Please don't skip this book, because it offers a rare glimpse inside the wonderous minds of Java' creators. I can still remember the chill that ran down my spine when I read how an instance could be created from a String class name. I'd wanted features like this for years, but Visual Basic lacked them, and here they were. Wow!

Actually this was a hard read for me because I wasn't coming from C++ and was still getting up to speed on OO. But I found myself coming back, and back, and back, for more lookups than any other book for my first year with Java.

The Java Class Libraries, by Chan and Lee, Volumn 1 and 2

A major problem with the huge class libraries that come with Java is there's no examples, and no discussion, and nothing that ties it all together, and no good complete reference with examples for almost every tricky method call. This has frustrated and slowed the learning curve of many. Now we have the last word in Language References. These 2 books are now my standard Java reference books when I want to find out how to do anything with Java's packages. I get nervous when I'm on site and they're not. :-)

Java in a Nutshell, and Java Examples in a Nutshell, both by Flanagan

Good ole Nutshell was one of the first Java books, and is still one of the best. Few have extensive, often useful long sections of code, as does the Examples book.

Graphic Java - Mastering the AWT, by David Geary

If you do any GUI work you must master Java's awt packages. There are now numerous books on this topic, but this did it for me. This is where I learned about layout managers, rubberbanding, custom widgets, events, and ton of crucial good stuff.

Object Oriented and Patterns

Object Oriented Software Engineering, by Ivar Jacobson

I find it difficult to locate the perfect introduction to Object Oriented and process concepts. They all seem to assume you already know what it means, assume you just need a review or elaboration, and lack good examples. Of course I had to overcome years of procedural bad habits.

This is the book where it started to click and make sense. Ivar relies far less on subjective approaches and more on a diciplined, repeatable, engineered approach. That's how I felt several years ago. This year we discover that Rational has picked Ivar's process as it's standard process, and so Ivar has "The Unified Development Process" coming out in December 98.

Object Oriented Modeling and Design, by Jim Rumbaugh et al

Pretty good. Jim, Grady and Ivar are the three wise men at Rational. Enough said.

The Best of Booch, by Grady Booch

A collection of very readable articles. Stuff like this plus Ivar's and Jim's book helped push me over into understanding OO. Grady's style is rambling but an easy read. He's my favorite software author.

As an example of his style and quality, page 85 has the sentence "Because the resulting software products are rarely scalable, extensible, portable, or reusable, the long-term cost of ownershp is intolerably high." The careful reader can glean from this sentence the key long term risks of all software development efforts, ie scability, extensibility, portability and reusability.

Object Solutions, by Grady Booch

Cool. Nifty. Perky. Concise. That's what each page is like. One feels like he's looking over Grady's shoulder as he thinks and works. Page 25 gets right down to it with these immortal words:

"The five habits of a successful object-oriented project include:

  1. A ruthless focus on the development of a system that provides a well-understood collection of essential minimal characteristics.
  2. The existence of a culture that is centered on results, encourages communication, and yet is not afraid to fail.
  3. The effective use of object-oriented modeling.
  4. The existence of a strong architectural vision.
  5. The application of a well-manages iteratrive and incremental development life cycle."

Design Patterns, by Gamma et al

This was the best selling software book for the first two years it came out, and is still a top seller. Why? It single handedly established the concept and popular use of patterns. No top notch designer can proceed without this book on their shelf. It has become the most widely referenced software book of the 90's. It's known as the GOF (Gang of Four) book.

There's one curious weakness. One of the most important patterns is MVC, Model View Controller. Some consider it the grandfather of all patterns. While discussed in section 1.2, this is not included in their list of 23 patterns. How odd. Others have commented this is because the book covers only low level patterns. If so, why is the Interpreter pattern included? It is far more complex than MVC and far less popular.

Chapter 1, How Design Patterns Solve Design Problems, is classic literature. Study pages 18 - 22, which cover Putting Reuse Mechanisms to Work. Study pages 24 - 25, where 8 common causes of redesign are covered. Redesign is to be avoided if one wants to hit high reuse or easy maintainability.

A System of Patterns - Pattern Oriented Software Architecture, Buschmann et al (5 authors)

Once you've digested OO and Design Patterns, you're ready for the big time. This book paints a broader vision of the realm of patterns than the GOF book. As an example, Section 2.5 on page 169 covers Adaptable Systems with the Microkernel and Reflection patterns. There is a bit of deep thought here. Incidentally, the Bean Assembler has become my personal Microkernel. I'm pleased to thank Lenny Estrin for this book.

CORBA Design Patterns, by Mowbray and Malveau

The serious system designer needs a broad set of concepts, including patterns, to draw upon. This book goes beyond the GOF and 5 author book to cover other patterns common to business systems, especially distribututed ones. Page 15 has the gem "In system-level architecture, change and complexity are the primary forces to resolve." Oh so true.

Process and Management

A bit of advice. Software processes can be classified as "technical" and "managerial". Technical is also known as a "method" such as Spiral Lifecycle Model, Objectory or The Unified Development Process. These are the engineering aspects. Managerial process is the people, schedule and organizational aspects. Both are necessary. Managerial is more important as project size grows. A problem is books and popular processes mix the two process types freely. Beware.

The Mythical Man-Month, by Fred Brooks (a true classic), 1975. 2nd edition 1995.

I recently remarked to another consultant that this, back in 1982, was the first book that opened me up to the big picture of software development. He countered, "That's because it was the first book that could open anyone up."

I'm now on my fourth copy, having given the others to developers to read, read, read. Usually my loaners come back, but if they don't I like to wistfully fantasize they've become seeds dispersed by the winds of learning, and are somewhere being read and reread until dog earred, page loose, and ready for the compost heap....

This is the best selling software book of all time. It's main point is that better approaches are possible to Software Development Management than such practices as foolishly throwing warm bodies at a project to speed it up, and that this takes wisdom, not cleverness. Here's some samples of that wisdom from the book:

"What we do not understand we do not possess" - Gothe p 163.

"Plan to throw one away; You will, anyhow." p 116.

"How does a project get to be late? One day at a time" p 153.

"The hardest part of the software task is arriving at a complete and consistent specification, and much of the essence of building a program is in fact the debugging of the specification." p 195.

"Adding manpower to a late software project makes it later" p 25. (Brook's Law)

"The Second-System Effect" - "This second (system) is the most dangerous system a man ever designs." p 55.

As a bonus chaper 16 of the 2nd edition has Brook's classic "No Silver Bullet" reprinted in full, with rebuttals and discussion. This and Dijkstras's "Go To Statement Considered Harmful" (actually a letter to Communications of the ACM in 1968) are the two most famous essays in all of software literature.

This is my top recommendation for a first software book on anything. It will get the reader interested in improvement and reading more, more, more. If it doesn't, show them the door, door, door. :-)

201 Principles of Management, by Alan Davis

This small book has one short page per principle. It remains the best summary or introduction to software managment I know of. This is my top recommendation for a first book on software management. It is fairly non-technical, and thus good for any manager or developer. Sample principles are:

"Principle 18 - Build software so that it needs a short user's manual" (like Paul Reavis says)

"Principle 64 - Design without Documentation is not Design"

"Principle 106 - Don't code too soon"

"Principle 167 - Manage by Variance"

Please don't be put off by the brevity and simplicity of this book. Several years ago, when it first came out, there was a 6 week discussion of it on the CompuServe CASE forum. They widely agreed it was distilled dynamite, and great food for thought.

Debugging the Developement Process, by Steve Maguire

This is my top recommendation for a first process book It's a very engaging, informative, easy read. Yet another top notch book from Microsoft, these sample quotes say it all:

From chapter 5 on Scheduling Madness - "The schedule, not the project goals and priorities, not even common sense, was driving the development process."

From chapter 8 on slippage - "Train the development team to work effectively during a normal workday. Don't allow them to work long hours, which serves only to mask time-wasting activity."

Dynamics of Software Developement, by Jim McCarthy

And this is my top recommendation for a second process book. (Ivar's OOSE is the third) It clearly esplains why all projects need (but rarely have) a program and a project manager. This is a gigantic golden nugget organizations will pass up at their own risk.

The book is organized into 54 catchy rules. Sample quotes and rules:

"Focus your attention on the movement of intelligence from people to bits as the central activity of the software development team." p 3.

"Being surprised by a slip says the organization is broken." p 131.

"Build an evolving image of the market that becomes increasingly sophisticated." p 73.

"Rule 4 - Don't flip the bozo bit"

"Rule 7 - Use Feature Teams" - This is a really, really, really good practice.

"Rule 33 - Get to a known state and stay there"

BTW, why did Microsoft hire Jim? During the interview he pulled out a list of The Top Ten Reasons You Should Hire Jim McCarthy. How's that for effective creativeness?

Program Smarter, Not Harder, by Johnson et al.

The title agrees fully with one of my own self-guiding mottos. Yes Virginia, there are ways to increase productivity besides working longer. This book covers them exhaustively.

"Good software process is not merely the path to the goal of a successful product but is the establishement of an ever-changing curricula of improvement practices." p 9.

"A high level of reuse can only be achieved if reuse is more important than the project." p 180, paraphrased.

Chapter 11, Guidelines for Software Qualtiy, is what I recently gave a small team to read as their introduction to process. It covers the Capability Maturity Model and Walkthrough, Reviews and Inspections. 1 hour after they read it, during a review we uncovered a design defect that caused an immediate 1 week slip in a 6 week project. It was a successful review, and the team began to grasp the importance of formal approaches because they had seen it work.

However, like most books, it's wrong on hitting ultra high reuse Page 239 states:

"In the best of cases, software developers on an object-oriented project don't spend much time writing new code. The best use of developer's time is in finding and understanding existing classes and integrating them into the solution. (right so far, but muffs up on the following) This is done by instantating a template class from a library, adding another level of inheritance, or in some cases, copying and modifying the source code of an existing class."

Ten times as productive are plugpoint frameworks using interfaces and declarative knowledge.

Microsoft Secrets, How the Worlds Most Powerful Software Company Creates Technology, Shapes Markets and Manages People, by Cusumano and Selby.

Spellbinding. Detailed. Top quality case study approach. This is my top recommendation for upper management, so I loaned it to my cousin Scott. A year later I got it back, as he was cruising up the East Coast for job interviews. His best offer so far was a VP slot at an 800 person company in his industry, which is not even software. He in kind turned me onto Critical Chain, which 2 days ago that company's President had handed him a copy of, and asked "Tell me what you think of this."

Page 64 has Mike Maples's (MS executive vice-president from 88 to 95) personal list of management principles:

  1. Let people do their own schedules.
  2. Build in buffer time for unforseen delays that always occur.
  3. Assume change will happen, so don't waste time trying to write a complete specification up front.
  4. Manage by milestones, starting with the most difficult things first.
  5. Focus on customer problems, not technolgies or processes.
  6. Move people around, to mix the good and the bad. (and develop broad skills)

Page 43 has a complete copy of Chris Mason's (famous IMHO) 1989 "Zero Defects" memo. In essence it says to debug as you go, not later. Today, 1998, not everyone has gotten this message, especially upstream of coding.

The book's chapter titles are very telling:

  1. Organizing and Managing the Company
  2. Managing Creative People and Technical Skills
  3. Competing with Products and Standards
  4. Defining Products and Developement Processes
  5. Developing and Shipping Products
  6. Building a Learning Organizaton


Difficult Areas


Any biology textbook describing cells, the human brain, nervous system, etc

A small one is Nature's Masterpiece - The Brain and How It Works, by Pool.

For example in the human nervous system, over 90% of all internal events are ignored, and a large portion of the body is just for event transmittal. All information for duplicating an animal and key organ instructions is stored in DNA. This heavily affected Bean Assembler design. Mother Nature and Father Time are our best designers, and their best work is life.

The Goal and Critical Chain, both by Eliyahu Goldratt.

Critical Chain is more current, read it first. Both are business novels you can't put down. Critical Chain is on project management, and how one manager discovers how to do this better. The Goal, published in 1975, sold over a million copies and had 12 translations. The goal (pun intended) of these books is to teach one the difficult art of asking the right question, and to encourage managers to train their associates to do just that as their most important skill, aka the Socratic method. Hmmmmm, heavy duty.

Software Runaways, by Robert Glass

This will scare you into adopting risk management as your prime tool to manage non-trivial projects, not to mention adopting a minimum of other formal practices. From the jacket:

"If failure teaches more than success, imagine how much you can learn frm the most catastrophic software development failures of all time. In Software Runaways, software failure expert Robert Glass shows exactly what went wrong in 16 collossal software disasters - and how to keep disasters from happening to you."

Now my approach is the project is risk driven, and the software is architecture driven.

More importantly this book shows how difficult some design can be, or how overlooking or postponing design details can lead to disaster. For example, on the cancelled 7 billion dollar FAA Advanced Automation System, only late in the project did they attempt to figure out how to install the new system while the old one was running. "No one could figure out how to do it." This chilling eleventh hour surprise shows how risks must be indentified and resolved early on.

Leading Edge Areas

Component Software - Beyond Object-Oriented Programming, by Clemens Szyperski

Building systems by component assembly is now seen as The Way. This book is an excellent exposition of The Way, though it is academic since the author has obviously done little first hand component work. But this is true for nearly everyone.

Chapter 7 is titled Object Versus Class Composition, or How To Avoid Inheritance. This confirmed what I've been practicing and preaching - Inheritance is to be avoided if you want to hit high reuse and/or productivity. I've been lambasted on the Advanced Java newsgroup for this stance, and now we have the book that supports my position. Composition, at the highest level, is components in frameworks.

Page 20 mentions a Forrester Research report which discusses the usual difficulties of adopting OO versus the substantial ease of component use, and states "There is a push from 'elitist objects' to 'populist components.' " How's that for an insight?

The book is through, covering many OO details, CORBA, COM and Beans, and many market issues. There will be many more books on components soon. OO is out, Components are in.

Rapid Development, by Steve McConnell

Why is this here, and not with the Process books? Because Steve has gone beyond typical process approaches and addresses a completely new issue - How to develop in "web time." This is incredibly difficult, and even tougher to write about. Steve, the author of Code Complete, has done it again. His wife calls him a "two time author." I call them both required reading classics. This book is state-of-the-art high speed process management.

As a small taste of the usefulness of this book, page 98 lists the top ten common schedule risks, and how to deal with each, and how to deal with them well. Please let me know if there is any other material in the universe like this.

Page vii lists the 25 Best Practices to hit your schedules ASAP. These form chapters 17 to 41. Examples are Spiral Lifecycle Model, Inspections, Throwaway Prototyping and Outsourcing. These are essentially a large, detailed checklist for you to review and follow, if you can think at that level.

Page 92 explains Risk Exposure, whereby one can quantatively rank risks. First you list your risks. Then you estimate the probablity the risk will happen (Loss Probablity) and schedule slippage it would cause (Size of Loss). Loss Probablity times Size of Loss equals Risk Exposure in a unit of time such as weeks. You then sort the list by Risk Exposure and start resolving them one by one. Do all this in a spreadsheet and impress your grandmother!

The Man Who Discovered Quality, by Andrea Gabor

Subtitled "How W. Edwards Deming Brought the Quality Revolution to America - The Stories of FORD, ZEROX and GM."

Few developers are aware of the extraordinary impact and ahead-of-his-time ideas of Deming. This book is inspirational time and time again. A few quotes:

Page 16 - "While his knowledge and technical expertise are beyond dispute, he believes it is more useful to ask questions than to give answers, an approach that has gained populatiry as executives of troubled companies grow wary of easy solutions."

Page 225 - "Pontiac found itself on the cutting edge of both SPC and labor relations. The Deming experiment that proved to be Pontiac's inspiration took place at engine plant No. 18. Only a year or so before Deming's arrival, another consultant had written off the plant's management as incompentent and suggested that it be replaced. Clayton Williams, the supertendent of manufacturing, knew his job was on the line. To Williams, a God-fearing Southern Baptist, Deming's brand of quality evangelism with its belief in the fundamental goodness of people, coming at that paricular moment in time, must hae seemed like a sign of devine redemption. Willimas became an ardent Demingite. 'Within five months he had dropped his inventories $600 million, dropped scrap rate eighty percent, increased his throughput four times,' recalls Hoglund. 'He went from goat to hero in about eight mnonths. It was just flipping from a very traditional approach to this very human give the people the opportunity, controlling the process.... When we saw this, we saw the power of what Dr. Deming was doing."

The book shows how one person took a long look at a large unsolved probem, and solved it beyond all expectations. There are similar problems requiring similar dedication and similar paradigmatic solutions, awaiting all of us.

"One who is smart learns from experience. One who is wise learns from the experience of others".

Here's the history of this page:

More and more I was being asked "What do you recommend I read about so and so?" First I kept a 20 line text file with my top recommendations in 3 categories. But it was pretty dry. And I really wanted to get others reading up a storm. After all, books and practice are how I learned software. My degree is in Industrial and Systems Engineering. I'm just another self-taught kind of guy.

A pattern I noticed was if I just said or wrote the book title, not much happened. But if I took the time to bring it to life by describing it, and pointing out cool tidbits, they would jump on it. So I took the time to write it all up, and here it is. Enjoy.

A few notes about reading

I love to read to improve my skillset. I read about 2 hours a day in my field. That adds up to about 2 books per month, 5 magazines per month, and maybe 50 articles per month. Experience has shown me that this is the best way to master a particular field of expertise, and to keep up with changes. So I spend 2 hours a day with the masters of my field, listening to their advice, getting the very best they have to pronounce on their subject. Think about it. Due to the proliferation of printed material, we can sit at the feet of the wise men and women for hours and hours, and drink as deeply as we want from the cup of wisdom they pass around....

To pick a book, it must pass a few tests. Long ago my elder brother, Pete, told me there were two "sniff tests" he ran on every book before purchasing it:

Over the years I have added these:

To get the most out of a book I do a few things:

The last is by far my most important reading technique, because it allows me to later come back and quickly lookup important information. Thus, during a meeting or while writing or while thinking real hard, I can reach over to my books and suprisingly quickly get to the source. This does wonders for my ability to elaborate when sharing information. This is the technique that allowed me to so easily list some cool quotes and such for the above books.

Magazines? I subscribe to Software Development and Component Strategies (previously called Object Magazine). These are the best I've found for general improvement. And of course there's Java World.