I've recently picked up my copy of Code Complete - 2nd Edition again after a long hiatus from it.  It's such a massive book that I think if you plan on reading it from front to back, it'll bore you to death and put you to sleep.  Of course, this is not to say that the book is bad - quite the opposite, the book is filled to the brim with knowledge that will benefit any level of developer - but that you have to approach it in a more "leisurely" manner.

The book itself is one of those that you can really just kind of jump in and out of the chapters (except for some of the early ones that should be digested together).

Some bits from Chapter 31 that I think really capture the essence of the book. 

McConnell opens with an excellent statement that succintly summarizes my infatuation with proper code structure, naming, and other seemingly "non-development" coding activities: it is a matter of personal pride in my work and the effort that I put forth to make the code legible:

“The visual and intellectual enjoyment of well-formatted code is a pleasure that few nonprogrammers can appreciate.  But programmers who take pride in their work derive great artistic satisfaction from polishing the visual structure of their code.” (P.729)

The chapter covers the importance of good formatting and layout, the psychological effects of good layout and formatting (such as easier to memorize code structure), and techniques to achieve good layout.

McConnell introduces the idea of “The Fundamental Theorem of Formatting” which says “good visual layout shows the logical structure of a program” (P.732)

He quotes Elliot Soloway and Kate Ehrlich in their studies:

“…there is a psychological basis for writing programs in a conventional manner: programmers have strong expectations that other programmers will follow these discourse rules.  If the rules are violated, then the utility afforded by the expectations that programmers have built up over time is effectively nullified."  (P.733)

This is in alignment with the ideals of best practices.  The core concept is to have a codebase that exudes familiarity even to first time readers.  McConnell emphasizes the importance of the human aspect of coding:

“The smaller part of the job of programming is writing a program so that the computer can read it; the larger part is writing it so that other humans can read it.” (P.733)

Indeed, writing code so that the machine can read it is easy: the compiler, IDE, and development tools like ReSharper will tell you when the machine can’t read it.  Writing code so that other humans can read it is a true challenge since there is no one to confirm your view of the code or structure (without a well defined code review practice or pair programming). 

In that sense, writing code is not so different than writing in general.  Using shorthand is always the fastest ways to write little notes for oneself, but when composing a written work that others must consume, there are certain conventions that people come to expect: proper spacing, proper usage of punctuation, proper grammar, and the usage of paragraphs to delineate discrete bodies of text – these details all help to make the text more readable from a mechanical perspective.

While code is certainly not literature (well, not to most normal people anyways ), there are similar traits in elegant code structure and elegant prose: it is simple, clear, concise, and expressive.  It might follow a pattern (rhyming, iambic pentameter, etc.) that gives it a flow.

Soloway and Ehrlich’s studies concluded that:

“The results point out the fragility of programming expertise: advanced programmers have strong expectations about what programs should look like, and when those expectations are violated—in seemingly innocuous ways—their performance drops drastically.” (P.735)

They cite examples where advanced chess players showed a marked increase in ability to memorize chess pieces arranged in “standard” or common scenarios over novice players, but demonstrated no increased ability when the pieces were arranged in a random fashion.  The conclusion is that familiarity increases the ability to internalize and process an otherwise abstract structure (or in this case, arrangement of chess pieces).

Of course, it’s not all just fluff and “nice to haves”, right?  McConnell raises an interesting observation that:

“The information contained in a program is denser than the information contained in most books.  Whereas you might read and understand a page of a book in a minute or two, most programmers can’t read and understand a naked program listing at anything close to that rate.  A program should give more organizational clues than a book, not fewer."

This makes the argument clear for commenting, proper and consistent application of white space, and using descriptive rather than short names (see Framework Design Guidelines for more coverage on that).  For example (and I’ve never understood this one), the use of “itm” instead of typing “item” or “tsk” instead of “task” or the use of “d” to declare a local variable instead of “document”.  One letter makes the code much more readable and much easier to process for another human reader of the code.

