Author responds to "Worst. Best Practices Book. Ever."

I think I may have been a bit harsh yesterday in my review of Practical Guidelines and Best Practices for Microsoft Visual Basic and Visual C# Developers. Although I stand by my statements, I wanted to expand on and clarify things based on some of the feedback I received (especially one from the author).

First and foremost, there are lots of good tips in this book on doing a whole variety of things from remoting to threading. In fact, there are many more good tips than there are bad. But when you title your book "Best Practices," you really can’t afford to have one bad paragraph (let alone the number I found) in your book. With the countless books to choose from, readers will look to a "Best Practices" book as the standard for development. Therefore, such a book must be judged on a higher standard than others.

One of the first things I touched on was credibility (of which I said the authors had none). Now, I didn’t intend for this to be demeaning or insulting; it’s simply a statement of fact. There are few (if any) among us who has the credibility to make statements of fact without any backing. Just as your professors would say, you need to reference and back up your facts. Yes, "MSDN Regional Director" is a prestigious title, but it certainly is no where near "Turing Award Recipient." And from reading some of their books, even those folks qualify their statements of fact.

In a number of cases, the authors did provide a reason for the "magic number" they chose. For example (and I do not have the book in front of me), they said to not have more than 64 local variables per method. The reason they gave was that the JIT compiler has to use a less-efficient method of allocating memory. Fair enough, but this is the wrong primary reason to give for not having more than sixty-four local variables per method.

Let’s think about that for a minute. Do we really want a developer to think, gee, I’d love to add a sixty-fifth variable to my method, but that’ll just kill JIT performance. What the authors should have said was that managing sixty-four variables in a method make code hard to fricken’ follow. Harder to follow means more bugs. Had the authors bothered to look at nearly forty years of computer science research, they would have discovered that maintainability vs. bugs vs. speed is the subject of many, many studies.

Francesco Balena’s response my criticism on his focus of speed was:

"[M]ost of the techniques you consider as questionable can make your code run faster by at least 50%, or more. If the offending statement appears in a tight loop they can save you a significant amount of time, not just a few CPU cycles. In a server-side component this sort of optimization makes the difference and can positively affect scalability - I am surprised you missed the point.

I respectfully disagree, Francesco. You missed my point. The book is targeted not towards the gurus and experts, but towards the beginner and intermediate level developers. For this I will quote the two rules of optimization from M.A. Jackson (Principles of Program Design, 1975):

Rule 1. Don't do it

Rule 2. (for experts only) Don't do it yet.

Catch the date on there? Even in 1975 experts understood the problems with the authors’ line of thinking. Believe me when I say your customer would prefer code that works to code that saves forty nanoseconds out three milliseconds. Yes, tuning and optimization is important, but it is not an appropriate theme for a book with this target audience.

