Olivier Langlois's blog

I have not found this book very fun to read because of its very structured and academic format. I have not learned much from it as much of its content is general wisdom that anyone with many years of experience in the industry has probably seen around before. Something positive I can say about the book is that I totally adhere to the methodology explained in the book. In my software development career, I have experienced myself the benefits of applying similar software development management methodology and I have also seen the negative consequences of not following it.

I have not found this book as interesting as the type of books that I usually read. I prefer books dealing with the more technical aspects of software development. I have read this book because I need to acquire a solid base of knowledge on software project management and not because the topics covered in the book seemed fun and interesting to me. Even if I was not very enthusiast to read it, I must confess that the author made a great job making his book interesting to read by interleaving important concepts with anecdotes from his work experience.

This book is divided into 54 short advices each taking 1 to few pages to expand the rational behind the advice. This is a format that I like and the advices that I have preferred were the ones dealing with the psychological aspect of software development. An example of such rule is that software quality is the mirror of the state of mind of the team. For some this might be obvious but considering the book intended readers which consist of engineers and software professionals, the author has been wise to be explicit on this topic in my opinion as from experience, human interactions is usually not the strongest skill among developers.

The part that seems to me to be outdated is the whole proposed economical model to market software. The author advocates that to make money from software, you must release often like every year and by doing so, your customers will be so happy that they will gladly hand you more money year after year. I think this model used to be true when the software industry was still young 20 years ago but in 2008, the software products are so mature that no matter how hard you try to squeeze more new features, it will not be enough to justify for people to purchase the new version when that last one does everything you want. You just have to think about the sales of Windows Vista or Microsoft Office 2007 to see what I mean. Changing just for the sake of changing does not sell.

In my opinion this model should be changed to one where incremental small evolutions are proposed to customers. I would be willing to pay a small amount of money every year for an OS that is smaller, better and faster at each version. I do not get it how software companies can expect people to be interested in slower and more bloated products than the previous version. Add the possibility to purchase inexpensive add-ons to fill very specific needs to the model and you have a very attractive model. I am not sure if what I would like to see is representative to what the typical customer expects or if my proposal is viable in real life but one thing is sure. The model proposed in the book does not seem to work anymore for many mature businesses.

There is a 2006 edition of this book. I might take a look in it to find out if the advices that I have found outdated have been reworked.

This is a good book as it does a good job covering the different sources of software insecurities:

• The classical buffer overflows on the stack and on the heap
• Canonical issues on input
• The least privilege principle
• There is a brief overview on how store a secret

On the last point, the authors know well the topic. If you are using cryptography to protect something in your software but just store the private key in a global variable then you are helping tremendously the job of hackers as all they will have to do is look into your executable binary to search for something that looks like a key. A security measure is as strong as its weakest element and no hacker is foolish enough to attack a cryptographic algorithm that is proven strong. Even if you store the key in a secure place, all that is needed to retrieve the key is to perform a memory dump at the right time just before the software use the key. At least, you can make hackers job harder as there is nothing you can do to make your software 100% safe against hacker if the software is valuable enough to motivate them to hack your software. All you can do by improving your software security is to buy you some time before your software is hacked. All that to say that there is no bullet proof solution against hackers but the book gives solid leads to improve software security in that aspect.

In this book, there is a strong emphasis on Microsoft security technologies. The Windows Crypto API and the Microsoft OSes privileges API are described in length. If you develop on Windows and want to make your software more secure then this is an excellent book for you. If you develop on another platform, there is still something for you in this book as there are a lot of code snippets that are platform independent to improve software security such as input validation for file names to protect yourself against canonization bugs.

This is a very good book about software security but I do not recommend it simply because there is a new edition of it.

In my opinion, this book is better than Pthreads Programming because it goes way beyond just presenting the pthreads API. One critic I had on all the other multithreading books that I have read is that they are not covering issues with multithread programs on a SMP system. This book is actually discussing some of these issues on several pages! Beside this quality, it also covers high-level design patterns on how you can use threads such as pipelines, work crew and client/server. There is also a chapter showing how to program with thread cancellation and a section explaining how to create new synchronization objects from the primitives.

This brings me to the only problem that I can think of this book: its age. It is not totally up to date. Learning how you can build new synchronization objects by itself is a very interesting exercise but the problem is that the new synchronization objects built are the barrier and the read/write lock which have been added to the pthreads API since the book publication. Also, except for a small section describing the futur of pthreads, the newest additions to the pthread API are not described.

This book does a nice job for describing the pthread API. When I have read this book, my multithread programming experience was mainly with Win32 threads and reading this book was my first exposure to the condition synchronization objects. With the help of this book, it has been a breeze to learn how to use conditions. What is missing from this book written 10 years ago, which is also missing in all multithread books that I have read of that era, is coverage on issues with parallel processing. If all you have to do with threads is to launch a background job while keeping UI responsive or asynchronous I/O on a single core processor, you will be fine with this book.

However, if you try to crunch an array of data with multiple threads each processing their own chunk of the array, you could fall into cache line alignment problems even if your threads does not access the same memory locations. Those problems are platform dependant. I have written such a program that was working wonderfully well with a Sparc station and a PowerPC based station but once ported to a x86 architecture, the program was actually becoming slower than the single thread version. It is very hard to get it right. You have to be careful about the array alignment in memory and where the boundaries of the chunks of data that you assign to threads are. What will happen if 2 threads located on 2 different processors access to the same cache line is that one processor will have to flush that cache line back to the main memory and the other processor will have to fetch the values back from the main memory to its cache. The overhead of this is so huge that processing the array from a single thread could be faster.

I still have to find a book that addresses these problems. I expect it to come soon with dual and quad core processors becoming mainstream but this is not this book.