In the event you didn't follow where I was going with this post and this post, someone has written even more extensively on the same topic. Actually, so has:

• this person
• this person
• this person
• aaaand this person.

This is the future of computing. Will the IPad be that future?  It's hard to say.  But nonetheless, this is where computing is going.  You should get ready, because mark my words, the Windows operating system will someday be like the mainframe punchcard computers of yesteryear.  I don't mean horribly technically outdated - I mean that gradually the usage of Windows OS as a personal operating system will go away, and the only place you'll see Windows is in the enterprise or in other more "work" style environments.  What the IPad represents is what your children are going to be using, what my grandparents and your grandparents are going to be using.  When I first saw the IPad presentation, I was underwhelmed until I went for lunch with a very, very, *very* smart friend of mine when we realized - hey, we're supposed to be underwhelmed - we're not the demographic being targeted.  I know that is tough to hear for some of the software developers who read this bog, since you're used to being shunned by polite society anyway! 

Sounds crazy, doesn't it?  Well, remember that yours truly, the Nostradamus of the computing industry, also previously proclaimed:

• That Microsoft would see the error of its ways regarding Javascript.  This was at a time when some of Microsoft's evangelists were all, "Who even likes working with Javascript, right? Watch us spin a couple of squares with Silverlight!"  A couple of years later and now we have JQuery as the library of choice with the Microsoft MVC.  For those of you who read this that are not technically inclined, "who even likes working with Javascript?" is akin to saying, "Who even likes washing their hands before eating dinner?", which come to think of it, explains Silverlight's popularity in Manitoba!!
• (Speaking of the MS MVC) that the MS MVC was the future of web development, and that WebForms was on its way to being legacy technology.  Well, well, none other than Scott Guthrie agrees!  "I don't see that anywhere in the article,  Justice!"  Trust me.  In my next post I will use my incredible literary analysis skills (honed from the age of 2) to open your eyes.  Again for those of you who don't have a computing background, the difference between the MS MVC and WebForms is like the difference between using indoor plumbing and throwing your feces against the wall - they both resolve the underlying issue but the latter is a heck of a lot messier and was only acceptable in the dark ages.
• Vista would be a flop.  And it was such a rousing success that Microsoft actually invited yours truly to an "influencer meeting" across the country where I learned all about how to sell Vista to the enterprise.  (I might argue that Microsoft first went wrong in calling me an "influencer", actually, but to be fair they have made some pretty spectacular decisions in the past along with the questionable ones).

I remember wrhen I wrote about why I thought Vista wasn't compelling.   Sure, someone chimed in to tell me all about all of the under the hood improvements that would *guarantee* everyone would get it, and as I said back then, "Why does my mother care about IIS7?  Or Bitlocker?"  But my mother?  She'll care about the IPad.  And that is why the future doesn't belong to you, or to me - because we're the fringe elements on this one, my friends. 

The mainstream is coming.  You should get ready.

"We're not thinking about fighting Sony, but about how many people we can get to play games. The thing we're thinking about most is not portable systems, consoles, and so forth, but that we want to get new people playing games."
- Nintendo President Satoru Iwata on the Nintendo Wii

"I love your...what do they call that?  The IPhone?  It makes everything so easy!!   But the screen is so small - I could never read or type anything on it!"
- My grandmother  

"Why do you keep writing 'There's no more info online?  Don't you understand that a lot of seniors don't have a computer, much less the internet?  And it's so hard for some of us to get on the internet anyway!"
- Letter to the Editor, Edmonton Journal

"This will be the most important thing I've ever done."
-A rumored quote from Steve Jobs, co-founder and CEO of Apple, referring to the Apple IPad

(from a discussion with a developer that will go unnamed*)

3:31 PM Justice Gray

So, Latino Heat and I would like to know why you look like you are receiving an enema every time you're on the phone

Not that I know what receiving one looks like, I'd just like to add

3:32 PM Latino Heat

I have seen in the faces of others though

3:32 PM Justice Gray

You have lived a rich life, Latino Heat

3:32 PM Latino Heat

it starts with surprise, moves on to pain

and ends with disbelief and enjoyment

3:32 PM Justice Gray

Come to think of it, you just described my refactoring process

"I can't see the difference, can you see the difference?"

I say to my wife and 4 of her friends, "I will grill steaks for tonight's dinner.  They will be on the table at 6 PM".

At 6 PM, we all sit down to the table and I place a rock on each plate, said rock still being slightly damp as I scooped them out from the harbor 20 mins before.

My wife complains, "I thought you were grilling steaks?"
One friend says, "This isn't like any steak I've ever seen"
Another one says, "Not only is this not steak, but it can't be grilled.  It is wet!!"

I reply to them, "Ha!!  Grilling steaks doesn't mean what you think it does!!"

So, in conclusion is this situation:
a) the fault of my friends, who should have asked me what I meant by "grilling steak"
or
b) my fault for communicating something completely different from the commonly held expectation of every human being on the planet?

in the programming profession it's relatively well-understood that, as long as they can get by OK, programmers don't care that much about the money -- it's the quality of experience that matters)

Oh Bruce Eckel, you crazy old hippie. I hope your kids aren't trying to send you to the nursing home after reading this!

(The rest of this essay, however, is excellent weekend reading, especially the part where he highlights why MS is getting destroyed by Apple!! Highly recommended for that alone!)

And that message is that you are a decrepit piece of street trash.  That is, if you are not already subscribed or reading their "14 days of JQuery", which started today.  Not since I spent two arduous weeks teaching D'Arcy Lussier how to read has there been such an opportunity for total life transformation in only half a month!  The JQuery team is too humble to tell you that pursuing *any* other technology direction in software development is the biggest waste of time since the invention of VB.NET but thankfully, you have someone who has no shred of humility whatsoever to tell you how things really are.   Dave "Encosia" Ward knows that HTML and Javascript are the future.  Sara "Girl Developer" Chipps knows that HTML and Javascript are the future.  And finally, Justice "the man whose words you hang on, read to yourself on a voice recorder and play back softly while you're in the bathtub" Gray knows that HTML and Javascript are the past, present, and future of software development as you know it.  Most of you were planning to spend the next 14 days as you usually do: on the couch playing World of Warcraft with your only companions being a tub of ice cream and your tears.  Let's be real here, iif you don't like JQuery, this is the only life you deserve.  So for today's inspirational missive I am speaking on behalf of every incredibly attractive JQuery fan out there and telling you to stop being such a loser and start paying attention to what the JQuery team has to say!    Take it from the Alpha, Omega, and Gamma Delta of software development!

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!