This is exactly what I was thinking when I described the book as "dangerous." If it had a different title, I’d give the book a "C" rating and say it’s "okay." But as a "Best Practices" book, it will encourage developers to think about "is it good for the JIT" instead of "is it good for my predecessor." I’ve seen code like that. I’ve seen the cost of code like that. Believe me when I say it’s not pretty.


  • Hey, your own books are very low

    on quality too.

  • > Yes, "MSDN Regional Director" is a prestigious

    > title, but it certainly is no where near

    > "Turing Award Recipient."

    Do you really want to see Turing Laureates writing .NET guidelines and best practices?

  • Any "best practices" book, or indeed any set of guidelines, inevitably will include contentious points. So will have more than one "bad paragraph" in the eyes of some beholders. Therefore I think you're wrong (dogmatic of me I realize) to judge it on a "higher standard" than other books: if it didn't cover any contentious points it would be too bland.

    And I wouldn't want a pragmatic book for beginner and intermediate developers to reference research like some academic treatise.

    But you've intrigued me enough to want to see this book!

  • I read a first preview of this book (written in italian language) and on page 4 of introduction the authors write that the book is not for the inexperienced developer and i agree with them.

    A best pratices book publishies the author's experiences (20+20 years in this case).

    The reader have to choice what to do, for that he have to be at least a project leader.

    I think the book can became a reference for a project, also if it contains some errors because is more quick and easy to adopt a standard (with some small errors) than create one on your own.

    It's more easy to write a note to correct what you don't like.

    May be you can think to write a similar book with less errors.

    Well do it !

    Some problem to find an editor ?

    Balena and Dimauro had found the editor in about 1 minute (i read it in the introducton).

    How many time do you need ?

    What about your credibility ?

    "such a book must be judged on a higher standard than others" you said.

    What about the level of reviwer ?

    How many enterprise projects did you managed ?

    Hown may softwar engineers did you lead ?

    Some times the suggestions contained in the book are not original, i understand don't use a primary keys that have meaning for the end user after my first project as DBA, but, of corse, not all did that job.

  • Maybe the differences stem from their priorities: "robustness, security, scalability, efficiency, usability, code reuse, extensibility, maintainability, interoperability, ease of development".

    And in that regard, I'd agree that their priorities are pure unmitigated evil. :)

    The priorities, IMO should be: maintainability, extensibility, ease of development, code reuse, and security.

    Robustness is a factor of maintainability and extensibility in my mind. So it's a little out of place in this list I think. If it's truly extensible, then it should be easy to scale/tweak when the time comes, so performance is *never* a design goal for me. The flexibility in the design to accomodate possible performance tweaks (among other things) is. Ease of Development is a big plus, but it comes far behind a robust design unless it's throwaway code. The level of code reuse can be an indicator of good design I think, but an extreme devotion to it can lead the more fragility if you aren't diciplined. The DRY principle should only be applied to a feature level IMO. Once you start using code outside of it's intent just because it does what you want right now, you start leaning in the direction of static libraries and tight coupling. At least I do. Security is a process of review IMO. Some say you have to design with security in mind, but I don't believe in that. Security "solutions" are generally "fixes" to issues found in testing in my experience. Important for projects that need it, but many don't, and the difference between a hardend application, and one that isn't, doesn't have anything to do with the overall design IMO, more the implementation of a few choice interfaces to cross-boundry resources, and diligent testing.

    I think that from the comments there's probably a lot of good in the book, and I'm looking forward to reading it, but I think that until your own priorities as a developer are solidified, this book could be very dangerous.

    Disclaimer: My opinions are my own and that of the invisible little green men that beam them to me. :)

  • God Alex, how dare you review a book you read, applying what you know and your opinions to the material, and let people know what you think? Why would you ever do that? You deserve to be attacked from all angles for it. Hang your head in shame.

  • Man, you need to get laid and relax (I do too by the way, so I'm not criticizing). Good points, but take it easy. Just b/c Baleana and Dimauro use absolute terms/phrases like "always, never, don't, it is essential" doesn't mean there's not allot to learn within the pages of this book. (I wonder if the Italian version contains more nuanced terms? It is possible. Writing in one's own language is difficult enough) Regardless, while I haven't read much yet, the little I have contains much value and my copy of the book already has several dog-ears and underlines.

    Personally, I bought it because they tell you "why" they make their recommendations, thereby arming with reading w/ more information to decide whether or not he or she wants to take any particular guideline to heart, determine if they're making a specious claim or are just plain making arbitrary recommendations.

    For me, understanding the processes of their reasoning (whether specious or not) is an exercise that helps me learn more.



  • Francesco,

    Quick reply, since I don't know if this will ever be read by anyone being that it's a comment.

    I really appreciate the personal replies. I do realize that my review was harsh, and I still do feel it was warranted. I have, however, reworded my original post on credibility.


    I picked apart your book and looked for the detail. The examples I made I did not take out of context. The <%= %> thing you did not have a left and right way, you said "do your title like this." You offered no other way. And frankly, your way sucks.

    Target Audience:

    On the scale of Beginner, Intermediate, and Expert, your book is target more towards the first two. Beginners (especially to .NET) will look towards the best practices book.


    THis was not an ommision to twist the trut. The quote from the docs does nothing to explain when you should (multi-threaded exiting) and shouldn't (response.redirecting) use the exception. It was on the whole useless.


    It's the fact that you make it a high priority in your book that gets to me. When you speed is on the developers mind, it leads to crappy code. Plain and simple. This has been known for 30+ years now.

  • Thanks for replying Francesco:

    You explanation of what you mean by robustness makes a lot of sense now. Thanks for taking the time.

    As far as security, I'd disagree if it's not a requirement, I don't think the impact on the code base should be that large with a well thought out design.

    I'm still looking forward to picking up the book when I find the time. :)

  • >Believe me when I say your customer would

    >prefer code that works to code that saves

    >forty nanoseconds out three milliseconds.

    >Yes, tuning and optimization is important,

    >but it is not an appropriate theme for a book

    >with this target audience.

    Sorry, that's just moronic.

    If one has a function that is called some million times per second, optimization *is* important. That's like decoding base64 in an application. If you decode some GBs data per minute (and that's it), you won't want the customer to pay for an extra server because your code is so god-damn slow.

Comments have been disabled for this content.