"On behalf of the industry and the English language, we apologize."
-Brownfield Application Development in .NET, page 269

For the last half of a year I have had a monkey on my back, and today is a blessed day because I've finally set that monkey free, because I finally am posting my review of Brownfield Applications in .NET. 

Here is the short review of this book:

• I asked Manning before writing this review if the book had gone through editing and was assured I had "pretty close to the final version".
• Manning is a patient publisher who has been waiting several months for me to provide this review, so I vastly appreciated their indulgence
• Kyle Baley is a great man who loves his wife and children

There you go.

You'll notice the short review doesn't dwell too much on the whole "book" part of "book review", and that is because Kyle Baley and I are friends.  In fact, despite his public plea for public feedback, no matter how negative, I would implore Kyle to perhaps stop reading this post now and simply remember we are blood brothers for life no matter what happens. With that said, let's get to the *real* review for this book; I'll start with the negatives and finish with the positives so that everyone can leave happy.  But before we start I want you all to know one more time that I love Kyle like a brother and he is a fantastic person and software developer.

For want of an editor

At the beginning of this post I mentioned setting my monkey free.  Hopefully Manning can follow my example and set the monkey who edited this book free as well.  I'm not even talking about the general cohesiveness of the book, which has issues we will discuss later.  As a disclaimer, I do not feel it is too lofty or unrealistic to expect that the responsibility of "editor" includes catching and correcting things like:

• 2nd grade spelling mistakes
• sentences that aren't sentences
• paragraphs that end in mid-sentence, never to be finished, e.g. "This also helps your code's 'reversibility'.  That is, any changes you make can easily be backed out.  This may not sound like [abrupt end of paragraph]."  Er, like *what*?

If you disagree, please unsubscribe immediately as you are unlikely to agree with anything I say, ever.  Just to head any wiseacres off at the pass who want to start correcting my own grammar and spelling, please keep in mind that I'm not charging you to read this post*!

To be fair to the editors, I'm not sure whether the overall cohesiveness is an editing problem or simply the difficulties of co-authorship.  Early chapters assume the reader already has a background in certain topics and then subsequent chapters treat the same topic as if this is the reader's very first time ever seeing it in print.  This is particularly noticeable when it comes to the discussion and "introduction" to Design Patterns after they've already been discussed 1700 times previous, or the assumption in 7.1.6 that everyone knows what the Adapter Pattern is before we are "introduced" to it in Chapter 8. The book's stance on datasets swings a bit from "not recommended but we can see how they are used in certain situations" to "datasets are eeeeeeeeeeeeevil we hate em WE HATE EM WE HATE EM".  As I'm familiar with both of the book's authors and styles I can pick apart who is saying what, but for someone who isn't that familiar (read 99.99999% of this book's hoped for audience, I would assume) the overall message comes off a bit confusing.

The unit testing/CI/IDE conundrum

Nowhere near as confusing, however, as the stance the book takes regarding automated builds, unit testing, and debugging in the IDE. Page 81 (Chapter 3) states:

"There is one thing that you should be aware of when moving to a project/solution structure favoring a scripted compilation.  It is possible that you will create a structure that no longer allows for direct running and debugging in the IDE.  With Visual Studio this would mean that you may no longer be able to hit F5 and step into code with the debugger. For some developers this will be a major friction point in their personal development process (code, debug, verify, fix, repeat). For others, the transition to relying on automated tests to do their debugging and verification will be more fluid."

The book then goes on to strongly imply how awesome and 1337 it is for a team to only use automated tests to debug issues and that hey, you're a rock star for breaking free of your IDE chains.  Yee haa, everyone's happy, except the guy that actually reads beyond Chapter 6 and gets to this little part in Chapter 7:

"the reality is that unit testing might not be possible"

Why in the world would you recommend a process that potentially you can't accomplish if you can't rely on unit tests in the first place?  This gets even weirder when you read the reference to TypeMock in Chapter 10 that talks about it being able to "test the untestable" but provides no explanation or examples as to how it works.  Wouldn't it have solved everyone's problems to just show how TypeMock could get around some of this "untestable" code and thus allow you to justify your breaking the IDE build to the remainder of your development team?   By the way, if you think it's weird that TypeMock's first real mention is 7 chapters after the chapter on - you know - testing, you're not alone.

More detail please

TypeMock is not the only subject given "short shrift" in this book either:

