Here I will attempt to list the various books on software engineering and related topics that I’ve read and provide my opinion on them. I say “attempt” because this will be a background task; something to do whilst I’m chewing on my lunch or when I wake up at 4 in the morning and can’t get back to sleep.

Many of my favorite books are now getting rather long in the tooth. It’s not that I don’t like newer books, it’s just that I like to be able to look into the past as well as look forward into the future, while trying to stay current in the present. In other words, I think that having a historical perspective gives one a better appreciation for why things are the way they are, how they might be better, and where they could end up in the long run. So if you are willing to accept that we all stand on the shoulders of those who came before us, then I think you might find some gems in this collection.

So, without further ado, here’s the list so far:

  • Software Engineering Metrics, Volume 1: Measures and Validations. ed. Martin Sheppard, McGraw-Hill, 1993.
  • Code Complete. Steve McConnell, Microsoft Press (1st edition), 1993.
  • Software Requirements: Objects, Functions and States. Alan Davis, Prentice Hall, 1993.
  • Mathematical Structures for Computer Science. Judith L. Gersting, W. H. Freeman (3rd edition), 1993.
  • Software Engineering. C. Easteal and G. Davies, McGraw-Hill, 1989.
  • Learning Python. Mark Lutz and David Ascher, O’Reilly (2nd edition), 2004.
  • Design Patterns. Gamma, Helm, Johnson and Vlissides, Addison-Wesley, 1995.
  • Discrete Event Simulation in C. Kevin Watkins, McGraw-Hill, 1993.
  • Safer C. Les Hatton, McGraw-HIll, 1995.
  • Software Requirements and Specifications. Michael Jackson, Addison-Wesley, 1995.
  • Software Testing. James McCaffrey, Booksurge, 2009.
  • Writing Effective Use Cases. Alistair Cockburn, Addison-Wesley, 2001.
  • Software Requirements Engineering (2nd Ed). Thayer and Dofman, IEEE Computer Society, 2000.
  • Embedded Software – The Works. Colin Walls, Newnes, 2006.
  • C Traps and Pitfalls. Andrew Koenig, Addison-Wesley, 1989.
  • wxPython In Action. Rappin and Dunn, Manning, 2006.
  • Python Programming on Win32. Hammond and Robinson, O’Reilly, 2000.
  • The Pocket Handbook of Image Processing Algorithms in C. Myler and Weeks, Prentice Hall, 1993.
  • Python Pocket Reference (3rd ed). Mark Lutz, O’Reilly, 2005.
  • Structured Programming (A.P.I.C. Studies in Data Processing, No. 8), Dahl, Dijkstra and Hoare, Academic Press (June 1972)

Detailed reviews follow:

Software Engineering Metrics, Volume 1: Measures and Validations. ed. Martin Sheppard, McGraw-Hill, 1993.

This is a good collection of papers on the topic of software metrics. It includes works by McCabe (cyclomatic complexity), Boehm (economics and metrics), and Sheppard (a critique of cyclomatic complexity). If you collect or analyze software metrics then this is a book that should be on your bookshelf. It’s also one of the books I typically recommend to programmers aspiring to be software engineers.

Code Complete. Steve McConnell, Microsoft Press (1st edition), 1993.

I have both the first and second editions, and I think they’re both good. McConnell does a good job of laying out the steps necessary to successfully define and implement quality software, and he does it in a semi-formal way that’s engaging and enjoyable to read. I can only hope that more people would read and apply the material in this book.

Software Requirements: Objects, Functions and States. Alan Davis, Prentice Hall, 1993.

This is one of my favorite books on the subject of software requirements. I’ve been known to take it with me to meetings and quote from it every now and again.

Mathematical Structures for Computer Science. Judith L. Gersting, W. H. Freeman (3rd edition), 1993.

A hefty but readable tome, this book covers topics such as predicate logic, recursion, program verification, and the application of discrete mathematics to computer science. Highly recommended for anyone who wants to gain a deeper understanding of the abstractions that form the basis of non-trivial software.

