I was looking at Code Complete on the shelf, thinking, "Outside of the Mythical Man Month, this may be one of the few mass market Software Engineering books to stand the test of time." For this reason, I'm thinking of jumping in to reread it.

I'm curious - has anyone else given it a second look recently? I so, did you see anything he got very wrong?

This isn't an attack, and not a request for a book review - I am more interested in which ideas have changed over the years.

And please - no comment about, "Demarco/Spewak/Zachman stood the test of time..." I am specifically interested in Code Complete because of the breadth of ground it covers, and breadth of impact it had in the field.

  • 1
    A quick re-examination of it has reminded me of annoyances where the text appears to contradict the examples, and different parts of the book advise different things. Other than that, it still seems pretty good.
    – Izkata
    Mar 12, 2012 at 0:19
  • @Izkata - examples?
    – MathAttack
    Mar 12, 2012 at 2:24
  • Added as an answer
    – Izkata
    Mar 12, 2012 at 3:18
  • 1
    Good question, recently I've been pondering whether to reread it myself. I wonder if there are plans for a new edition? Mar 12, 2012 at 7:02
  • 2
    I studied Code Complete (2nd Edition) last summer and nothing felt obsolete there. Unless there will be radical unexpected changes in software development, I think I would feel safe recommending this book in at least five years from now.
    – gnat
    Mar 12, 2012 at 9:28

2 Answers 2


Code Complete covers a lot of timeless concepts such as:

  • strong cohesion
  • loose coupling
  • good routine names
  • defensive programming
  • self-documenting code
  • software reviews
  • unit testing

which are certainly relevant today.

Some of the concepts championed in CC are now syntactically enforced in newer languages, for instance C# doesn't allow variable in sub-scopes to be defined in a manner that hides a super-scoped definition.

Other concepts, such as Hungarian notation for variable names have fallen by the wayside in mainstream programming (although anyone still working with the Win32 API will argue vehemently that they are alive and well). Nevertheless, the real concept behind the variable naming convention is to convey necessary meaning and clarify code, concepts that I would argue are also timeless.

All told, from what I can recall (and a quick peek inside my venerable copy of CC), I would say it is certainly worth reviewing.

I don't think, however, that it rises to the truly timeless nature of The Mythical Man Month. MMM address issues of who is doing the work, how and why are they doing it; as well as the costs and complexity of (human) communications. MMM addresses issues which are fundamental to everything we do. CC, in comparison, focuses on practical and pragmatic issues of how we do it. Put another way, if a project is behind schedule, and a manager decides to add 100 people to the team, writing comprehensible code will not really make a difference.

CC doesn't really address significant issues plaguing our industry; but it does provide a good foundation for striving for the best outcome in an often impossible situation.

I would certainly consider them both required reading for anyone who care about software development; and I would recommend re-reading MM whenever you need a refresher. CC is worth rereading if you are leading a development team, setting group standards, or training newer developers; outside of that, I personally find that I long ago internalized the material in CC and practice it on a daily basis.

Hopes that helps. They are certainly two of my favorites.

  • Perhaps I should create a similar Q for MM. Perhaps Brooks had it easier since he wrote a management book.
    – MathAttack
    Mar 12, 2012 at 2:23
  • Does not CC address the issue of "who is doing the work" in chapter 33: Personal Character?
    – mg1075
    Mar 12, 2012 at 2:44

Overall, the book is still good. However, I do have a few small issues with it:

  • Chapter 17 ("Unusual Control Structures") does mention guard statements as returning from a function early, but the examples given in Chapter 15 on "if" statements advise against guard statements. (Called guard clauses/early returns in the book)
  • The example in section 14.2 appears to contradict itself. It first gives an example of "bad" code, and how to make it "good". It then states that, when grouping related statements together, either by data or by task similarity would be "good". The "bad" example should then also be considered "good" - and, I think, much easier to read than the "good" example, because all the data is being calculated at the same rate - there's less state to hold in your head.
  • Chapter 23, Debugging, where print statements are villified in a bullet point. While I agree that they shouldn't be the only tool, they are enormously helpful in reducing the range of code where the bug occurs. Sprinkle a few throughout to see where the data suddenly isn't what you expect, gives a good starting point for debugging, depending on the code you're working with.

I have a vague memory of another involving function arguments, but can't find it at the moment. It may have been another book.

  • 6
    Yeah, he was wrong about print statements then and he's still wrong now. When faced with a bug in an unknown location prints and logs are generally my tool of choice. Mar 12, 2012 at 3:55

Not the answer you're looking for? Browse other questions tagged or ask your own question.