McConnell also makes a very good case for how code should be structured to reduce the complexity of the visual layout.  He gives a good abstract comparison on page 747.  These are small items which increase the readability of the code in very subversive ways; you probably never think about such details actively, but when processing a page of code, little details like indentation probably have a strong effect on your ability to understand the purpose and nature of the code.  More importantly, when other humans have to process your code, these little details, taken in cumulative, could mean the difference between a day of ramp up and a week of ramp up time.

Of course, McConnell does acknowledge that in many cases, such matters of style are borderline “religious”.  But from an objective perspective:

“…it’s clear that some forms of layout are better than others.  Good programmers should be open-minded about their layout practices and accept practices proven to be better than the ones they’re used to, even if adjusting to a new method results in some initial discomfort.” (P.735)

Definitely a book that deserves some shelf space on any developer's desk (edit: or nightstand ).

I originally came across a title Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries after perusing the documentation on the Subtext site.

For the most part, I had been following the guidelines outlined by Scott Bellware in his handy dandy style guide, but this text - FDG - takes it to another level and formalizes it in a way that it must be accepted by development teams since it was born from the source itself: the .NET Framework development teams.

I've reviewed it on Amazon, but here is the transcripted text:

I don't personally think that all developers will find this book useful. In fact, I have a feeling that some may find it highly useless and disruptive as it is abstract in a sense (one must apply the lessons to each library and scenario independently, taking into consideration many different aspects of usability and readability) and it does require some "retraining" of bad practices which have been long since ingrained due to years of usage.

But whether this book deserves a five star rating or a one star rating - whether this book is for you - can be answered by asking yourself the following question: are you obsessed with quality? Quality in the sense of creating a library that is:

- Easily reused by others, even first timers encountering the library or even first timers to .Net
- Well thought out with well designed classes
- Consistent within itself and consistent with the base libraries from Microsoft

The importance of the little things like naming classes, properties, methods, using one type of construct over another, using one type of accessor over another, etc. cannot be stressed enough in the overall picture of creating a library to a higher standard of quality, usability, and extensibility.

As Confucius is to have said:

"If names be not correct, language is not in accordance with the truth of things. If language be not in accordance with the truth of things, affairs cannot be carried on to success.

"When affairs cannot be carried on to success, proprieties and music do not flourish. When proprieties and music do not flourish, punishments will not be properly awarded. When punishments are not properly awarded, the people do not know how to move hand or foot.

"Therefore a superior man considers it necessary that the names he uses may be spoken appropriately, and also that what he speaks may be carried out appropriately. What the superior man requires is just that in his words there may be nothing incorrect."

As I wrote in an e-mail to my team, I think that digesting this book will lead to: higher quality public facing APIs for our customer development teams seeking to extend the functionality, increased readability and more consistency internally in our teams, increased usability and decreased maintenance costs for the support teams as well as new developers on our team, and of course, increased skill, knowledge, and competency as developers of each of the team members.

The title of this book is perhaps a bit misleading.  In reality, this book is applicable for anyone doing .Net development since it will lead to better quality code construction irregardless of whether you happen to be working on a "framework".  What I also like about the book is that the authors, architects, and various developers who worked on the .NET Framework admit error and inconsistency in some design and shows that this book is truly a work of the men in the trenches and intended for those of us who work on the front line of software development.

While the book does not delve into architecture or design, I think it still has value in enhancing the skill and mastery of any developer that takes the time to read it.  Definitely pick up this book if you are serious about becoming a better developer in the sense of being a more refined craftsman.

So it turns out that Paul Andrew, the technical product manager of WF linked to my very abstract review of Essential Windows Workflow Foundation.  For those that haven't been following, I wrote an awesome review of the book on Amazon and sent it in (or so I thought!) but I haven't seen it show up on the page yet

So for the sake of others considering this book, I'll review it again.

There are two types of developers that you will come across: those that are content to make things work and solve business solutions from the top down and those that want to understand the underlying technologies to build solutions from the bottom up.  This is not so much a discussion on "architecting", mind you, but rather a discussion on how different developers approach tools and frameworks.  Not that one is better than the other, but each brings a different approach and each has different preferences with regards to technical resources.

If you fall into the former and you are mostly concerned with your immediate business solutions (learn top-down) and you learn best by doing, then this book is not for you.  The contents of this book are not so much concerned with how to solve business solutions with WF nor is it a cookbook for WF solutions.  This book doesn't have many pictures of the design surface and doesn't concern itself much with building workflows in the designer.  It is an introductory guide to the underpinnings of the WF framework.  It delves into the workings of WF and the principles behind many of the advanced concepts that may not necessarily crop up in most use cases.

If you fall into the latter category of developers (learn bottom-up) and you learn best by first understanding the tool and the design principles of the tool, then this book will be a good starting point to understanding WF.  In fact, the first chapter of the book walks through a sample implementation of a simple "workflow engine" and covers the principles that drive the implementation of the WF framework.  The chapter presents a "If I were writing a workflow engine, how would I write it?" scenario (if that makes any sense).  This outline then serves as a basis for understanding the function and design of the WF engine.

The book provides insight into advanced concepts and does a fairly good job of it (examples are simple and straightforward - oddly, not all of the code is provided online), but it seems to come up short in the last chapter, where the authors just kind of jumbled everything that they didn't cover into one chapter.  It almost seems like the authors were working on a 10 or 12 chapter book but were forced to cram the remaining topics (unfinished) into chapter 8.  In short, the book seems unfinished.

This book is not for everyone.  It does assume some familiarity with higher level .Net framework concepts that many developers from the ASP.Net world may not have experience with (specifically, threading and asynchronous method calls) so for that reason, I would recommend a companion book: Pro C# 2005 and the .NET 2.0 Platform, Third Edition.  As a general note, I've found that the "Microsoft .Net Development Series" of books from Addison Wesley typically does not cater to the first class of developer as the titles tend to be architecture and framework oriented as opposed to solution and implementation oriented.

In summary: 4 out of 5 stars; a worthy book that deserves a space on your bookshelf if you plan on doing WF.

Yesterday was my first time at an NFL football game (Jets vs. Bucs).  This also means that I've been to each of the three major sports (NBA, MLB, and NFL).  (For my international readers, the NFL is the highest league for American-style football).

I must say, the experience is quite something.  It's very different from either of the other big three sports in that there is a whole huge sub-culture in the football world.  If you've never experienced it, there's nothing quite like it at all.

Sadly, I didn't have my camera with me, but driving into the parking lot of Giants Stadium I was just struck by how many people were there tailgating.  It was incredible, it was like a little town sprung up there that morning, with people pitching tents, watching TV, eating BBQ, throwing footballs around.  I mean, it felt like these people lived there.  What caught my attention as well was that a lot of men would urinate right by the side of the road without hesitation (since the lines for the port-o-potties was ridiculous.

The stadium itself was tremendous.  There's nothing quite like it in the enormity of it all; you get kinda queasy sitting in the third tier just looking down.

The game itself was great.  Vinny Testaverde was playing in his first game in 9 months since retiring with the Cowboys after last season.  I have to say, I can only hope that I'm that mobile and that fit when I'm 41, because damn, the guy can still move and throw the long ball.  He had the crowd roaring during pregame warmups when he threw a 60-70 yard pass to Laverneus Coles.  Wow.  Vinny only threw one interception, which was unfortunate (it was short only by a little), but acceptable considering that just two weeks ago, he was hanging out on his sofa watching the Jets play

Afterwards, listening to Vinny talk, I was reminded of The Incredibles.  Vinny had some great years (the best of his career) with the Jets and here he was again, up to his old heroics after retiring from football.  And like in The Incredibles, it took a team effort to overcome the opponent.

In a totally unrelated sidenote, I got my copy of "Ghost in the Shell 2: Man-Machine Interface" on Friday.  My review is on Amazon, but I'll copy it here for the lazy:

"Before you read on, bear in mind that I'm writing this review in comparison to the first "Ghost in the Shell". While Shirow does mention that this book is not a continuation of the first, there are some major differences in style.

Let's start with the artwork. As I've noticed with Shirow's work, all the ways from Appleseed, his style has matured with each work and is at a very advanced level, in my opinion, among top comic book artists in the world. He has a certain style of coloring that, to me, is really unique in how subtle, lifelike, and tactile he makes fabrics and skin. While only roughly 35-40% of the book is colored, it is done so fantastically.

In addition, Shirow has a supreme mastery of the female body form. It's simply stunning to see how beautifully he can render the female body, especially with the dynamic energy he brings to his characters. While he renders many of the panels with the female characters in the buff, he does not render "R" nudity, but rather "PG-13" nudity, except in one panel). (As a sidenote, parents of younger readers should perhaps consider this an "R" rated book. While none of the nudity is gratuitous, it can be a little too much for some).

As fans of Shirow have noticed, he has been experimenting with integrating 3D, rendered environments and objects with his 2D artwork. He shows his mastery of this technique in many of the panels, where it seems seemless; you feel as if the character is really a part of the scene. Then in others, it seems poorly done (for example, he renders pigs in a sequence of panels and the pigs just look weird). I'd also offer some criticism of his rendering of "virtual space", as it quickly becomes cluttered and very difficult to navigate, visually, especially in the low-res, black and white lineart panels.

As with all Shirow works, there is certainly enough cool technobabble and gadgets to get your geek juices flowing. From exoskeletons that envelope and "swallow" the pilot, to oddly constructed androids, to the techno-metaphysical discussions of reality, life, existence, and justice.

My main criticism with the work is the incontinuity *within* the plot itself (I fully understand and accept that this is not a continuation of the first). Without going deeply into the plot, there are some scenarios where he will start what seems like an arc, but then the arc disappears, without entering into the plot again. It seems like whole parts of the book were created just for the sake of showing artwork, and not progressing plot (to me, plot should always come first in a written work, which this is, despite the medium). It feels like the recent Star Wars movies in that they are really a showcase for Lucas's technique with fully rendered sets and have lost any semblence of a cohesive plot and the great acting (especially Harrison Ford) that made the first three the classics that they are. Yes, while I do appreciate the eye candy, this is still a graphic novel, and, as such, I expect a cohesive plot and not random interjections of this and that and whatever.

Some fans will also find the lack of action (compared to the first book) a bit disappointing. The first book was far grittier and more action packed than this book. It also had a richer cast of characters. "Man-Machine Interface" really only features one character (albeit in various bodies and forms) and thus loses some of the dynamic interactions between characters. Shirow never gets a chance to fully developer the chief of Poseidon police and his crew.

Overall, this book is excellent if you simply love Shirow's beautiful artwork, mastery of the female body form, and creative techno-gadgets. The plot, especially the ending, will leave you sorely disappointed. Whereas the first ended on a revelation of a metaphysical type, this book ends in a fizzle."

If you're a fan of Shirow, it's a no brainer, you gotta pick it up, but it's certainly not for everyone.

I'm also working my way through Fred Brooks' "The Mythical Man Month".  I'm only 1/3 of the way through the book at the moment, but it's absolutely a great book that everyone in an IT organization (everyone!) has to read.  I mean, even after all of these years, the same problems persist in software development (doesn't anyone learn from history?).  If you're in the IT industry, whether you're a manager, a salesperson, or a developer, be sure to pick this one up.  It's an easy read, too, since Brooks' style is very inviting and personable.  He makes some excellent analogies.  I think I'll do a mini book review after I'm done with the book

That's it for now...been busy at work, so less time to post during the day >.<