Seriously.

 

Thank you!

Signed,

-The Greatest Architect You Know*

* that would be yours truly

** and yes, I use TDD

"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

 

Mark down August 7th as the day all of your prayers have been answered. 

1) Microsoft is piloting a brand new track at TechDays!
2) The track is about Developer Foundations, and yes, it *is* about what you are *hoping* it's about!!
3) Not only is Justice Gray involved, but he is the track co-chair!!!
3) The other track co-chair is adult industry legend, Peter Ritchie!!!!
4) And yes, you do need to put your pants in the laundry!!!!!

I have been so excited about this announcement that I ran around Vancouver all day yesterday randomly punching people in the face while I screamed "Developer Foundations" at the top of my lungs.  And trust me, after you attend our track you too will be punching people left and right.  In excitement. 

As if all of this wasn't overwhelming enough, you'll likely have an aneurysm once I reveal that

these are not regurgitated TechEd sessions - they are all-new original content being created by myself and Peter Ritchie, with input from the speakers involved! 

Not only that, but Peter and I have unprecedented leeway in determining the sessions themselves!!!  The tracks are going to be announced very shortly but I wanted you to be able to read this announcement without needing to call an ambulance.  Trust me when I tell you these sessions are going to be everything you have ever dreamed of!!!

This track is going to be piloted for TechDays this year at the following locations:
Vancouver - Sept 14-15
Toronto - Sept 29-30

Unlike the other tracks, this track will be 4 sessions and repeat for both days.  Microsoft, Peter, and I feel strongly enough about the content here that we want people to have an opportunity to attend as many of these sessions as possible.

This is really an unprecedented opportunity for the community - if these tracks are well-received there will be more foundational tracks at TechDays in the future, and in more cities.  Therefore, I am asking you to do me a favor - spread the word about this.  As one of the guys in charge of the track content, these tracks being well received is a foregone conclusion.  However we also want these tracks to be well-attended and that is where you come in!  If you care about having foundations represented at future TechDays, I beseech you to let people know about this stuff, particularly when the track content is announced!!!

If you doubt me now, I can tell you as one of the guys in charge of the content that it is going to be everything you ever dreamed of, whether you are a speaker or an attendee!

Thanks to Microsoft, John Oxley, John Bristowe, Joey deVilla and more for listening to the cries of thousands in adding this track, and listening to the cries of *millions* in involving me with its creation!   BTW, if you *are* interested in being a speaker at part of history in the making, give me a shout and we'll chat!

It's always nice to be reminded that Justice Gray doesn't just influence individual developers, but in fact also determines the direction of major corporations.  That's the other big message - aside from the one in the post title - that Microsoft has given the industry, by showing everyone that Office 2010 has been written entirely in Javascript!  That is right, Silverlight now joins the ranks of other hallowed languages/applications like J# and Visual Sourcesafe in the realm of "things that Microsoft produces but has no intention of ever actually using themselves".  Let's think about that for a second:

if you are developing with Silverlight, you are using the development equivalent of Visual Sourcesafe, only with a marginally better ability to show demos of animated spinning balls!!

Looking at this from a longer-term perspective it's obvious this was always bound to happen:

1) Microsoft does a bunch of public demos about "Silverlight is the greatest thing ever because who really likes to learn about a key language of the development area you're working in!  I *hate* pesky learning!"
2) Justice Gray attends said public demo and posts an impassioned defense where he reveals Javascript is the greatest development language ever, aside from the unfortunately unreleased Justic#
3) Microsoft's Scott Guthrie has a heart to heart with the framed picture of Justice Gray on his wall
4) The ASP.NET MVC team reveals they are bundling in JQuery
5) Microsoft reveals Office 2010 is all Javascript all the time

Can a public Silverlight book burning at the next major industry conference be all that far behind?

I'm sure some of you feel that I am being unkind to poor, downtrodden Silverlight.  To be fair, I am sure that maybe there is a large market for apps that rotate an image of a swan multiple times!!! 

Sorry, I guess once again my ace hacking abilities have destroyed an entire industry vertical.

Look, we're all friends here, and because no one is your best friend like Justice Gray, I am imploring all of you who are "developing" or whatever you call what you do in Sliverlight...just come back to do real man's web development before you're unemployable!!!  It's not too late!

• This blog's underlying architecture and feed location*
• Correspondingly, your LIFE.
  

A short list of things that will need to be changed forever as of July 13, 2009:

• Your underwear

That is all!

* relax, I've got a 301 set up because I am an ACE HACKER

I had some spare time tonight and against my better instincts I decided to read some technical blogs.  It turned out to be quite a historic night for two reasons:
a) I was introduced to the concept of something called "The Sharepoint Knights". 
b) It marked one of the only times in my life that I wished I was functionally illiterate.

