I am a professional software developer, and one of my hobbies is
computers — mostly programming. I like languages, and know C++, C,
A+, Scheme, awk, etc. My preferred platform
is Linux, specifically, Debian
GNU/Linux. I am a Debian Developer (<neil@debian.org>)
and maintainer
for several packages
I've read a fair number of books related to computer programming and software development methods. I'll share what I think of some of them here. This is by no means a complete list of all the books I've read.
Before I've written a review, you might find just a link to Amazon.com where you can buy the book, but its presence means a review is forthcoming.
This is a book that every software development manager should read, and every software developer should hope their manager has read. Basically, Tom and Tim say that the working environment matters. Quiet, uninterrupted time matters. Getting a team to gel matters (and is hard). It all matters because making software developers productive is a result of creating an environment in which developers are free to do their best, where the environment consists of both the the people with whom they work, and their physical surroundings.
One favorite test of theirs is to assign a programming task, a spec for a small program that takes a few hours to complete, to each of two programmers at a company. They've done this at hundreds of companies. It probably doesn't surprise anyone that there is a factor of at least ten in productivity between the top and bottom range of programmers. What does surprise many is that the correlation between programmers at the same company is high. It means that either the environment is very conducive to producing good code quickly, or some places attract good programmers and the others do not, or both. In addition, they found that as long as the programmer had at least six months of experience in the language used, it did not matter which language it was, nor how many years of experience they has as programmers. They also found that the programmers who produced results with zero defects actually took slightly less time to complete the task than those whose results had one or more defects!
A couple of good chapters are Teamicide and Quality - If Time Permits. They wrote Teamicide after thinking, gee, building a team is such an art and so important that we should have a chapter describing how to do it. Well, it was so hard to come up with any hard and fast rules that they decided instead to describe some sure fire methods to destroy a team, so people could learn by contrast. The Quality chapter is about how building in quality is more of a mindset than an after the fact QA approach. They cite a couple of sources to give credence to the idea that building in quality might actually cost less than trying to build a product that is barely good enough, because less time will be spent on bug fixing, redesign, and other productivity killers.
This is a gem of a book, with snippets of information that will make you think about a variety of areas of software developement in ways you might never have thought of them before.
This is the book by the inventor of the relational model, Edgar F. Codd. He explains the fundamentals of the model, and no one knows those fundamentals better. In this book, which, as the title says, is about the second version of the relational model, he greatly extends it by adding many new concepts that he feels should be part of the relational model. I actually think he goes a bit overboard - the relational model works because of the power of its simple and incredibly solid foundation. Layering a whole bunch of rules and prescriptions on that gives me the uneasy feeling that they are personal preferences and not part of the model per se. I think Date does a better job.
I have to emphasize that, in my view, the relational model is one of the great achievements in computing. The model is incredibly good for many purposes using modern implementations, and it can still be argued that the modern implementations fall far short of fully implementing the model. Most implementations diverge from the simple and elegant foundations in set theory and that's where the trouble starts.
Chris Date is one of the early proponents of the relational model, in fact, he worked with E. F. Codd, the inventor of it. I think Date is a somewhat better elucidator of the model and its implications than Codd, and is very active in expounding its merits, along with his colleagues Hugh Darwen and Fabian Pascal.
Now, about the book — this is actually an introductory text, but it is full of good information on the relational model. If more people had read it and understood it, there would be a lot less talk of object databases and XML databases, especially as "replacements" for the relational model, because the the relational model does not restrict the data types that can be used as attributes, so a relation could have XML or object fields. It is only limitations of the current implementations of the relational model that prevent this. There are, of course, explanations of normalization, the relational algebra and calculus, and an obligatory chapter on the seriously deficient (in my opinion) database language SQL.
Understanding this book thoroughly would be more than most people need, but if you are one of the few who really groove on this stuff, he and others have a number of other books out there, too. I like a good, clean theoretical model, especially one that is underappreciated and clearly explained — that's why I like Date's book.
What? A novel about project management? What a yawner, eh? Well, no. Tom De Marco is the author of Peopleware, and he has spent a lot of time studying how people interact with each other. It's not that much of a stretch to think that he might be able to come up with some entertaining fictional interactions for a novel. (Heck, for all I know the people in the novel might be thinly disguised versions of real people he's met!) It's fun and a quick read; have an open mind and give it a try.
This is another classic of software engineering. There is, of course, the title essay, in which Brooks describes how adding people to a project can actually slow it down. The basic idea is that the additional communication overhead that must be absorbed when adding people to a project can take a large part of the additional effort that is being added. In addition, there is the famous Silver Bullet essay, in which he claims that there are no silver bullets in software engineering, i.e., buying the next whiz bang tool is not going to save your project. In fact, once again, adding the overhead of learning the new tool slows down the overall rate of productivity. Of course, you hope that after the initial slowdown, you will get it back many times over in increased productivity, but realizing there will be a slowdown should make you choose a time to acquire and learn a new tool when you have some free time, not when you are in a time crunch.
There are a number of other good essays in this book, so it is well worth buying, especially since a twenty fifth anniversary edition came out with some extra essays.
As a side note, Brooks is from IBM, as was Codd. That place has spawned some great thinkers.
If you program in C++, you are going to buy this book, so you might as well buy it through my link!
This is a very good description of the Standard Library. I recall struggling with some aspect of it, finding no help in man pages and other online sources, then reading this book and finding the answer and a clear explanation quickly.
Scott Meyers is well known as a guru of C++ programming, and this is his two Effective C++ print books combined into one CD with some additional material and cross references. It is very handy to have this book on a CD that you can transfer to your favorite laptop and refer to as you program amazing C++ programs on your train ride to work. Well, that's what I did when I rode a train to work, you might have a different use for it, but regardless, you will find it interesting.
This is an oldie from the late '70s. It predates Larry's evolution into a software development management guru and Yourdon's choice to write melodramatic books on various software engineering topics.
It is interesting to read this and other old books and see what has not really changed in software engineering. The terminology changes, i.e., back then people talked about "cohesion" and "coupling" and now people talk about "ecapsulation" and "orthogonality", but anybody who can form an abstraction can see that some of the basic ideas are just getting rehashed by people who have failed to learn from history.
User interfaces are important enough to be the subject of serious analysis and design, and it helps that Larry and Lucy have written an excellent book on the topic. Mark Twain is alleged to have said, "If I had had more time, I would have written a shorter letter." An analogous statement would be, "If I had had more time, I would have written an intuitive interface that mortals could use without much wailing and gnashing of teeth." The information in this book seems obvious when you read it (that's why the interfaces that result are intuitive), but is too rarely implemented.