I am not ashamed to say that your hero *wet his pants* today.   In fact, on seeing the below picture again, it seems I have wrecked yet another pair.  Oh well, it's not like I'm going anywhere tonight anyway!!!

That's right, your eyes do not deceive you, Cookie Crisp is now available at Costcos nationwide.

In giant-sized boxes.

I do not know whether I need to give the Harper administration or the Obama administration credit for the biggest victory in US Canadian trade since yours truly nearly moved to Austin a couple of years back, but nonetheless I want to assure both politicians that because of this, you have my vote.  For life.

EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE

Seriously.

Thank you!

Signed,

-The Greatest Architect You Know*

* that would be yours truly

** and yes, I use TDD

Apparently the economy has forced some companies to take some bold and unorthodox steps in targeting new demographics.  I was walking home from the gym today and spotted this advertisement at one of the bus stops:

Doesn't look like anything too out of the ordinary, right?  Thank goodness you are reading a blog post written by a man with the eyes of a jungle cat.  

That's right, if you have the urge to get away from everything for a while, *and* you define "everything" as including your wife/husband and other family members, Sunquest understands!  Truly an exciting and disturbing new step in travel marketing!

Congratulations to the millions of you who simply reload this blog's home page over and over in your browsers for upwards of 8 hours a day, hoping to find some brief nugget of wisdom that will help you become as amazing as yours truly!   Here's your tip of the day:

If you are:

• 30 years of age or over
• using the term "EPIC FAIL", in any varying form of capitalization

you are embarrassing yourself.  Please, please, *please* stop.

Thank you,

-Justice

"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

Second time is the charm?

Something has been keeping me up at nights recently and that something is Kyle Baley.    This is not meant in any perverse way whatsoever, but I know that despite this disclaimer I now have to make my annual request to all of the Justice Gray/Kyle Baley fanfic-writing "shippers" out there to please put your pens down.  Forever.    All right, now that we've gotten that out of the way I can explain to you my totally rational and not at all questionable reasons that I have been tormented by visions of Kyle for the last several months.

Those of you who are only familiar with Kyle through pictures of him shirtless in a leather jacket, lying next to some other dude are no doubt confused - perhaps even *amorously* confused, and who would blame you, I am sure - about why he deserves recognition.  If you happen to be more aware of Kyle's body of work, you likely agree with me that it's a miscarriage of justice that he has been passed over four times for the most coveted award in the software development industry today, *and* not received a Microsoft MVP award either.  Long-time readers will remember that I once recommended 4 people for the Microsoft MVP designation.  Scant months later, Microsoft honored 3 of those 4 developers and the 4th was Kyle Baley.  This snub would have been easily overlooked if it had not continued for something like 17 subsequent nominations, at which point it became less of an oversight and more of - dare we say - a conspiracy.  Anyway, back to sleepless nights.

Every 6 months it seems like the internet begins its regular whine/debate about how the Microsoft MVP program is lacking credibility.  SNORE.  This debate is tired because we already *know* the MVP program is a sad mockery of a recognition program.  Why? Kyle Baley is pretty much the MVP of the entire world, yet he is not a *Microsoft* MVP.  I then realized why I was waking up in cold sweats every evening after I posted a new entry in the Winners At Life series - because Kyle Baley had not yet been a recipient.  Thus this program of celebration and recognition, designed to be the one award system in the software development and consulting industries that truly mattered, could only keep its credibility and prestige if I declared Kyle Baley the 5th Winner At Life.  This is not to denigrate the previous winners of this award, all of whom have gone on to wonderful careers in software consulting, entrepeneurship, law enforcement and the adult film industry; however, Kyle has his own unique qualifications for this award that very few can match:

1. Kyle is a talented software developer, not quite the greatest ever like the author of this blog but probably a close 2nd place
2. Kyle is a great presenter and a pragmatic thinker as this blog has attested to on more than one occasion
3. Kyle lives in the Bahamas.    If that weren't enough, Kyle works from home and has a swimming pool in his backyard.  That's right, Kyle Baley lives a lifestyle one can only dream of.  Kyle makes it sound like it's all difficult with stuff like "home invasions" and whatnot, but let's get real, the only time someone gives you a home invasion in the Bahamas is to give you a surprise hug and whisper "Thanks for living here" in your ear before taking off to share that joie de vivre with someone else.
4. Kyle is chased by other celebrities, just like yours truly
5. Kyle was once accused of being me with a clever disguise    
6. in yet another stunning similarity to yours truly, Kyle has an Asian wife.  As I can attest to, this demonstrates not only exemplary taste in women but great wisdom in general.

