Sunday, March 25, 2007
Cohen on Howard: Final Thoughts
So, there you have it.
Is that the state of discussion in the software engineering community? Cohen's writing is frequently hindered by poor logic and unchecked facts. There seemed to have been more than a few ad hominem attacks on the authors simply because they worked for Microsoft.
In my view, there were two good criticisms to come from his review:
1 - the book is poorly organized
2 - the section on input checking proposes regexes as the be-all, end-all for input validation
It seems to me that could have been said much more succinctly than 5,400 words. Perhaps a chunk of the words freed up by being more direct could have been used to educate others on the areas he felt were poorly treated.
Disappointing.
If I were the person at Microsoft responsible for allowing books to be released I would not have approved the book by Michael Howard and David LeBlanc.
In essence, this is a book about how Microsoft has screwed up security in their programming practices over the years and how they are trying to fix it.
It also implies accountability, which is, as far as I can tell, a new thing at Microsoft in terms of software development.
That's right, Microsoft does not want backward compatability, but we all knew that a long time ago.
While this is a good business model, it is a poor information protection approach. Which may be the real reason that Microsoft does so poorly in this arena. They tell us that the most valuable part of a bank is its vault - did they miss the information age somewhere? They probably never worked on bank security.
The book is almost 800 pages, by the way, and it does have a solid 40 pages of worthwhile content, not a bad bloat ratio for some software products.
This is consistent with their expressed view of applying theory where appropriate - that you should never do so. That's part of why they will continue to make big stupid mistakes from time to time.
[...] but careful is not a word I would attribute to the authors of this book in their writing style. They approach the issues with reckless abandon, and that's entertaining at a minimum.
In Part 3, my hopes were dashed. Yes, part 2 continues in part 3. The separation is apparently only a trick to meet an administrative requirement of maximum section sizes, or perhaps a limitation of Word based on an integer overrun.
I think that the lack of time and attention to the underlying issues, the lack of organization and models, and the inconsistencies and poor advice are all related to spending too little time thinking through the issues and organization of the book. This is reflective of the same corporate culture that led to the problems with security at Microsoft and in other software vendors.
A better name might be something like: "How poor quality programmers at Microsoft have produced hundreds of instances of the same 10 big mistakes in their code, and how they can do their jobs a little bit better".
Is that the state of discussion in the software engineering community? Cohen's writing is frequently hindered by poor logic and unchecked facts. There seemed to have been more than a few ad hominem attacks on the authors simply because they worked for Microsoft.
In my view, there were two good criticisms to come from his review:
1 - the book is poorly organized
2 - the section on input checking proposes regexes as the be-all, end-all for input validation
It seems to me that could have been said much more succinctly than 5,400 words. Perhaps a chunk of the words freed up by being more direct could have been used to educate others on the areas he felt were poorly treated.
Disappointing.