Sharp observers will realize that these two reasons are (like 75% of the married couples in Winnipeg, MB) strongly related.

Some of the ways *you* can be under consideration for membership in the Sharepoint Knights include:

• User Group Management
• Conference Speaking
• Getting Regularly Beaten For Lunch Money
• Never Having Intimate Relations With Another Human Being
  

I know a lot of you out there have leaned over to your cube-mate to excitedly proclaim, "Hey, I think I qualify on all four of these!!" and are anxious to hear a little more about this undoubtedly prestiguous group.  Here's some notes from the initial announcement:

"Some might compare it to the MVP program, but it's much more behind the scenes.  It isn't used to promote your skills more than it is to help share information amongst the group and to help each other and the community.  The SharePoint knights do recognize each other for their skills and boost each other up.  The knights are made up of Devs, IT, and PM and Business Analysts.  Male and Female alike as in the Jedi Knights."

I'm glad this was laid out for me, because I know that when *I* am trying to determine if a group is an elite representation of industry professionals, I *immediately* ask, "Do they compare themselves to concepts in STAR WARS???"

But don't worry, it gets better.  Way better!!  Apparently if *you* become a Sharepoint Knight you will also receive "An unique ranking Knight icon to put on your business card, blog, site that sets you apart as a Knight who provides a service of SharePoint chivalry".  Sharepoint chivalry.  Seriously.  Can you imagine explaining this icon to a business client over the age of 12 without them laughing you out of the office?    

I have heard some rumors that the next Sharepoint Knights summit will figure 20-sided die rolls for that coveted Charisma+3 bonus.  Unfortunately, I will probably never know for sure because I am not and never will be a Sharepoint knight.  Yes, let's be open here - by virtue of:

• this post
• not having a life-sized replica suit of armor at home
• having hobbies involving the outdoors

I am disqualified from contention.  It's entirely possible that if *you* have ever kissed someone with tongue, *you* can't be a part of the Sharepoint knights either.   I know, I know, "Justice, if I can't be part of the Sharepoint Knights,  how will I ever have a chance to be part of a group of pasty middle-aged geeks shunned and feared by regular looking people of society?" and to that my friends, I can only say that the Microsoft MVP program brings in new people twice a year, so there's still hope!!    Keep chasing that dream!!

 

Apparently there are some WebForms lovers in the ASP.NET community who love the technology soooooo much that they were "not without a tinge of anger" when discussing the situation at PDC with Phil Haack, the program manager for the Microsoft MVC.  Can an online petition a la the oh-so-successful "Keep VB6 around because I'm tired of learning new stuff" be far behind? 

I had to laugh when reading the post, and not because of the image of a legion of "professional software developers" standing in front of Phil, looking down at their feet, hands in their pockets muttering, "If you don't stop progressing the industry, I'm going to burn my pocket protector".  No, I laughed because I know how Phil Haack *really* feels about WebForms development despite his public stance.  Let me share with you a heretofore-*confidential* exchange between myself and Phil:

From: Phil Haack (haack420_ForLife@Microsoft.com)
To: Justice Gray [E-mail censored because I get enough unsolicited offers for sexual favors]
Subject: I need your advice
So there was a homeless guy wandering outside the 7-11 tonight and what a sob story this guy had.  "Excuse me, sir...but I used to have a job doing ASP.NET WebForms development..."  I didn't even hear the rest of his sentence but when I heard the word "WebForms" I just snapped.  Kicked that dude in the nuts *17 times*, poured a can of gasoline on him and then SET HIM ON FIRE, yelling,
"Burn!!!!  Burn like the careers of everyone who still does WebForms development!!!" 

So do you think I went too far?*"

I had originally sent this E-mail to the local authorities but the Seattle police simply told me that they don't have the manpower to handle the sheer outbreak of people crying their eyes out on the streets about
a) how they do WebForms development
b) they feel "betrayed" by the very *existence* of the Microsoft MVC
c) they fear change.  I don't mean the change people throw at them while yelling "Get a *REAL* job" either.

There's not really much I can say to this reaction.  We talked about it briefly a couple of months back when "Mr. Drag and Drop" GridViewGuy dropped by Rob Conery's to say, "BOOOOO HOOOOO TESTING IS HARD STUFF, hold my hand so I can start doing competent work".  There's pretty much no way I can possibly relate.  What I can tell you however, is that if you like sleeping on a bed of money, you should learn the MVC.    If only you knew how much people like me make cleaning up WebForms projects gone wrong!!!  With every half-assed DotNetNuke implementation I save somebody from, it's another *10 billion dollars* in my pocket.  Hey, to all of you people soiling yourselves because WebForms is dying: maybe some of you suckers should spend less time doing this:

and more time doing this:

[this is not a joke, despite how it may read at first]