Before all of you with Asian girlfriends or wives bombard me with E-mails, letters and videos that:
a) beg me to make you a Winner At Life
b) offer your girlfriend or wife to me in *exchange* for being named a Winner At Life (let's remember I am happily married *and* a committed Christian)

you should ask yourselves the following questions:

• "Am I the 2nd or 3rd greatest software developer that ever lived?"
• "Do I work from home as an independent consultant and live a rebel's life?"

• "Do I live in the Bahamas or somewhere equally paradisical?"
• "Do I think 'paradisical' should be a real word rather than just one in Justice's vocabulary?"
• "Do I think Justice should be in *charge* of the world's vocabulary?"

If you are able to answer all of these questions in the affirmative, then we maybe can start negotiating.  These awards aren't candy!

Finally, there is one other reason I felt the need to recognize Kyle - I need to remind Kyle that he and I are friends.  That's right Kyle - on Monday, October 5, 2009 please remember that we are blood brothers to the end.  In fact I would ask my entire audience to remember on Monday that Kyle and I are best buddies, truly two hearts beating with just one mind but in an explosively and totally hetero way.  Why? 

Oh, you'll find out...but in the meantime, you can find Kyle either on his blog at Codebetter or on twitter at @kbaley!

"But this isn't on a Saturday!"  No it is not.  However, I am a wild man and wild men do not worry about silly things like timetables and regularly scheduled events; no, the only things men like me worry about are

1. being rugged
2. being manly
3. being ruggedly manly

The reason I am doing the next installment in this series early (or is that a month and a half late?  SHUT UP)  is for the same reason I do *anything*: Justice Gray is a humanitarian force of nature.   Recently I was disturbed to find the following twitter from someone who admires me greatly:

What a surprise:

1. Justice Gray takes a break from posting for a month
2. Scott Hanselman tells the world he is fat, curls up with a box of Oreo Cakesters
3. Microsoft releases some "Windows 7 House Party" videos that target the sought-after demographic of middle-aged women who have more cats than they do friends.

Seriously, it is bedlam out here and I can only hold my lack of posting responsible. 
      
Scott, my friend I am here to tell you that you are correct - your morbid obesity stops here, and it stops now.  And it stops now because I am going to remotely train you into the he-beast that you were always meant to be.  Trust me, following my patented advice week in and week out you will have completely transformed yourself for the better by the end of this year!  And we'll start with one of the most patented moves in my training arsenal, a little thing I call the Justice Gray Caesar Cleanse. 

Now, some of you fat slobs out there might think that the idea of a cleanse to get you ripped is lunacy.   In my naive days before I became a physical powerhouse, I would've thought so too.  I used to think the way to getting ripped was simply:
20% exercise
80% diet

but according to the good personal trainers on the Royal Caribbean Cruise Line, the *true* way to getting ripped is actually:
15% exercise
35% diet
50% detox/cleansing

Lucky for you, if *you* are on a Royal Caribbean Cruise you can even take a "cleansing class" for the low price of $300 US!!  But this post isn't about Royal Caribbean, this post is about getting jacked.  And ripped.  In that exact order!

The Justice Gray Caesar Cleanse technique, much like Tetris, is simple to learn but hard to master.  Its mystical origins date back more than a month ago to a wedding that I attended that had a free bar.  Pay attention closely:

1. Have a Caesar
2. Drink the Caesar
3. Go to the bar and get another Caesar
4. Repeat steps 1-3 twelve times
5. Use your seductive charm to get the bartenders to give you an extra-large triple Caesar
6. Repeat steps 2-3

The important part is to make sure you do this in a very short time frame.  The shorter the better - then the magic occurs!  I'm not going to go into the details of how a "cleanse" works for you readers, I trust you know how to Google for this kind of stuff but let me tell you after I got back to the hotel room the pounds dropped off.  Heck, I'm not even sure I have a lower intestine anymore and my liver probably has some issues but look, details like this don't mean a thing when you want to get jacked.  And ripped. 

Coming next week, maybe we'll discuss doing 3000 reps in a *row* of bicep curls and then bench pressing a building over your head, or maybe the benefits of drinking nothing but eggs and cream for three weeks solid - who knows, I am a maniac.   The important part is that at the end of this series, Scott Hanselman will be strapping on the wrestling trunks and posing down at a conference near you.    That is my solemn promise!!  I've even made up a special image for Scott to hang on his wall for inspiration while he becomes 600 *THOUSAND* pounds of lean muscle.

Seriously, I have tons of other things I also want to talk about other than TechDays!  Upcoming posts you can look forward to on Gray's Matter include:

• the revelation of the second Winner at Life for this week (albeit late)
• a book review that has been in the works for 9 months or so, and I can say based on the other reviews for this same book, that this one will shock you
• the beginnings of "My Life As An Architect"
• a post on "The Angry Developer/Industry Critic Anti-Pattern"
• Quite possibly the best real-world explanation of a long held development principle that you will ever see.  No fooling.
• In addition to the resumption of my telling you all why Vancouver is the best and of course, how to be a cagefighter, Christian, and a classy dresser

The best part?  I'm almost positive all of these posts are related in some tangential way.  I know: we weave some rich, complex tapestries here on Gray's Matter but you have come to expect challenging intellectual fare here and I cannot but do what my audience demands.

However for today after finalizing some content-related stuff for the Developer Foundations track, I think it is safe to tell you that you are a moron and a failure if you do not come to TechDays Vancouver.  Microsoft can't tell you something like this in their marketing - you know how corporations are - but you know they are all thinking it.  More importantly, I am thinking it.  Do *you* really want to go through life branded as a social outcast? 

To help promote TechDays, I have a new button that I've made specifically to promote this event and have included here.  I can only hope that this shows up on sites nationwide in preparation!

Microsoft, this image is yours royalty free.

Getting tired of seeing software developers lounging on yachts and sipping margaritas all day and wondering when the “good life” is coming your way? We’ll give you a hint, true software development success starts with understanding:

• How generics can be used for more than just collections
• The true power of lambdas and anonymous methods
• The ins and outs of LINQ to objects
• Proper error handling beyond try-catch-finally
• The importance of regular bathing

This presentation will give you guidance on everything else - and more - so that you too can say that .NET helped you retire by the time you were 30!

I know that some of you passed out in ecstacy at least three times while reading these abstracts.  Heck, I almost did myself and I've read over them a million times!   Let me tell you something - if you think this is awesome, you should see the presenters we have lined up.  I can't speak for Toronto yet.  However, when it comes to Vancouver, Peter and I have not put together a speaker lineup, we have put together a boy band.  And tomorrow we'll find out who these people are!!!

This is a *VERY* exciting week for Gray's Matter and by extension the software industry in general, and not just because your role model is back from a 3 week vacation in the remotest regions of the planet, places where the internet is not only a foreign concept but in fact considered to be an urban myth.   To commemorate my courageously surviving while abroad we will be featuring not just one but *two* Winners At Life in the next seven days.  That's right, everyone is a winner this week. 

Most of you know that I - along with a previous Winner At Life, Peter Ritchie - am in charge of the Developer Foundations track for Microsoft's TechDays 2009.    Many of you *also* know how Justice Gray writes presentation abstracts.  Let me assure you that the only difference between the abstracts I have written in the past and the abstracts written for TechDays is that these ones actually focus on technical content rather than the history of Laurence Gowan's music or how to get past level 116 in Chip's Challenge.  You can imagine how concerned I was when finding out that my usual style of writing was up against a foe that even I might not be able to defeat - Microsoft legal.

This is where Damir Bersinic comes in.  You see, Damir for all intents and purposes *is* Microsoft legal.  Better yet, like myself he has incredibly good taste in presentation abstracts and thus not only are the session abstracts approved, but they were largely unaltered from their originals.  This was enough by itself to earn my respect, but Damir was was not satisified with merely respect and instead went one step further to earn my undying adulation.   Here is a look at a "before legal" and "after legal" version of one of the abstracts to show why Damir is my newest personal hero and thus your newest personal hero as well.

Here is one of the Developer Foundations sessions, after legal looked at it:

Session 2: Going from 0 to 100 Dollars per Hour with the .NET You Never Knew

Getting tired of seeing software developers lounging on yachts and sipping margaritas all day and wondering when the “good life” is coming your way? We’ll give you a hint, true software development success starts with understanding:

• How generics can be used for more than just collections
• The true power of lambdas and anonymous methods
• The ins and outs of LINQ to objects
• Proper error handling beyond try-catch-finally
• The importance of regular bathing

This presentation will give you guidance on everything else - and more - so that you too can say that .NET helped you retire by the time you were 30!

Here is that same session, *before* legal.  I have noted the sentence that was chopped out in bold italics.

• how generics can be used for more than just collections
• the true power of lambdas and anonymous methods
• the ins and outs of LINQ to objects
• proper error handling beyond try-catch-finally
• the importance of regular bathing

We're not legally allowed to show you how to do that last one at this conference, but this presentation will give you guidance on everything else - and more - so that you too can say that .NET helped *you* retire by the time you were 30!

Yes, you read that right.  Damir has not only left our presentation abstracts largely intact but in fact, he has changed the abstracts to allow things that *I* found legally questionable.  If there was any doubt in your mind that TechDays 2009 is going to be a conference to remember, this should erase all doubts.  And in the unlikely event that you are still unsure, tomorrow morning the other three sessions and their abstracts will be revealed.   Go to the TechDays site and get their early bird registration while you still can - tomorrow you will read these sessions and want to go to TechDays so badly that you may likely resort to selling yourself on the street to get a TechDays registration.  Knowing the average software developers build, I can tell you that prostitution is likely not your conference-going solution - you just don't have that kind of time!