Software Engineering. C. Easteal and G. Davies, McGraw-Hill, 1989.

While this book is dated now it still contains mountains of useful insight into the activities of software engineering. I would recommend if for no other reason than it exposes the reader to the methods and techniques that are the precursors upon which much of today’s software engineering processes are based. It’s a lot easier to figure out where you’re going if you know where you’ve been.

Learning Python. Mark Lutz and David Ascher,  O’Reilly (2nd edition), 2004.

A couple of years ago I found myself back in a Python environment after being away from it for quite a while, and I picked up this book as a way to give myself a quick refresher. A lot has changed in Python over the years, so I was looking forward to seeing where the language had been and where it was headed. Although I did get a lot from the book I also came away with a sense that it was somewhat confused as to what kind of book it was supposed to be. My one major gripe was that I felt that the presentation of the language was somewhat haphazard, and in some places confusing. Python might look like a typical procedural language (if you use it that way) but under the hood it is unique. I felt that the book contained far too many “oh, and by the way”, and “oh yeah, Python has this or that, but don’t worry about it for now” types of sidebars and asides. But, all bitching aside, this is a decent place for someone to start who has never seen Python before.

Design Patterns. Gamma, Helm, Johnson and Vlissides, Addison-Wesley, 1995.

This is the famous “Gang of Four” treatise on design patterns in OOP. Anyone who works with OOD/OOP has probably heard of it. Hopefully they’ve read it, and if they haven’t they should. The solutions presented to recurring problems in software design are as timely today as when the book was written. I wasn’t a big fan of OOP until I read this book. It helped clear away a lot of the hype and let me add some new tools to my kit.

Discrete Event Simulation in C. Kevin Watkins, McGraw-Hill, 1993.

A good introduction to the concepts and applications of discrete event simulations, which treat time in a discrete fashion and model the events which occur with each discrete interval of time. The book covers topics such as random number generation, entity modeling, scheduling and queue modeling. For me a nice touch was the inclusion of a diskette with the source code for a set of simulation functions, which makes it much easier to load and try out the concepts presented in the text.

Safer C. Les Hatton, McGraw-HIll, 1995.

A solid set of guidelines and techniques for developing safety critical and high-integrity systems using C. A large focus of the book is on automated testing, of which I am also a big fan. Hatton uses data collected from various sources to develop some useful metrics, and then shows how to apply them. Some folks seem to have decided that the book is a defense of C as the language of choice for safety critical applications, but I’m not sure I agree with this. I do believe that OO isn’t appropriate for everything, especially when code transparency is essential, and dynamically typed languages like Python are problematic in safety-critical environments (see my rants about unintentional obfuscation and code documentation). According to this article on The Register: “C overwhelmingly proved the most popular programming language for thousands of new open-source projects in 2008, according to license tracker Black Duck Software.” Since a significant number of software systems are still being developed in C I believe that this book is as timely now as when it was first published.

Software Requirements and Specifications. Michael Jackson, Addison-Wesley, 1995.

A collection of short pieces about requirements analysis, specification and design. Presents useful insights and cogent advice for anyone involved in these activities by introducing the notion that systems may inhabit more than a single problem domain. Most of the sections are short and easy to read.

Software Testing. James McCaffrey, Booksurge, 2009.

A good overview of the skills and techniques directly applicable to software testing, gleaned by the author from interviews and conversations with test managers in a number of settings. Short, simple and to the point, it is a good starting point for someone new to software testing, and a quick refresher for the seasoned practitioner.

Writing Effective Use Cases. Alistair Cockburn, Addison-Wesley, 2001.

A well-written guide for writing well-written use cases. Describes what constitutes a good use case and points out some of the pitfalls one might encounter while collecting the information necessary to craft a useful description of the intended behavior of the software. While I’m not a big fan of use cases (I prefer formal hierarchical requirements), if the only form of requirements you use are use cases then you owe it to yourself to read this book.