then you *need* to go see Scott Hanselman's presentation, "Microsoft .NET Framework: Overview and Applications for Babies" *tomorrow*, Monday the 27th of October, at 5:15 PM in room TL49.  You need to see it, and when it blows you away, make sure you provide good ratings and feedback for the presentation.  Hell - listen, if you're *not* at PDC, find some way to submit feedback anyway and make sure it is 10 out of 5 stars or whatever ratings scale Microsoft uses for these things.

Scott has given an overview of this presentation before, but in case you're too lazy to find it by clicking on the link, here it is again:

"Join Scott Hanselman for this lots-of-code-minimal slides talk that walks through the sheer joy of building out a .NET Framework application with Visual Studio using many of the new advances in the .NET Framework 3.5SP1 and 4.0. We have a data layer with Entity Framework, use REST web services with WCF and ADO.NET Data Services, write an ASP.NET site for reporting using Dynamic Data and MVC. All the data will come from a WPF client application and a Silverlight application that the audience will run live! All this, plus it's an application that babies and toddlers will love!"

So what makes this presentation great enough for me to interrupt my *own* self-promotion to highlight someone else? 

a) Scott's presentation is not yet another Northwind-based demo*
b) Scott's presentation is a highly original usage of the .NET libraries and thus stands a very good chance of being *memorable* and having a lasting impact on those in attendance
c) Scott is a Microsoft employee.  For those of you who read the first two points and thought, "Big deal, Justice, you did a presentation on MS MVC that explained the MVC pattern in terms of Steven Rockarts' drug addiction" I'm not an employee of MS, and thus not subject to Microsoft's cardinal rule against being interesting.
d) I know how Microsoft works with these things, and if Scott's presentation is the blowout highlight of the conference,there will be leverage for *more* original presentations, *better* presentations, and ones that actually can *teach* people via unforgettable impacts.  Who actually goes to a Northwind demo and actually *remembers* what they saw?

This is *your* chance to be an influence on Microsoft's future direction!  Previously, the only chances you've had to be part of a zeitgeist moment in the software development industry have been:

• shaking my hand
• seeing me wave at either you or someone behind you from a distance

Scott's presentation, believe it or not, may be an even larger moment than the above.  Please, I am begging you, if you have a chance to see this thing, *attend it with all of your might*.  It might be our only opportunity as a profession to free ourselves of Microsoft's Northwind-based demos and moving on to something meaningful!!

* Seriously, I legitimately dream of a day when the statement "This was the strangest Microsoft talk I could sneak past the bosses without them noticing" isn't something that needs to be said, even *half*-jokingly.  We've made some progress but we've still got a long way to go.

Trust me.  I've been there, I've felt that pain, I've even debugged the NHibernate source to figure out what the heck was going on.   Please, I beg of you, tell my tale to those who ask, tell it truly...and let me be judged accordingly!  And let me tell you, this Hamlet quotation is appropriate because going through this problem will make you feel as if your mom just slept with your uncle.  Do I take NHibernate difficulties too seriously?  Maybe.

Anyway, some of you NHib rookies out there might think that if you have an enumeration, it's easy enough to just map it to an int for DB storage, like the following:

namespace J
{
    enum JusticeCharacteristics
    {
        Sexy,
        Sultry,
        Seductive,
        *Sassy* // This is fake code homeboy!  I can use whatever characters I LIKE!
    }
    
}


and then in the mapping file put the following for a class using the JusticeCharacteristics in a property called "Characteristics":
<property name="Characteristics"
              column="JusticeAppeal" type="Int32" />

Bold in this case stands for THIS WAY LIES MADNESS.

You see, when you do something like this NHib tries to map back and forth between two different types - the moment you retrieve the object from the database it is marked as "dirty" and thus you will get an automatic update call every time you close the NHibernate session.  Trust me, nothing is more confusing than profiling your application and noticing that you've got random update calls firing every web request!  Certainly a very confusing and time-intensive operation, made quadruply so when a himbo like myself is trying to figure out what destruction our team has wrought! 

The solution to this problem is actually pretty simple - just use the enumeration type as the mapped type:

<property name="Characteristics" column="JusticeAppeal" type="J.JusticeCharacteristics" />

Italic in this case stands for YOU ARE NOW AN NHIBERNATE NINJA.

Given the skew of the audience that reads this blog, I fully expect:

• 99.999999999999999% of you read this post and thought, "Thanks for sharing something completely obvious" (trust me, it won't be the first time)
• 0.0000000000000001% freaked out and raced to their production application and now have me to thank for saving their system performance
• one of you doesn't even know what NHibernate is, but that's okay Dad! I'll explain it to the entire family over dinner this Christmas!

[Update: For the curious, Ben Hart has an explanation of the casting issues that cause this over on his blog.]