• 7.2.2 has talk of fluent interfaces but it amounts to "fluent interfaces have their place, and when used appropriately..."  So when *is* it appropriate?  The book apparently doesn't know because they don't offer any guidance in this area, so I'm honestly not certain why it was even mentioned.
• Database migrations are referred to but in a book that is full of detailed examples on how to set up a NANT script apparently there's not space enough to explain this concept to a reader.  If someone is that new to the very *concept* of a continuous build why would they be familiar with this?
• Why bring up Presentation Model but provide no examples?
• Discussion of user interface based testing was superficial and non-commital
• Since it's likely most people's questions around the Presenter would center around Event Handling, why is there no exploration of this?
• pg. 262 - "You'll need a separate layer to translate between domain objects and DTOs.  Don't worry, it's not as arduous as it sounds."  Obviously not arduous at all since the book offers no explanation as to how this would be done!  This is strange considering the Layers chapter assumes the reader is fairly new to many of these concepts.

Less detail please

Likewise there are other places where things could've been cut, such as the code example in Chapter 10 that is shown once in the context of "here's some bad code" but is strangely *not* used when examples of refactoring are provided; why include the example at all if you're not going to do anything with it?

The great debates

As a book that also wants to advocate certain practices I think its arguments (aside from the unit testing ones) are specious:

• pg. 301 - I agree that business logic should be in code rather than in the database.  However, while addressing the fact that some business logic is in the hands of overprotective DBAs, it would been nice to see some harder evidence that this is a bad idea.  This felt more anecdotal than anything based in fact.
• 9.3.4's discussion on SRP and class explosion is pretty lacking.  Yes, I use Resharper just like anyone should but the argument of "overall inefficient navigation is a sign of a problem with your tool: Visual Studio" is a terrible and gross over-simplification.   Perhaps some better advice on how to structure class files to aid in navigation or a balanced discussion on SRP would serve the purposes a little better than an argument that boils down to "Your IDE sucks, go spend some money."  How would this argument play out in real life?
  • Dinosaur Dev, 10 years on the project: "Hey, I think this new structure is a little confusing, I can't really find anything anymore"
  • Dev 2, a couple of months on the project: "That's Visual Studio's problem, not mine!  Go get Resharper"...not too convincing.

The recommendation of Resharper also assumes that the developer has that sort of purchasing authority and installation authority to make that decision, which is *definitely* not always the case.   What happens if they don't?  I think going to a boss and saying, "We need to spend $300 per developer because the new guy restructured our file solution to the point we can't work without it" is a tough sell.

The elephant in the room: development management

 

I will be open and say I had a big philosophical problem with the whole concept of "don't worry about breaking your IDE's ability to do builds, rely on the unit tests".  I think that is laudable but it doesn't recognize the friction that *also* creates for a development team that may need to be educated towards even the concept of automated builds.  This sort of thing feels more like a "scorched earth" approach to developer management that is at odds with some of the messages in the first chapter of the book.  And speaking of development management...

I recognize that working to change developer/development team management is not the focus of this book; it represents the *technical* "how to get there", not the *political* "how to get there".  There are a wide variety of different factors that come into play when introducing these ideas; I would've sooner that the book devoted a full chapter to it (not the superficial talk of it in the first chapter) or simply not talked about it whatsoever.  To be fair, I don't know that
a) managing software developers and effectively dealing with technical office politics are subjects that either author has a lot of experience with
b) that these *are* subjects the authors should be well-versed in, considering this is largely a code-based book

I think this is why writing about brownfield development is difficult: there are a wealth of political issues at play when a project *does* get into this sort of sorry state, and its handling of those are oftentimes what a developer needs to be able to do in order to make significant change.  Compounding the problem - what to actually tackle?  The technical topics are so broad that if you focused on everything to the depth it required you'd need a book series rather than a book. Perhaps Manning should consider re-branding some of its other books together under this topic umbrella and linking them as a set?  I think this difficulty definitely shows itself when reading the book.

In search of an audience

Lastly, I'm just not sure who the audience is supposed to be for this book.  Is it senior consultants who are being brought in with decision-making authority?  Is it, like chapter 1 postulates, developers who are new to the existing project that see the potential for improvement?  If it's the former, they likely already know quite a bit of what this book has to offer.  If it's the latter the way the book handles introducing topics is really confusing as compared to dedicated books on specific topics, and - like the Resharper example demonstrates - there are some assumptions being made about the level of authority that person has that aren't true in most cases. 

All right, now that I've gotten all of that out of the way, a brief focus on some of the good points about this book:

The good

• Like I said before, Brownfield is a difficult topic to write about - this book is at least, well, a book on brownfield!  Are there really many other books like that in the development space right now?  The closest thing I could think of was the old Mike Gunderloy book "Coder to Developer" but that struck me as *very* focused on dev and not so much on maintenance dev work.
• Totally agreed with "Any process that impedes the forward motion of a developer should be rethought, reworked, replaced, or simply eliminated"
• Arguments in favor of unit testing are good and of use to anyone trying to convince their management it's a good idea.
• I strongly agree with The Zero Defect Count philosophy as espoused in the book. Great thing to share with your team.
• I like the Layering chapter.
• First time I've seen a book aside from Fowler that differentitates between Supervising Controller/Passive View
• Kyle Baley is a great and wonderful man who I respect