Software Requirements Engineering (2nd Ed). Thayer and Dofman, IEEE Computer Society, 2000.

A lengthy tome with a large collection of papers on various aspects of software requirements engineering. While it is thick, one can also pick through it for interesting topics, and most of the entries are quick reads.

Embedded Software – The Works. Colin Walls, Newnes, 2006.

Overall I wasn’t all that impressed with this book. It contains a lot of material that seems to be aimed at someone just entering the embedded software arena, and there is also a lot that I would classify as page-filling fluff (i.e. the parts on tools like Eclipse that are covered just as well, if not better, by material readily available on the web).  In general I think the author’s heart was in the right place, but the book tries to cover too much and ends up without a lot of depth or deep insights.

C Traps and Pitfalls. Andrew Koenig, Addison-Wesley, 1989.

Another “oldie-but-goodie” book, originally published in 1988 and copyrighted by AT&T Bell Labs. It contains loads of defensive programming advice, some of which I don’t believe can be found anywhere else. When it was written ANSI C was not yet an official standard, but Koenig uses the ANSI syntax anyway, correctly anticipating that it would soon be a standard. But, most importantly, the concepts Koenig discusses are readily applicable to other languages and situations.

wxPython In Action. Rappin and Dunn, Manning, 2006.

I was actually somewhat disappointed by this book, as I was expecting something more along the lines of the X Window System manuals (which are, in my opinion, classic examples of how to write good software manuals). What I found was a lot of top-of-the-waves information and examples that I didn’t find particularly useful. I ended up doing a lot of searching on-line to get the answers I needed  to some, admittedly obscure, questions. In a few instances I had to resort to reading the original wxWidgets documentation and even peeking at the C++ source code. This annoyed me. But, nonetheless, I do think it’s a good place to start if the reader has never before seen wxPython–it will at least let you determine what you’re missing and then go search for it.

Python Programming on Win32. Hammond and Robinson, O’Reilly, 2000.

If you’re writing Python code in a Windows environment then you really should have this book. It has a rather cookbook-ish style about it, but that’s OK as it does manage to highlight the important topics and provide examples for them. A big caution is in order, however, because once you start down the path of utilizing the underlying Windows services and Win32 API you will have created non-portable code. Or, to put into the terms of an associate of mine: “You will have given yourself over to the Dark Side.” Well, so be it. You do what you have to do to put food on the table, right? If you’re in need of this sort of knowledge, then definitely look into getting this book.

The Pocket Handbook of Image Processing Algorithms in C. Myler and Weeks, Prentice Hall, 1993.

Although published in 1993 this tiny book is chock full of image processing algorithms, most of which is just as applicable today as when it was published. But, as this is an abbreviated quick reference, and seems to have been assembled in a hurry, there are some rough spots and in some cases the example code contains errors that may leave the reader scratching their head. See these reviews, here and here, and carefully review and test anything you take away from this book.

Python Pocket Reference (3rd ed). Mark Lutz, O’Reilly, 2005.

When I started to wade back into Python after being away for several years this little book was my constant companion. In fact, I own two copies, a newer copy of which resides on my desk at work, and an older one held together with tape and dabs of glue, which now lives safely in my satchel. If you’re working with Python you should own this book.

Structured Programming (A.P.I.C. Studies in Data Processing, No. 8), Dahl, Dijkstra and Hoare, Academic Press (June 1972)

Although it’s now over 35 years old, this book is an essential read for anyone who really wants to understand the foundations of modern computer science and software engineering. The core concepts are still as relevant now as they were when it was first published, and it provides an invaluable baseline against which to measure how far the state of the art has progressed. You can still find used copies of it on Amazon for around $25 or so. It’s worth every penny.

0 Responses to “Library”



  1. Leave a Comment

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s




Follow Crankycode on WordPress.com

Little Buddy

An awesome little friend

Jordi the Sheltie passed away in 2008 at the ripe old age of 14. He was the most awesome dog I've ever known.


%d bloggers like this: