Code Complete, 2nd Edition by Steve McConnel
Why Read It?
It is uniquely comprehensive and practical. It touches all kinds of important daily tasks that other books gloss over, such as code indentation, naming variables, use of pseudocode, debugging, code reviews, system integration and so on. If you're trying to make up your mind about the pros and cons of different techniques, this is a good place to check.
Shortcomings
It tries to avoid being prescriptive about development practices, which is a reasonable approach for a book that strives to be comprehensive, but there is a lingering old-fashioned feel as a result. For example, the section on Developer Testing mentions Test-Driven Development in passing, referring to it under the unusual title of Test-First Development. My opinion is that Steve McConnell doesn't have a strong intuition of how Agile practices differ from conventional practices and so you need to look elsewhere to get that perspective.
Summary
A great book to have on your shelf to get a quick but thoughtful overview of good practices. Edition 2 is much better than Edition 1.
Code Complete, Second Edition by Steve McConnell, Publisher: Microsoft Press, Pub Date: June 09, 2004, Print ISBN-10: 0-7356-1967-0, Print ISBN-13: 978-0-7356-1967-8
Design Patterns by Gamma, Helm, Johnson, Vlissides
Why Read It?
This extraordinary book unfortunately spawned a volcano of obscure jargon and concepts that created a new techo-elite. And if you don't know it, you're excluded from that elite and vulnerable to being bamboozled.
The basic idea is simple and well-executed - capture the common programming idioms that developers use as generic patterns. Give the patterns names. Try to codify existing programs in terms of these patterns.
'Shortcomings
The idea of a design pattern is subtle and interesting but you won't find a sensible discussion of the topic here. What you will find is a chapter-by-chapter exposition of an arbitrary collection of design patterns. A few of the patterns are genuinely useful concepts. Too many of the patterns are confusingly named, however. Some are difficult to distinguish. Others are simply band-aids for common language design flaws.
Summary
This book did not become famous for nothing. The codification and generalisation of common programming idioms into generic design patterns is a spectacularly good idea. It is fascinating to speculate how many idioms there might be. But the book is not a tutorial, lacks examples that distinguish variations on a theme (e.g. Abstract Factory versus Builder, Strategy versus Factory Method), and has a noticeable bias towards C++ issues.
Read it, endure it, find someone to discuss it with. It's worth it.
Refactoring by Martin Fowler
Why Read It?
At the very heart of Agile development is the sequence Red-Green-Refactor and it is the most subtle part of a new discipline. This book is the best explanation of what refactoring is all about.
It starts with an exceptionally readable blow-by-blow example of refactoring a small program. Then it breaks of into a non-exhaustive list of common refactoring steps.
Shortcomings
Refactoring really is a subtle idea. As an indication of this, the introduction to this book describes refactoring as "the process of changing …. that does not alter the external behaviour yet improves its internal structure". But this misses the crucial idea that refactoring is done as a series of ''tiny'', ''meaning-preserving'', ''standard'' steps. So it's great on technique but somewhat short on philosophy.
Summary
Together with Test-Driven Development by Kent Beck, this is all you need to get started with Agile programming.
Test-Driven Development by Kent Beck
Why Read It?
A superbly readable description of test-driven development, the core technique behind Agile programming. The running example provides a thread on which a smart, enthusiastic and friendly narrative rests. When you finish the book you'll be dying to give it a go.
Shortcomings
Just one niggle - the running example is described in very woolly English terms. Anyone with a maths background like myself, is likely to be irritated at the vagueness. And it is a bit vague on why test-driven development really works so well. So strong on technique, not so great on philosophy.
Summary
The single best tutorial book on Agile programming by a mile. If you only read one book on software development, this is the book.
The Mythical Man-Month by Frederick Brooks
Why Read It?
Wonderfully articulate, this book persuasively argues a common-sense view of project management. It's central theme is that "adding manpower to a late software project makes it later" but the book has other key themes such as the second-system effect and value of prototyping.
Despite being published in 1975, it anticipates some of the key ideas that have gelled into the Agile manifesto: pair programming, prototyping, small teams, use cases ('The Manual'), specialised roles, the critical role of communication, sprints ('code freezes'), and incremental milestones. And some of the advice, regarding sharp tools and separate roles for different levels of software, has never been accepted as conventional practice, despite being solid advice.
Shortcomings
Somewhat dated in places where it implies a 'waterfall' development. The last chapter (17) was tacked on decades after and isn't as convincing as the previous chapters.
Summary
It is the best book on software engineering written to date. If you only read one book on software project management, this is the book.
UML Distilled by Martin Fowler
Why Read It?
UML has become essential for the practising software engineer. But UML is also a jungle of arbitrary diagrams and notations. This book is your guide to the handful of diagrams that are actually useful. Fowler provides an intelligent and frank commentary that is a gasp of fresh air in the overgrown, stinky swamp of UML notations.
Shortcomings
None.
Summary
Excellent - perhaps the only book on UML worth getting :)