Guidance

So should you buy this book?  On its own merits?   Maybe for the Layers chapter and the arguments on unit testing, but otherwise I'd probably lean slightly towards no; at least not until it goes through some more significant editing, and if it Manning doesn't think it is worth at least that, then Manning has basically told you it's not worth your money!   If it is tightened up I could see it being compelling at least as an introduction to the more important concepts a developer will deal with in their career, sort of a "Coder to Developer" for the consultant set.  It also *might* be worthwhile in its current form provided you only use it as a vague guide to branch off into more detailed explanations/tutoring with a developer, but at that point I'd probably just recommend a different set of books.  

However, on the principle of this being Kyle Baley and Kyle Baley being an awesome human being, for sure, give him as much money as you can.

Obviously as long-time readers know I am familiar with both of the authors of Brownfield, so the book having this rough edge was a bit surprising to me.  There are certainly some flashes of great things in here but I think the overall content needs a bit of touching up and some focus on what audience is being targeted wouldn't hurt.  However, as Manning has said this is presumably the final edit so it may be too late for this edition.  However, I *definitely* look forward to seeing what the authors of Brownfield can do as individual authors - and with some tighter editing - in the future!

* although I should

Buy this book now!  Don't buy it because it's well-written and full of great advice.  Don't buy it because it's Dave Thomas' greatest creation since the Spicy Chicken Sandwich.  No, buy this book because you'll be paying a paltry $30 US for at least *two months* worth of blog content you can repurpose!   That's *50 cents US* per blog post! Heck, write your own book, swipe most of its topics, and make even *more* money!  You've seen how lucrative the book industry is!!  Have you wanted to look like an expert in your field after a paltry 1/6th of a year?  Then this book is for you!

I wasn't half this enthused when I first read The Pragmatic Programmer.  The book itself is a quick read with approximately 70 tips for becoming or continuing to be a successful software developer.  However, if you've read technical blogs for at least 3 months or taken a look at similar books in the field, you'll quickly realize you've read it *all* before.    How many posts have *you* read about "No Broken Windows"?  "Refactor Early, Refactor Often"?  Heck, "Care About Your Craft"?  Pretty much every blog posts something along these lines at least once in their lifetimes, and *this* blog will be no exception, except when I do you will *know* I'm liberally lifting from them and simply putting it in a sexier, sleeker, metrosexualler package! 

See, originally I thought that the Pragmatic Programmer was a waste of my money.  "Why does everyone love this book when all it does is regurgitate a bunch of blog posts I've read over the last couple of years?"  And then I found out why...because it was written in 2000!!  The Pragmatic Programmer is not the regurgitator, my friends...no, the Pragmatic Progammer is the regurgitee.  Blogs have been getting inspiration or outright *stealing* from this book for more than half a decade!  Why should *you* be left out? 

Regardless, the book is enthralling and you could pretty much read it in a day or even a couple of hours, if you are so inspired to do so.  My only complaint with the book: there's no easy reference to scan all 70 of the tips at a glance. the pull-out reference guide for the 70 tips is *buried* in the back cover of the book!!  Who's going to read through *indicia* and advertisements to get to that??  Who even *opens* back covers of books anyway, except for the admirable Avonelle Lovhauq?  Thumbs *down* for that!!

I'll warn you though, although you'll likely appreciate the advice (even if you do have a feeling of deja vu when reading), you'll likely get just as angry as I did when I read Martin Fowler's "Refactoring".  If this advice is pretty much common-sense *and* it's been around for 7 years, why the hell is the field of software development still in such a sad state on average 7 years later??   I've seen companies that were lucky if just *one* of the 70 different tips were things that their team took to heart.  

In the end, this book gets a 4/5 - for sure, I'd sleep with it at a moment's notice but reading the Pragmatic Progammer is more like sleeping with an aged, seasoned prostitute; you might've seen all the tricks before but likely they originated here.  Besides, you'll just take what you learn there, claim it as your own and then be hailed as the greatest lover in the world*! 

* Yours truly has never slept with a prostitute or *been* a prostitute, despite the fact women offer to pay him for sex ALL THE TIME**
** of course, yours truly is also happily married so put those $1000 bills away, ladies***

Now that I've gotten that negative review out of my system, it gives me great pleasure to tell you that "Working Effectively With Legacy Code" is to "Applying UML and Patterns" as a massive multiple orgasm is to a swift kick in the genitals.  Sincerely, it's that good.

Common responses I've gotten when I mentioned this book to people:

"You really need to read this book!  It is excellent."
"I really need to read this book! I hear it is excellent."
"I really need to read this book so I can write blog posts claiming all of the ideas inside as my own!"
"Reading Working Effectively with Legacy Code gets me so hot...if only you weren't married" (most members of the opposite sex)
"Reading Working Effectively With Legacy Code gets me so hot...if only you weren't married" (Donald Belcham in quite the awkward moment)

Now, if you're like me, you want to cut through all the hype and get to what really gives the book credibility: the author's physical appearance.  In this arena, Michael Feathers gets a thumbs up for being a total bad-ass - look at this photo and render!


Arms crossed in the "G's up" pose, L.A. Raiders style jacket, and that pouty scowl all tell us that Michael is ready for either a fight or a freestyle rap at a moment's notice.  It looks like the development community has found the Eminem to James Kovacs' Vanilla Ice!

If for some strange reason you care more about the actual content inside the book, you won't be disappointed either.  "Working Effectively With Legacy Code" reads like a spiritual sequel to "Refactoring", following up on Martin Fowler's guide with more examples and advice on how to get a crazy, mangled code base under some semblance of test.  There's an even larger emphasis on testable code than in Fowler's book, but I suppose that's to be expected from the guy who wrote CppUnit.  Speaking of which, don't let some of the C++ examples scare you off; there are also examples in Java and even one or two in Ruby!  The concepts in this book are useful no matter what the language, although I do think people inheriting a C++ code base might find this book even more beneficial.  I know that I felt a lot more confident about my ability to tame wild code after reading it, and I'm pretty positive you will as well, no matter what code base you're working off; well, maybe not assembly but you get my drift. 

This book is infinitely valuable for *anybody* who works with code they've inherited from others dead and gone, but it's just as useful for anyone doing "greenfield" development.  After all, most of the code you write is eventually going to become someone else's legacy code - this book will help you see ways to ensure your code is testable in the first place and a great way to expand on what you've learned from Fowler's Refactoring.   That being said, I would probably read Refactoring prior to reading this book simply to get more familiar with some of the refactorings that Feathers discusses, and *why* Feathers has such an emphasis on testable code.

As you might imagine, this book has my highest recommendation (5 stars).  This means I would have ridiculously illegal sex with "Working Effectively With Legacy Code" at any opportunity.  Heck, given the content of this book it would likely even help improve my technique*!

 

"It may help to drink some beer before trying to understand this."

"Your boss asks, 'What have you been doing all day?'  You reply, 'Logging in!' Is your boss happy?"

-from Applying UML and Patterns, by Craig Larman

I feel no shame (nor insecurity in my heterosexuality) whatsoever when I tell you that I'm enough of a fan of the Daily Grind to have a Mike Gunderloy poster in the bedroom at our home.  I can't explain how I got it without violating the terms of the restraining order so let's just leave it at that.  You can no doubt imagine my reaction when I found out that the author of the Daily Grind, a blog I've been reading almost since its inception, actually linked to a post I had written.  Sure, he used the word "infecting" in the description, but when you deal with a cold, analytical mind like Mike Gunderloy's, you take whatever scant bits you can get.  

One notable aspect about Mike Gunderloy is that he has aboslutely nothing to do with Applying UML and Patterns.  However, there are two reasons for my seeming sidebar into nowhere:

a) With his link comes some renewed pressure and accountability.  The vengeful James Kovacs pointed out that my book list reviews haven't been publicly updated in some time.   This needs fixing, so today I have posted yet another book review.
b) Talking about Mike Gunderloy is *still* more exciting than talking about Applying UML and Patterns.

Many of you have noticed that a vast majority of my book reviews tend to lean on the enthusiastic side.  This review is not one of them, despite the interesting single curl drop-down hairstyle Craig Larman displays on the back cover.  Remember this footnote from my review of Refactoring?

"There was actually *another* reason I was near death, but you'll have to tune in next week to find out the answer".

Most people originally assumed I was just courageously recovering from a head cold, but the truth was far more sinister - reading this book nearly *cost me my life*.  Nothing makes you crave death more than slogging through about a 1/3rd of Applying UML and Design Patterns.

Beginning of the book with the best pitch for agile methodologies and an explanation of what the RUP really means?  Fantastic.

Latter half of the book with a description of various patterns and how they fit into UML design?  *Amazing*.

Inception?  SNORE.  And as someone who has read through the entirety of the GOF Design Patterns book, I *know* boring.  

Now, dissing the GOF Design Patterns book is hardly that unique - in fact, it seems like these days it is in vogue to rag on the classic blue book.  However, most developers who have read "Applying UML and Patterns" seem to want nothing more than to spoon with Craig Larman and whisper sweet nothings in his ear for writing it.  As I'm not one of those people (and not just because I'm rampagingly hetero), I can see that my opinion on this book won't be terribly popular with the masses - I can recommend it, but make sure you're not expecting an exciting read.  Thankfully, the latter half of the book or so almost makes up for the plodding nature of the text preceding it.  Larman uses two main examples throughout his book: point of sale and Monopoly.  I was a little disappointed that most of the emphasis went to the point of sale, but part of this is probably my own bias towards Monopoly.  To those of you that find point of sale examples to be incredibly sexually arousing, I'm sure you'll get quite a charge out of Larman's book and I also recommend you see a doctor.

I can't give this thing ***** in good conscience, and yet I can't give it 0/5 either; it does have some useful information and I do feel as if I'm a better developer for reading it.   The first part gets a 3.5 out of 5, the "abyss" pages get 0 out of 5 for nearly ending my existence, and the last half or so of the book gets 4 out of 5.  For those of you who are familiar with my ratings scale, this is like knowing a woman who was average/cute in junior high, gained a whole bunch of weight in high school, and then started working out and became a 20 year old hard-bodied, large-breasted stripper - sure, you'd kill to make out with her now, but would you really have gone through the dark years to get there?  Recommendation to read, but skip Inception if you'd like to keep your sanity! 

This blog was relatively quiet over the last two weeks; it was not because I was fending off advances from Kathy Sierra, despite what you might expect after my previous post.  No, it was because yours truly had a brush with *death* that nearly took him out for good.  That's right, I had a horrendous cold; runny noses, sneezing, congestion -  it's a wonder I'm even here today, courageously telling my story of recovery.  I'm not afraid of death (after all, long-time readers know the kind of excitement that will ensue when that happens), but if I were to shuffle off this mortal coil, who would finish the 27 books in 27 weeks?  Who would become 375,000 pounds of ripped muscle by July 25th, 2007?  Who would be there to be that motivating force for Scott Reynolds?  More importantly, who would continue the long string of Donald Belcham jokes that have put igloocoder.com on the map?  Thus, I struggled valiantly to recover but all seemed for naught...until I chugged 1 or 2 L of extra strength Neo Citran and opened up Martin Fowler's Refactoring. 

"Refactoring" is not a book you read expecting to be angered, and its not a book you read expecting to have the room spinning around while your bed flies through the air.  However, that's exactly what happened to me as I opened its pages and read the story of a scrappy young Martin Fowler and one of his many contracts.  It turns out that Martin was on a project that required about 6 months worth of refactoring.   Martin then brought this information to his superiors.  Sadly, not even his terrifically groomed facial hair could convince his bosses that this was a priority.  Martin's advice was ignored with a "There's no time, we're committed to schedule".  One year later, the company in question ended up having to do a complete rewrite of the now unmaintainable software while Martin faced down a giant metal monster with a furnace for a mouth that was threatening all of New York City, or something like that; I don't really remember the minor details.  C'mon, I was gravely ill!  I'm just lucky to be *alive*!! 

The rest of the book catalogs different code "smells" that creep up on a project (pretty much anti-design patterns) and then the various refactorings that can fix them.  There's also a discussion of when to use refactoring and when *not* to use refactoring (yes, there are times).  These come complete with other examples of engagements that Fowler had, including the time Martin solved the mystery of the Flying Dutchman and the Revolt on Dimentia 5.  While I know this outs my inner geek, I have to say that even without some of these anecdotes, I still consider Refactoring to be riveting reading. 

As I alluded to earlier, reading Refactoring made me angry.  I'm not angry because I can't grow a 1970s style beard like Martin Fowler can; after some therapy I can safely say I've dealt with my lack of facial hair and put it past me.  No, I became angry because some of what Fowler writes, to me, is *common sense*.  Naming methods appropriately?  Embracing code reuse?  Come *on*!  But I'm not angry at Martin - how can anyone be mad at this cherubic face? 

No, Refactoring made me angry at our industry and its immaturity.  The fact that so many projects produce code that *requires* so much refactoring boggles my mind.  Have you ever met a developer who has managed to avoid working on at least one project that was coded incredibly poorly?  I haven't.   Why is this? 

But forget about all that.  You didn't read this review because you cared about Refactoring, or because you cared about making your project better.  You read this review because you cared if I felt better.  I can report that I do - and it's all thanks to this book.  Before I started reading Refactoring, I was coughing, in fits of agony, and laying on my bed waiting to die.  Two days after finishing Refactoring, my head was cleared up.  My cold symptoms had vanished.  In their place was a renewed sense of purpose.  I felt faster...stronger...more ALIVE.  What else could have caused this other than my reading Refactoring?  Was my recovery from this cold merely coincidental?  I don't think so.  Yes, my friends, reading Refactoring saved my life.  It can save your life too, and possibily the life of your project. 

You might have noticed that this review is not dripping with the same sexual tension that...well, pretty much *all* of my previous book reviews have had.  This doesn't mean the book isn't worth your money; every software developer worth employment should read at least the first chapter.  It does mean that Martin Fowler's resemblance to a 1970s porn star interferes with any level of arousal I would have if I were not *firmly* heterosexual (and I am).  My final rating therefore breaks down like this:

Refactoring catalog - *****
Anger-provoking development tales - *****
Story about Martins battle with Dr. Noah Boddy - **********
Martin's lack of hair and giant beard - MINUS **

Total score - 4.5.  This has hopefully taught everyone a couple of valuable lessons:

• Cold medication can make any book better
• If you have facial hair you will *NEVER* be perfect.  Sorry Martin - once you shave I will change my rating to 4.8 stars.  Besides, no one likes kissing guys with facial hair, except for Donald Belcham!   Trust me, Martin - quit hiding behind that mass of facial fuzz and let the world see as you truly are.  If you follow my advice you will never have to worry about "getting some" again!**

(This is #2 of #27 in 27 weeks, referenced in my "How I am becoming a better developer" post.)

I have a massive schoolboy crush on Kathy Sierra.

There, I said it!  Whew!  It's like a massive weight has lifted off of me already.

Don't think I'm the only one who feels this way.  Steven Rockarts and Donald Belcham also think that Kathy Sierra == hottie.  The last time the 3 of us agreed on anything, the EDMUG executive became the most powerful force in the universe, so I'm pretty sure we're onto something here.  Donald has been pretty brazen with his affection (going so far as to pretty much ask her *on a date* at the tail end of a recent post...what a smooth operator) and Steven didn't mention it for fear of "falling down another flight of stairs".  I had my own reasons for keeping this secret.  Believe it or not, those reasons have *nothing* to do with my wife, the sexiest person alive and apparently the only reason some of you read this blog, according to recent comments.  She and I have agreed that Kathy Sierra can be part of my "Freebie 5", so Mrs L. and I are cool.  No, I have kept silent because this blog adheres to the highest standards of journalism.

Even a year ago, I knew that one day I would have to review Head First Design Patterns; but how could I review a book produced by someone on my freebie 5 and still maintain the complete impartiality you're used to?  So I did the only thing that I could do.  It was hard, but it was the only thing that was *right*:  I gave up on journalistic standards.

Now that I've made the ultimate sacrifice, I am telling you that Head First Design Patterns is *almost* as sexy as Kathy Sierra and is well worth your time and money.  Many of you are familiar with the thematic predecessor to this book, which goes under two titles:
"Design Patterns"
also known as
"The Most Boring Book Ever Written"

No one wants to say it, but I will - the original GOF book (though informative) is a guaranteed snooze.  In fact, the only way I ever made it through this book was by reading it on the crosstrainer at the gym so that I could not pass out.    Prior to the release of Head First Design Patterns, this was sadly the only book I could really recommend to developers for learning common design patterns.  Who wants to read a book written so academically as to almost purposefully alienate readers?  Where are the jokes?  Where is the *fun*?  Frankly, where is the *sex*?  I mean, let's take a look at the cover for Design Patterns:


Wow.  A Möbius strip, a blue stripe, and what looks like a random smear of gray paint.  I think we can all agree that the above cover was designed by someone who has never gotten laid.  

On the other hand, let's look at Head First Design Patterns:



This is pretty much the stylistic opposite of the original Design Patterns in every way possible.  It's also far more readable; this is the second funniest development book I have ever read, right behind "The Dating Experiences of Donald Belcham".   It manages to be hilarious, memorable, and informative all at once.  How many development books feature crossword puzzles and "head-to-head" interviews with the Decorator and the Proxy nearly coming to blows?  Heck, how many development books even feature pictures??  Almost none.

As I enjoy witty books, consider design patterns to be an *essential* part of a developer's skill set, and consider Kathy Sierra to be a total fox, you'd assume that this book would get the easiest guaranteed action since Tom Opgenorth's presentation at Calgary Code Camp.  However, two things:

a) the Proxy pattern chapter goes a little too heavy into Java RMI.  Now, I don't care about the entire book being written in Java, given the book's examples are clear enough to pretty much be language-agnostic.  However, 2/3rd of the proxy chapter is spent talking about Java RMI rather than a more abstract example (such as I've seen JP Boodhoo show off from time to time). I would have preferred more emphasis on the abstract examples.

b) Kathy Sierra didn't actually write this book - she was "executive producer" (read: editor?) on this book and the credit for the wonderful writing actually goes to Eric Freeman and Elizabeth Freeman.  It's not fair of me to knock off stars for this given that the Freeman's writing is fantastic, but I need to note it nonetheless as having a crush on a couple rather than a single person made me a little dirty.

This makes the book's overall rating on my ratings scale oddly appropriate: 4 1/3 stars out of 5, much like being in a super-hot make-out session with someone only to have their parents barge in just as things were about to get good...in the end you're a little frustrated but you'd still do it all over again if you had the chance!  The Freemans have crafted an *amazing* book that is the best way to introduce yourself or others to common patterns of design, or to convince people outside of the industry that not all programming books are supremely boring.  Some people might just buy it for the cover like Jonas did - at least, that'd why he *said* he bought it.   Why would you buy a book for its cover if you're only going to tear the cover off and put it under your bed?  I don't get it.

And Kathy - if you ever want a "passionate user" to do some "pair programming", I'm right here baby*!!

* although I am HAPPILY MARRIED - I love you Mrs L**
** and apparently so is Kathy, but I didn't want to mention that and get Donald reaching for the scotch again.  ALCOHOL DOESN'T SOLVE ALL YOUR PROBLEMS BUDDY

(This is #1 of #27 in 27 weeks, referenced in my "How to become a better developer" post last week.)

Rajesh Setty (of the "Life Beyond Code" blog) didn't write "Beyond Code" so that he could seduce men and women alike.  Rajesh Setty didn't write "Beyond Code" so that a legion of ridiculously masculine men would develop ridiculous man-crushes!  Rajesh Setty wrote "Beyond Code" because he cared about software developers and wanted to help them reach their fullest potential - the rest just came as a natural outgrowth of his writing.  

I don't know what to tell you about this book.  I would almost say it was like the "How to Win Friends And Influence People" of the software development industry, but it's so much more than that it's almost insulting to use that comparison.    This book is now *tied* with "Code Complete" as a book that I think every software developer *must* read at least once - *particularly* if you are an independent consultant (and I'm a total Steve McConnell fanboy, so you know this is saying something).  Or alternatively, don't read it at all but at least put a copy of it on your coffee table the next time you're bringing a hot date home - GUARANTEED ACTION.

"Beyond Code", as you'd expect, does not have one iota of code in it.  However, what it does have is a wealth of advice on how to stand out - how to stand out to your client, how to stand out among our peers, how to stand out *period*.  While the book is focused towards independents the advice is applicable to *anyone* who is doing software development for a living and wants to transcend just being just another code monkey into something more significant.  The foreword by Tom Peters says "Read it as if your life depended on it.  It DOES!"  This isn't hyperbole.  It's not a long book at all, but it has a great idea pretty much every second page.  I've seriously not had a ROI per page this high in quite a long time of reading.  

This being said, there are some reasons you might not want to read Beyond Code:

1. you don't want to threaten your marriage or relationship by introducing Rajesh Setty and his prose into it  
2. you don't like getting aroused as you're reading software dev books, unless you're reading Code Complete
3. you feel stressed out when you are chased by hordes of the opposite sex wanting to offer themselves to you in the worst way
4. same as point #3, but substitute "clients" or "employers" for "the opposite sex"

Last week, we had a lively discussion on career security on this blog; if you read this book, take its advice to heart and truly implement it's advice, I am almost 100% certain career security is never going to be one of your problems.   Nor will getting some, for that matter!

If you are at all familiar with my scale for rating books (see the bottom of this post for an explanation), then you know that the rating for this book is academic.  No matter how depraved, no matter how undignified, there is *NOTHING* I wouldn't do with this book!  All the way for CERTAIN, even if the only thing I've have the next morning is a goodbye note on the pillow along with some scars and memories to haunt my sleepless nights!  And trust me, sleepless nights are all you're going to get after reading this! 


BUY IT AS SOON AS POSSIBLE.  Then, once you've done that, *read it* as soon as possible!

No, Donald, I'm not referring to the code you write! I am referring to one of the many things I learned from reading the pulse pounding *THRILL RIDE* of the century, "You: The Owner's Manual" by Michael F. Roizen and Melmut Oz, which is part of the series of books that includes "You: On a Diet" and "You: Ultimate Cage Fighter".    As entertaining as mocking Vista can be, I thought I'd take a small break from it to share this *vital* book review with you...before it's too late.

We start our tale of intrigue and biological espionage with a small quiz: to give *you* the chance to prove that you are a master of the human body.  Unfortunately, while I am a master of everything else in North America, my score of a *whopping* 17 out of 50 on their multiple-choice exam indicates I obviously have a long way to go.  This despite my scoring a 19.1 on their related RealAge test a year or so ago!!  I smell conspiracy.

Regardless, I'm not bitter about this in the slightest; for in the end, I learned a *TON* about the human body, including:

• The reason why men can drink more alcohol than women, unless that man's name is Anand Narayan
• The reason why size *does* matter!! 
• Why Q-Tips are not for ears
• How to find out whether you have enough stamina to have sex (however, this does not teach a developer how to *get* sex, which is likely a topic needing an entirely separate book)
• the one similarity between the brain and the penis
• and *especially* for Donald, why it's okay to have regular doses of alcohol, and which ones are most beneficial (sorry, buddy, scotch is not mentioned)
• a cartoon diagram of the rectum!
• and *MORE*

I don't want to spoil all of the shock twists and surprises that this book has in store for you, but let's just say that the B and T cells have a tough fight ahead of them. 

The good:

• So much information.  I learned something new on every page, and I can assure you that this has nothing to do with my gross incompetence!
• PLAIN ENGLISH.  No obfuscation going on here, my friends.  Everything is laid out in almost 3rd grade style.  Lots of pictures so that you're not intimidated by all those confusing words!  It's almost like "Head First Human Body"!

The bad:

• the jokes, much like the pick-up lines of many developers I know, are beaten down and seen better days.

The ugly:

• No matter how cartoony you make a diagram of the human rectum, it is still a diagram of the human rectum.  That being said, I know of one bonafide rectum fan who will pick up this book for that alone!

Final word:
The book is a 5/5 - I'm ignoring all the negatives here because at worst this book will teach you something and at best it will save your life.   If only Captain America had read this book - things might have been different.  From previous reviews, you know that I would *normally* engage in wall to wall whips 'n chains with this book.  But not this time - after all, who is really into getting hot and steamy with someone obsessing over how much gas the human body produces every day?  *TOTAL* turnoff, gentlemen!  But a strong, *healthy* recommendation otherwise.

I own a lot of books.  Actually, I probably own *too many* books.  So many sit unopened, saved for a later date because I only have so many eyes, brain cells, and waking hours.  It is for this reason that my review of Bob Reselman's Coding Slave takes place quite a while after the book's release in 2004.

Given that my review isn't terribly timely, you might have read other reviews and concluded that the central message of Coding Slave is that our system of software development is horribly broken, leading to unmaintainable systems managed by undertrained, overworked developers.  Or that the solution is to form some of engineering style guild run by developers for developers, where this mystical union takes care of both training and pay, ya da ya da ya da.  *Who cares*?  You know what Bob Reselman has taught *me* through this book?  The average user persona is way too boring.

When I'm writing user personas, I don't want to write about John Xavier, the middle-aged man who is looking to track his fleet of vehicles.  I want to talk about "Albert Schulberg, aka BigDick6969" (actual character in Coding Slave) and how "his priorites are to achieve orgasm and achieve inebriation, preferably in that order" (actual *quote* from Coding Slave).  Or Ajita Ortihawamein, the sassy and scrappy young developer who will lay down with anyone and anything to ensure the client is pleased!  Where are *these* kind of people in our documentation?  I'm not telling Steve McConnell how to write, but if the next edition of "Rapid Development" had people like these in its case studies it would be a GOLD MINE.


But you're not here to listen to me rant about user stories; you want to know whether this book is worth your time and money.  Let me put it this way: if you read McConnell's "Professional Software Development" but thought, "Man, I wish this had more menage a trois scenes to engage me as a reader", then Coding Slave is *definitely* the book for you.  Of course, if you are reading Steve McConnell's books in the hopes of seeing some sex scenes, I would suggest you have greater problems to take care of before you start worrying about the state of the software development industry.

I know what you're thinking, "Coding...sex...violence...Justice gives this a 10 out of 5".  Wrong.  Yes, I definitely think that it takes some testicular fortitude to even imply that we might as well be doling out sex along with code in the future, since we're either whoring out our brains or our bodies in the end.  Please understand that there is no bias involved in the non-perfect score for this review; I've read books by hippies before, and I'm totally cool with it.  


The reason this book isn't getting umpteen out of 5 is that it takes half of the book for things to even get started.  I understand that Bob does a bit of setup here, but I felt that the sidebars on the Frank and Walt characters were unnecessary for his main points near the end.  I freely admit I could be missing something here.  I have tacked on a bonus point here for the name of the "one ERP to rule them all" on page 138.

Coding Slave is really 4 parts: 1 part violence, 1 part code stories, 1 part sex, and 1 part essay.
The depictions of violence?  Awesome, vivid, but only very brief moments in the book.  We needed a bar brawl or something!  3 stars.  
The stories re: the coding, the monolith systems, the poorly documented code?  We've all been there.  4 stars.  
The sex?  Uhm...well, I have to admit, you can tell these sex scenes were written by a software developer.  And no lines like "Let me insert my element into your array, bow wow chika wow wow?*"  2 stars.  
The essay?  Best part of the book, and this is definitely a slightly less academic way of putting things than McConnell does (I would note that there *are* differences between the two but I'll go into them in a later post, possibly).  Thanks for including "The Meno" in the appendix.  5 stars.  

Using the incredibly complicated math of adding this up and averaging the scores out, we come to a rating of 3.5 out of 5.  Those of you familiar with my previously established ratings scale know that this means it comes somewhere inbetween a peck on the lips and a full-on tongue thrashing with this book.  

Let's say that "Coding Slave" is a bit of an awkward kisser but shows potential for improvement; thus this book is still worth your time if you have a little bit of patience to get to the good stuff!!!  Recommended.