Unhandled Exceptions

On the weekend of Independence Day (July 4th) here in America, I am pleased to announce that I am now officially declaring my independence from Microsoft Live Spaces!

I originally ended up with my blog hosted here on Microsoft Live Spaces years ago just out of sheer laziness -- one day my 10+ year-old hotmail account had a 'come set up your blog on live spaces' intro message from MS hotmail's spam-generator and so I clicked the 'sure, why not?' link and let it set up my blog for me.

There are, however, more than just a few gotchas with this default approach that have slowly started to become more than just nuisances and have now grown into full-blown annoyances.  These have now reached the point where I've decided to bite the bullet and say 'farewell' to the path-of-least-resistance and move to something a bit more fully-featured.

From now on, my blog's new home will be at http://blog.unhandled-exceptions.com

Since my migration strategy to get my content moved from here over to the new location was based on importing an RSS feed from this site, I was limited to being able to import only posts since September of 2007 since that's only as far back as the RSS feed from Live Spaces seems to go right now.  Given this, I have provided links to all past posts on this site from my new blog site and its my plan to keep this space right where it is with all of the content presently here so that these links remain resolvable for the time-being.

As far as I know, since this Live Space is linked to my hotmail account it should be able to remain here as long as my hotmail account remains active (and I have no plans to cancel that e-mail account any time soon).

So I invite everyone to continue to visit my blog at its new home: http://blog.unhandled-exceptions.com.  This Live Spaces blog's content will remain here for the time being, but no new content is planned be added to it at this old location.

A number of (apparently hyper-honest ) people have asked for a license under which I am distributing the Summer of NHibernate Screencast series of videos to the world-at-large.  Seriously though, I really appreciate the question and hadn't given it much thought but after careful consideration, I have settled on a variant of the Creative Commons licensing that provides for the following:

• unlimited distribution by anyone so long as the distributor:
  • provides me attribution should the content be included in any other distribution
  • does not include the content in any commercial endeavor
  • does not make any modifications to the content

Basically, this is designed for anyone to take the content, view it, share it with anyone they want to so long as they don't charge for it, redistribute it using whatever means they want so long as it remains clear that I am the author of this content, and they don't change anything in the content.

For the official record, here is the license statement:

Summer of NHibernate Screencast Series is licensed under a Creative Commons Attribution-Noncommercial-No Derivative Works 3.0 United States License.

Just wanted to let everyone know a few things about the Summer of NHibernate content (screencasts, code samples, etc.)...

1. the content has been relocated to be hosted on www.drop.io
2. Links provided in the prior posts have been updated accordingly to reflect the new URLs
3. this is intended to provide a (slightly) less invasive download experience than was achieved using the previous content host (www.4shared.com ) which I think was universally panned based on feedback I rec'd
4. I am continuing to investigate even better solutions and expect to have a distro approach with even less friction available soon so please be patient and bear with me a bit longer

I really appreciate everyone's continued interest in this content and the wide-ranging suggestions I have rec'd re: alternate distro methods -- rest assured that I am taking all of the feedback to heart and weighing several options.

More to follow soon once I finalize an alternate approach to this.

I have posted the next installment in the series which actually diverges slightly from the previously-planned curriculum.  The plan for this session was to cover INSERTs, UPDATEs, and DELETEs but looking back at the topics for Session 02 I realized that there were some aspects of querying that I had wanted to cover but overlooked as the clock ran out (I have a self-imposed time-limit for these of no more than about 90 minutes of total length so that they remain somewhat easy to sit through without squirming ).

Enter: Session 02a

To address this oversight, I this next installment is called Session 02a since its topics are really more in-line with the content of Session 02 rather than a completely new set of topics.  Topics focused on in this installment:

• Order By clauses
• Group By clauses
• Returning 'partial objects' from the database (retrieving only what you need)

The good news is that this session only runs about 60 minutes since its not a complete stand-alone session per-se.  This means that there are only two parts of the ZIP file that you need to download from the www.4shared.com drop.io site so 1/3 less annoyance in the downloading process .

As always, comments and feedback are appreciated.

Download Links for Session 02a

• Summer of NHibernate Session 02a Screencast Part 1 of 2
• Summer of NHibernate Session 02a Screencast Part 2 of 2
• Summer of NHibernate Session 02a Code Sample

Note that as with all of these screencasts, to successfully view them on your computer you will need to download and install the TechSmith Camtasia Codec.

Just wanted to let everyone know that the screencast for Session 02 of the Summer of NHibernate series has now been posted for download (see below).  For more details  on this and the other sessions, please see this post.

Session Outline

Session 2 (6/18): EXPLORING QUERY METHODS AND SYNTAXES

• Extend the data access classlib from session 1 to include additional query methods to return Customers from the database using all the different query approaches supported by NHibernate
• Demonstrate the Criteria API syntax to retrieve using the NHibernate.Expression.* statements
• Demonstrate QBE
  • Code retrieval method that takes a customer and returns all matches to that example object
• Demonstrate HQL queries
  • String-literals
  • Polymorphic queries
• Demonstrate Projections in queries
  • GroupBy
  • OrderBy

As before, the screencast and the related source code sample is available for download on the 4shared.com drop.io site.  Also as before, the ZIP file with the AVI exceeds the max single filesize supported by 4shared.comdrop.io (100 MB) so I have divided the ZIP file into three sub-100MB parts; you must download all three parts of the multi-part ZIP file in order to extract the video of the screencast.

Also as before, comments, feedback, suggestions are welcome.

Download links for Session 02

• Summer of NHibernate Session 02 Screencast Part 1 of 3
• Summer of NHibernate Session 02 Screencast Part 2 of 3
• Summer of NHibernate Session 02 Screencast Part 3 of 3
• Summer of NHibernate Session 02 Code Sample

Note that as with all of these screencasts, to successfully view them on your computer you will need to download and install the TechSmith Camtasia Codec.

I am pleased to announce that the first installment of the Summer NHibernate screencast series is finally available for download!

This first session covers the basic setup and usage patterns of the NHibernate object relational mapping technology and starts with the basics assuming no familiarity on the part of the user with NHibernate at all.  For background on the reasoning behind this video series refer to this previous post.

Screencast Session Outline

Session 1 (6/13): SETUP AND BASIC USAGE PATTERN

• Get the NHibernate dlls and .xsd files
• Demonstrate how to add the xsd files to VS XML intellisense capabilities to get syntax support in the XML files
• Use a simple Customer -- Orders -- OrderItems style database
• Hand-code DTO class for the ‘Customer’ table
  • Introduce the concepts of 1:1 relation between table and class
  • (the dumb-DTO pattern; start here since it’s by far the simplest way to work)
• Hand-code the Customer.hbm.xml mapping file to expose people to this syntax
• Hand-code the hibernate.cfg.xml file to expose people to this syntax
• Setup the project in VS (data access class lib)
• Setup a corresponding test class to go along with it (to be used to exercise the data access class lib)
  • Further demonstrates the value of unit tests as a ‘harness’ for exercising concepts in a safe vacuum
• Code a simple method that demonstrates the basic mechanics of interacting with NHibernate to retrieve all Customers from the database
  • ISessionFactory, ISession, reading configuration(s)
  • Leveraging the using ( ) {…} block to ensure session is properly closes/disposed of when done

Screencast format and Download Server

So that a high visual quality for sessions can be maintained, these Screencasts are being recorded at a relatively high resolution of 1280x1024 and are projected to run for between an hour and an hour and a half in length.  As such the total download is easily a couple hundred megabytes in size and since I'm too frugal to spring for a for-fee download site for the content I have instead chosen to post the sessions at the www.4Shared.com web site. I have isntead chosen to post the content on the www.drop.io web site. 

4shared.com drop.io is a free content hosting site offering unlimited bandwidth and 5 GB of unlimited concurrent storage but there is a limitation that no single file can exceed 100 MB in individual size.  To circumvent this limitation I will be breaking the Screencast into two or more multipart ZIP files, each one just slightly under 100 MB of capacity.  In order to unzip the AVI file you will need to download all three parts of the multipart ZIP file listed below.  An additional download has also been provided containing the source code for the session used in the video for those interested in exploring the code.

While this approach results in a larger number of individual files to download, it allows me to post the content and make it available at a location with no bandwidth limitations associated with it.

As usual, comments and suggestions are welcome!

Download links for Session 01

• Summer of NHibernate Session 01 Screencast Part 1 of 3
• Summer of NHibernate Session 01 Screencast Part 2 of 3
• Summer of NHibernate Session 01 Screencast Part 3 of 3
• Summer of NHibernate Session 01 Code Sample

Note that as with all of these screencasts, to successfully view them on your computer you will need to download and install the TechSmith Camtasia Codec.

My company makes extensive use of the NHibernate O/R Mapper technology in many of our solutions and we sometimes hire new developers that have good skills and experience but who have no direct exposure to NHibernate (yes, it is possible to be a good software developer even if you don't know NHibernate but anyone worth hiring in the first place can easily pick it up with minimal friction).  Often, our strategy for bringing people up to speed on this has been to rely on word-of-mouth and osmosis (often via pair-programming) to get the points across, but now we have a planned staffing ramp-up of a magnitude that will likely make that approach unwieldy.

To address this challenge, I am producing a series of successive screencast sessions that cover the complete use and implementation of NHibernate.  Called Summer of NHibernate, this series of screencasts is designed to take the newbie who knows nothing at all about NHibernate and teach them everything they need to know to start using NHibernate in a real-world application by the end of the hot summer months.  These screencasts will act as a set of reference materials that we can provide to new hires to help them get ramped up on the use of NHibernate in a short-order.

Since it seems to me that others in the community might find these to be of interest, I have decided to release them for general download to anyone who has always wanted to look into NHibernate but never found the topic at all approachable.

As I'm creating these screencasts first and foremost for internal consumption by our own staff, some of the content is intentionally not technology neutral (e.g., we use SourceGear VAULT for our SCC platform, CodeRush + RefactorPro! as enhancements to our VS IDE, etc.) and I have made no effort to make the content more 'generic' but any outside viewer should still be able to find the content useful despite this slight internal bent.

Think of this as an opportunity to take a multi-part crash course in NHibernate (from zero to productive) for free by downloading the screencasts as they are released and following along.  Each screencast will be accompanied by a new post on my blog that talks about what was covered in more detail.  Hopefully, rather than sweating outside in the summer heat developers can sit inside in the air conditioning and watch these screencasts this summer

Why bother releasing internal training content for everyone else who wants it?  Read on...

ALT.NET and the Chicken vs. the Egg Problem

Over the past 6-9 months or so I have watched closely the growing community interest in what has come (rightly or wrongly) to be called ALT.NET.  Meshing very well with a number of my long-held beliefs about .NET software development (and good software development in general), ALT.NET just doesn't seem all that 'ALTernative' to me since I have long embraced any number of non-Microsoft-proscribed software development practices and tools in support of those practices.

That being said, there are of course a large number of .NET developers (perhaps even the large majority) who have no idea what all this ALT.NET stuff is about.  A infrequent but recurring topic on the ALT.NET forum is that of "how do we lower the barriers to entry for someone wanting to get their feet wet with ALT.NET?".   This is is echoed by ALT.NET newbies who say "where is the book I can read to become ALT.NET?"

The big problem here is that while ALT.NET is (or at least tries to be!) much more about what practices you follow when developing with your tools than the tools themselves, skill/expertise with at least some of the basic tools would seem to be a prerequisite for focusing on some of the ALT.NET values when developing software.  This is the classic chicken-and-egg problem where you cannot practice the principles without using the supporting tools and you don't recognize that you actually need any of the tools until you try to follow some of the core principles and find the out-of-the-box tooling provided by Microsoft insufficient to support what you want to do.

Why NHibernate?

So why start with NHibernate?  The premise behind this coming series of screencasts is that data access is something that just about every application developer will have to deal with in just about every application.  As such, starting to learn a tool that enables more efficient and effective data access is likely to be immediately applicable to more developers than, say, an Inversion-of-Control container (though this statement is certainly debatable).

Further, while object-relational-mapping may be unfamiliar to many non-ALT.NET developers, its core concepts are relatively approachable and can be (relatively) easily incorporated into any software development project without requiring huge redesign of the entire system (as something like dependency-injection/inversion-of-control might require to be effective).

Lastly, rightly or wrongly NHibernate seems to have become the poster-child of the ALT.NET movement, constantly being raised as evidence of a powerful tool developed to support principles and practices that Microsoft is only just now barely starting to warm to.  This makes NHibernate one of the most visible software tool of the ALT.NET developer group (although I would stress here that it is entirely possible to develop applications without NHibernate and still follow a good number if not all of the good software engineering principles espoused by the ALT.NET community).

As such, I feel strongly that mastering NHibernate represents the low-hanging-fruit of the ALT.NET recommended toolset -- its ubiquity (and value) perhaps only eclipsed by that of any one of the unit testing frameworks out there.  If we can get users to begin to use something like NHibernate, they will be much more able to approach other tools in the ALT.NET world that support the practices that ALT.NET considers important to the development of professional software systems.

Synopsis

Following is my planned outline for each of the screencasts that will make up the series...

Session 1 (6/13): SETUP AND BASIC USAGE PATTERN

• Get the NHibernate dlls and .xsd files
• Demonstrate how to add the xsd files to VS XML intellisense capabilities to get syntax support in the XML files
• Use a simple Customer -- Orders -- OrderItems style database
• Hand-code DTO class for the ‘Customer’ table
  • Introduce the concepts of 1:1 relation between table and class
  • (the dumb-DTO pattern; start here since it’s by far the simplest way to work)
• Hand-code the Customer.hbm.xml mapping file to expose people to this syntax
• Hand-code the hibernate.cfg.xml file to expose people to this syntax
• Setup the project in VS (data access class lib)
• Setup a corresponding test class to go along with it (to be used to exercise the data access class lib)
  • Further demonstrates the value of unit tests as a ‘harness’ for exercising concepts in a safe vacuum
• Code a simple method that demonstrates the basic mechanics of interacting with NHibernate to retrieve all Customers from the database
  • ISessionFactory, ISession, reading configuration(s)
  • Leveraging the using ( ) {…} block to ensure session is properly closes/disposed of when done

Session 2 (6/20): EXPLORING QUERY METHODS AND SYNTAXES

• Extend the data access classlib from session 1 to include additional query methods to return Customers from the database using all the different query approaches supported by NHibernate
  • Demonstrate the Criteria API syntax to retrieve using the NHibernate.Expression.* statements
  • Demonstrate QBE
    • Code retrieval method that takes a customer and returns all matches to that example object
  • Demonstrate HQL queries
    • String-literals
    • Polymorphic queries
  • Demonstrate Projections in queries
    • GroupBy
    • OrderBy
    • Max
    • Avg
    • Etc.

Session 3 (6/27): EXPLORING INSERT, UPDATE, DELETE SEMANTICS

• Continue with query option examples if incomplete from session 2 (as needed)
• Explore INSERT, UPDATE, DELETE semantics in NHibernate
  • Extend data access classlib to include data methods to allow updates/inserts/deletes
  • Introduce concepts around session.Flush(), session.SaveOrUpdate()
  • Introduce the ITransaction pattern to wrap CRUD operations

Session 4 (7/2): MODELING RELATIONSHIPS IN NHIBERNATE

• Extend the collection of DTO classes to include the other tables
• Extend the mapping files to support the new DTO classes
• Exploring multiple-class mappings and FK relations in the mapping files
  • Relationship types
    • One-to-Many
    • Many-to-One
    • Many-to-Many
  • Collection types
    • Bag
    • List
    • Set
    • Etc.
  • Understanding cascade-xxx operations (and its impact on orphans)
• Extend the data access classlib to implement these things by way of examples
• Introduce the concepts of Lazy-loading

Session 5 (7/9): ADVANCED QUERYING OF CHILD COLLECTIONS AND VIEWS

• Querying complex object graphs (parent à children, collections, etc.)
  • Querying across object relationships
    • Joins
    • Sub-queries
    • Child criteria
    • Others
  • Via the Criteria API
  • Via HQL
• Understanding NHibernate support of the VIEW construct
  • Mapping files for VIEWs
  • Classes for VIEWs
• Understanding disconnected Objects and session.Evict( )
  • Multithreading issues/concepts

The first screencast installment will be ready by about June 20, 2008~!

Lately I have been giving some thought to just what exactly the guiding principles are behind the way I both approach and execute my professional software development career.  After considering this for some time, I have come up with the following fifteen or so principles that I think sum up pretty nicely my approach to things.

Things to note about these:

• These principles aren't listed in any order; except in so far as the order they came to mind (so perhaps subconsciously they are ordered! )
• Some of these are related to designing and developing software; others are related to managing people because both are significant components of my varied responsibilities

Complexity is the Root of all Evil in Software Engineering.

This principle springs from the observations over my career of myself and others that as the complexity of software increases, nearly all other positive aspects of the project decrease.  All of the '-ilities' that are espoused as being the goals of 'well-engineered software' (whatever that means!) decrease as complexity increases.

Flexibility, extensibility, adaptability, manageability, etc. all suffer terribly under the weight of an oppressively complex software project as the complexity conspires at every turn to make achieving these other aspects of sound design nigh-impossible.  As a result, if you can successfully reign-in complexity in your work, then all other goals are at least within range of being achievable.

A lot of what we do requires creativity; a lot of what we do does not.  KNOW THE DIFFERENCE.

If I had a dollar for every time I saw a developer solve a problem in a needlessly creative fashion, I could retire and live out the rest of my life in luxury.  Certainly, good software developers understand that they need to be creative problem-solvers, great software developers actually are, but exceptional software developers recognize when creativity is called for and when their tendency for creativity is inappropriate.

Often manifesting itself in concepts like NIH (Not-Invented-Here), ignoring this principle leads to wastefully redesigning the wheel for every project rather than smartly leveraging what others have done who have come before us.  The shoulders of giants are there for a reason; use them.

Write code for other developers, not the computer.

When it comes time for a developer to actually write code, always consider that there is absolutely no difference to the computer between using variables with illustrative and informative names like OrderNumber, CustomerName, etc. and needlessly-terse names like a, b, c, etc.  But to the developer who has to maintain your code (and this could even be yourself, stupid!), there is tremendous value in the former approach vs. the latter.  This principle applies well beyond things like variable, method, and class names and continues into function bodies, logic of algorithms, and the very structure of your software design and implementation.

Always be cognizant of the fact that your code will be read once by the computer (during compilation) but hundreds -- if not thousands! -- of times by yourself and other developers during the current project and any future maintenance.  Optimize your work so that other humans can effectively read your code; the compiler optimizations are improving just fine with each new version but developers aren't getting any better at reading complicated or counterintuitive source code.

This principle is related closely to the preceding thought about appropriate and inappropriate creativity; don't get needlessly creative with your code such that it makes it difficult for another developer to interpret what you meant.  This isn't clever, its wasteful.  

Context, Context, Context.

Very simply, this principle is about paying attention to your situation and recognizing what aspects are similar to other situations and what aspects may be different.  The reason there are 100 (at least!) different ways to solve a problem with software isn't so that you can randomly pick one and go with it .  Its because in each context, a different approach may be called for.  All aspects of your software solution from the overall architecture to the underlying language and run-time platform should all be the result of understanding what is and isn't appropriate for the problem at hand.  Dogmatic application of any specific approach, technology, etc. needs to be tempered by constantly asking yourself "is this appropriate for the current situation?"  

If I didn't learn anything new at work today, I should have stayed home.

Every day I have to learn something, even if its just increasing my recognition of how much more I have to learn.  One of the reasons I am drawn to this profession is that I can never be an expert at my craft, only (hopefully!) better at it than yesterday.  As soon as I 'master' something (even assuming that's possible today), something new comes along that I have to 'master' next.  If I didn't learn a single thing at work today, then the day was a waste of my time.

That something new doesn't need to be as big as a different programming language (of course).  It can easily be as small as a new technique, a new API call in a library I thought I knew pretty thoroughly, or even just my increased awareness of something new out there that I now need to find time to look into.

But if I'm not constantly learning, then I may as well be dead.   

Anything can be measured in a manner more accurate than not measuring it at all.

I tend to think of myself as an empiricist.  "Show me the data", is my refrain.  One reason I take this approach is that all too often in my career I have posited solutions to problems based on faulty assumptions (and not surprisingly this doesn't result in positive outcomes).

Probably the biggest challenge with a "show me the data" approach is that often data upon which to base a decision is simply unavailable.  In these cases, one has to rely on the idea of "Context, Context, Context" as discussed above plus good judgement.  But in the absence of any data at all the phrase 'good judgement' sadly reduces down to a 'guess in the dark' since without any data there is nothing to 'judge' when applying your 'judgement'.  This leads me to the principle that a faulty (or less-than-100%-accurate) measurement is always preferable to no measurement at all.  Which is to say that partial data is always better than no data.

"There is no objective measure of programmer productivity that is 100% accurate.", is a familiar refrain (and one I happen to agree with).  But does that truly mean that all programmers are equally productive?  Of course not, but with zero data to review that is the only conclusion one can actually draw that isn't a complete guess-in-the-dark.  Raw LOC count, bug-introduction rates per LOC, time between bug-fix-start and bug-fix-complete are all highly inaccurate measures of programmer productivity, but IN CONTEXT each of them tell us something about the developer's productivity that together start to let us draw conclusions about relative productivity of our staff.

In every case, in every context, some data is always better than no data so long as the interpreter of that data understands the context within which it was captured.  

If you cannot look at code you wrote last month and say 'yuck!', take early retirement now because your best days are behind you.

If at any time as a software developer you look back at your past work and aren't horrified by the work you did in the past, then you should hang it up now and just go home.  Tied closely to the notion of "I need to learn something new every day", this principle is about the idea that if you are constantly improving your skills then you will always look upon your past works with some level of disdain as you see it through the lens of your newfound skills.

If not, your best days are behind you, you have stopped improving, and the downward slide into uselessness has begun.  Get out of the way and free up the desk for someone else.  

An Open-Mind Policy is infinitely more important than an Open-Door Policy.

I have spent most of my career working for companies that were very proud of their open-door-policy.  Seriously, has anyone ever worked for a place that didn't say "We have an open-door policy here."?  Its like "We value our employees, they are our most important resource." and is equally as meaningless as just so much boilerplate HR-speak that every HR director who apparently comes from the same HR Executive factory has been taught they must communicate to employees.

But an Open-Door policy just tells you where its ok for you to go and communicate your input and says nothing at all about the chances that anything will come of it.  The barriers to communication in most companies have nothing to do with open or closed doors, they have everything to do with open or closed minds about what gets said when one passes through one of those 'open doors' that employers are so proud of talking about.

We all need to always keep an open mind about everything because the hubris that comes from "I know now and forever the best way to do XYZ" is getting in the way of the 'learning organization' that we all really want to work for.  

There is no problem so simple that a bad developer cannot make it complicated.

This principle maps closely to the common quote "Never underestimate the ability of the Universe to produce a better Idiot." but it speaks also to the same "Complexity is the root of all Evil" notion discussed previously.  This principle boils down to the idea that the best way to mitigate complexity is to become a better developer and that unskilled developers are more likely to overcomplicate solutions than experienced ones.  

If I was given four hours to fell a tree, I would spend three of them sharpening my saw.

The principle embodied by the above quote from (of all people) Abraham Lincoln, 16th President of the United States is basically a way of illustrating the concept of "Work smarter, not harder."

As software developers much of what we do is creative, unique, one-off work but so much of what we do is also rote, repeat, boilerplate content.  All too often, software developers fall into the 'solution by brute-force of effort' approach to getting work completed on schedule.  Instead, we need to constantly be on the lookout for tools, techniques, processes, and general approaches to our work that allow us to always be improving our efficiency and effectiveness at problem-solving.

I'm not against hard work, but I would rather put my energy into avoiding it by working smart where possible   

The key to effective delegation is learning to ignore HOW something gets done and just caring that it gets done.

One of the biggest challenges to the effective management of people is learning effective delegation.  And one of the biggest barriers to effective delegation is resisting the urge to micro-manage what you delegate.

It is a logical truism that in anything as complex and variable as software engineering, no two people will perform a task (whatever it might be) in exactly the same way.  This truth applies to tasks that run the gamut from "write an e-mail to that client asking for more info" to "develop the guts of the data-access-layer".

While its important to care generally about how each task is performed (e.g., is it up to our standards?, is it on time?, etc.) to effectively delegate means defining clear goals for the task and then only caring about the outcomes.  To care too much about the how of what gets done is to risk micro-managing the task such that you convey that the only valid approach is the one that you would have taken.  If you find yourself dissatisfied with the outcome of what you delegate, then it means you failed to adequately convey the goals of the task when you delegated it.  

Managing people is simple: hire the best, define clear goals, assign proper authority to execute, and get out of the way.  If they don't perform, fire them and go get someone else.

This principle embodies what I consider to be perhaps the single most important set of concepts for effective management of people because it to me it reflects a set of commitments to the process from both sides of the equation.  In essence, its an acknowledgement that creating the conditions where success is possible is a two-way street to which both parties have to contribute.

If management (department heads, project managers, whatever) fails to live up to their end of the bargain (hiring the best, defining and communicating clear goals, granting authority to produce, and getting out of the way) then the results (staff performing to expectations) is never going to come to fruition and to blame the employee for that failure is to avoid the painful introspection that will be needed to avoid repeating the failure in the future.

But if all those inputs are correctly provided for and you still don't get the performance you want (or need) out of an employee, then the single best course of action is to let that person go and hire another.  Life is too short and the pool of potential hires too large to waste time on reshaping an employee that is a square peg to fit into a round hole.   

Leadership means being a short-term pragmatist and a long-term idealist.

This principle is about the idea that to effectively provide leadership one needs to keep one eye on near-term tactical goals and another eye on long-term strategic goals.  When the effective balance between these two gets badly out of whack, terrible things start to happen to a team of people.

On the one hand, when there is no long-term strategy this can lead to nothing but reactionary short-term 'firefighting'-style emergencies that preclude planning and executing any tactics in support of a longer-term strategy.  Since there is no articulated long-term strategy, troops on the ground lack sufficient context to make the correct tactical choices day-to-day that would be needed to reinforce the attainment of the strategy.  They try to make the correct decisions, but lack enough context to do so.

On the other hand, when there is nothing but a long-term strategy without any tactical idea communicated about how to best achieve the long-term strategic goal, this tends to lead to 'death by a thousand initiatives' where everyone on the ground tries in vain to follow their own ideas about how to best attain the long-term strategic goals.  Eventually, you end up with everyone in the team headed in a different short-term direction, but if you ask each of them why they are acting as they are, each will (capably) explain why what they are doing is in direct support of the long-term goal.  But with everyone headed in a different direction, the long-term goal can never be achieved.

Effective balance between these two is critical to the effective leadership of people.  

Vision without execution is daydreaming.

This principle is related closely to the prior principle and essentially says that big ideas without any concepts about how to get there from here aren't a vision, they are just fantasies.

This is true whether your vision is a corporate strategy or a software design approach; talking is great, but every now and then its important to spend time finding ways to make your vision a reality or else your vision is just a daydream without substance. 

Software Architects care WHAT software does, Software Engineers care about HOW.  BOTH ARE EQUALLY IMPORTANT.

This principle is an attempt to draw a correlation between the roles of architects and engineers in the software development world very much akin to the the role of architects and engineers in the building construction field from which my career began a number of years ago.  This principle tries to acknowledge that just as in the building construction world, there is a need for both roles in the world of software development.

There is tremendous invective and derision in the software development world between 'Software Architects' and 'Software Engineers' where neither considers what the other does to be of tremendous value.  To be sure, I have met in my travels any number of terrible 'Software Architects' and any number of terrible 'Software Engineers'.  I have also met any number of terrible building Architects and any number of terrible building Engineers.  But none of these experiences has convinced me that the body of knowledge that defines these peoples' areas of study is somehow of no value even if some of these people I have met certainly added little value to the project (a building or a software system).

Nobody (who knows what they are doing!) would suggest that constructing a building without engaging the professional expertise of both Architects and Engineers would be a good idea.  This principle says the same is true of developing software.  Somebody has to be concerned both for the WHAT and the HOW of the final software solution.

To be clear, a lot of people with 'Software Engineer' as their title are secretly also practicing 'Software Architecture' because someone has to do this task and their team lacks someone in that official role with that official title.  This is perfectly acceptable as this principle isn't about defining titles for business cards.  Instead it's about defining roles for a software development project independent of any title anyone may have or want and acknowledging that in the software development process, both roles are equally needed for the project to be a success.

I don't believe anything; it gets in the way of learning.

Despite the title of this post, this last one is perhaps the most important becuase it reiterates that what I know today is the sum total of all my experiences and knowledge acquired to-date and recognizes that there is a world of knowledge and wealth of experience that I just don't have (yet!).  I have to remain open to the idea that once I have more experience and knowledge some (or perhaps even all!) of what I current think to be true may in fact turn out to be wrong.  Belief in anything gets in the way of anyone's ability to learn anything new that might contradict their present beliefs.

At my current organization, we have been having a number of debates over the past 6-8 months about the relative benefits of writing unit tests for our code.  The opponents (ok, I will give the benefit of the doubt and call them 'skeptics' instead) trot out all the usual suspects here to bolster their skepticism:

• it takes time (the inference here is too much time) to write unit tests
• unit tests represent a brittle interdependency between two or more classes in my solution -- when my production app changes, I have to 'maintain' my unit tests to keep them passing
• I don't need unit tests, any idiot can look at my code and know its working as intended (ok, this one is tongue-in-cheek, but the thrust is accurate)

Reviewing the non-Unit-Test developer workflow

Putting aside for a moment the debate about test-first (test-driven) -development vs. test-after development work styles, let's take a look for a minute at a typical development scenario where there are no unit tests involved in the process...

1. developer creates a new class (lets call it MyClass), writes code to create a public method that does something; doesn't matter what, let's call it MyMethod().
2. developer needs to execute that method to ensure it works as intended but the method can't be run by itself because its in a class in a class library project (which cannot be set as the start-up project type for the Visual Studio debugger)...oops!
3. to solve this, the developer creates a stub or throw-away project (a console app if they are smart and efficient, a winforms app if they are just smart, or a webforms app if they are gluttons for punishment and complexity )  designed to do nothing more than just new-up an instance of this newly-written class (MyClass myClass = new MyClass(); ) and call the newly-written method on it ( myClass.MyMethod();)
4. using the VS IDE debugger, the developer steps into the body of MyMethod()  and starts inspecting the values of various private member variables at different points in the body of the method
5. eventually, the developer gets to the return statement in the method and inspects the value about to be returned from the MyMethod() function to ensure its the right value as expected
6. satisfied that the MyClass.MyMethod() is performing as expected, the developer ends the debugger session and moves on to the next development task in the project

I don't think there is a non-unit-test-writing-developer out there that would quibble substantially with the preceding overview of how they work.  There just isn't much choice in the matter and this pattern repeats over and over again through the entire project until all the work is complete.  The only variation has to do with the case where the results of step 4 or 5 don't come back as intended and the developer has to modify the inner workings of MyMethod() to fix whatever incorrect value is returned from step 5.  But this also is completely typical and repeats hundreds of times during the development of any software project.

Reviewing the Unit-Test developer workflow

Why do I point out the above workflow?  Because its actually eerily-similar to the workflow the same developer would go through if they were writing unit tests!  Let's evaluate this statement in some detail by looking at the steps this same developer would go through if writing unit tests to support their work...

1. developer creates a new class (lets call it MyClass), writes code to create a public method that does something; doesn't matter what, let's call it MyMethod().
2. developer needs to execute that method to ensure it works as intended but the method can't be run by itself because its in a class in a class library project (which cannot be set as the start-up project type for the Visual Studio debugger)...oops!
3. developer doesn't need to create a stub or throw-away project because the unit test runner is capable of executing class libraries without an accompanying .exe explicitly written by the developer; developer starts a new test-project and news-up an instance of MyClass inside a new test-method.
4. the unit-testing developer can skip step 4 (where the non-unit-test-writing developer uses the debugger to step into the inner-workings of the MyMethod() method-body); the unit-test-writing developer doesn't care about what's going on inside the method, just that its return value is correct -- the intent of the unit test is to confirm the publicly-accessible behavior of the method is correct, not that the internals are doing something in a specific way
5. the developer doesn't need the debugger to inspect the return value from the call to MyMethod() since he/she has instead written an Assert.<somthing> statement in the their unit test method that will inspect the return value from MyMethod() and the unit test framework will report back that the Assert passed or failed.
6. satisfied that the MyClass.MyMethod() is performing as expected, the developer moves on to the next development task in the project

Hey stupid -- you're actually doing unit testing already even if you don't know it!

The point of investigating these two workflow patterns compared to each other is to realize that even if you aren't actually writing unit tests, you are still doing all the same work!  Without unit tests, you are doing all the work manually and with unit tests you are asking the computer to do the work.  But the take-away is that either way, you are actually following the exact same process.

So if this is true, why write the unit tests?  Let's look at some of the commonly-touted benefits of unit tests for a minute...

• unit tests are repeatable; they can be run again and again throughout the life of the project to ensure that something just changed hasn't inadvertently broken something else
• unit tests are a statement about the valid behavior of your software; the method signature public int MyMethod(int) only says that MyMethod() is a function that takes and int and returns an int whereas one or more unit tests can bear out that the input int needs to be non-negative and the return int should be non-zero for example
• unit tests are a way to convey to any developer on the team the intended behavior of your code; in the preceding example, there are several ways to tell the rest of the team what you had in mind for the MyMethod() function call: you can litter the function itself with comments, you can expect someone to read through the entire method body to completely grok the entire function and determine its restrictions for themselves, or you can write one or more unit tests that not only communicate your intent to the rest of the team, but allow the computer to validate that your intent hasn't been inadvertently violated by others modifying the internals of MyMethod().

Not codifying your work in Unit Tests is actually less-efficient than writing the tests!

The bottom line is really this: the non-unit-test-writing scenario presented above has the developer going through nearly the same effort as the unit-test-writing developer.

But in the first scenario, all of the developer's effort to get to a 'success' in the development of the MyMethod() function is completely thrown out after the method is written.  For anyone else (or even the same original developer!) to reproduce this effort requires them to manually step back through the debugger all over again to re-investigate whether they may have inadvertently broken the MyMethod() function's behavior by any changes that they have made to it directly or to other parts of the codebase that indirectly affect MyMethod().  This need to repeat all this overhead leads to 'developer testing laziness' where eventually the application is just too large to step through everything in the debugger to ensure an accidental side-effect wasn't introduced in one area by a change in another.  Instead the developer just 'knows' (guesses! ... hopes!) that nothing else was adversely effected by the work they just did.

And weeks or more later, who's to say what even is the proper behavior of MyMethod()?  Is it in the comments within the method that someone may have failed to bother to maintain?  Is it just in the method signature that says 'thou shalt return an int' ?  Without unit tests that can be run to validate that expectations are still being properly met by the codebase, who is actually to say what's correct?

Definitions of Legacy Code

Everyone reading this (assuming you are a developer with more than 2 months experience in the real world) has at one time or another likely been faced with a 'legacy application' that you need to extend or maintain to some degree.  There are several definitions of legacy code that are traditionally bandied-about...

• code written by anyone but yourself
• code written in a deprecated language (i.e., COBOL)
• code written in a 'current' language but in a deprecated style (i.e., using C# but as if a procedural programmer got ahold of the framework libraries reference without understanding OO concepts)

But my favorite definition is perhaps the simplest and most-encompassing:

• any line of code not covered by a unit test!

Why is this my favorite definition of legacy code?  Because the main reasons why the preceding definitions are used by so many to identify legacy code are that they all share some of the same characteristics...

• non-resilient to change; interdependencies abound and a seemingly innocuous change in one small corner of the codebase can have disastrous and unanticipated consequences for the rest of the application
• no (efficient) way to make a change and discover if you have inadvertently changed something that has a cascading impact on other areas of the codebase; this leads you to have whole sections of your application that are just 'hands-off' for making any changes because "nobody knows how it works so we dare not touch it".  Over time, eventually the entirety of your application is like this, leaving no way at all to modify anything and user requests like "can we change the title of that window?" take two weeks to accomplish because the window title was actually the way the app knew how to process requests or something equally bizarre and to change it means touching -- and manually retesting -- everything in the whole app all over again!)
• poor (if any) documentation about what's supposed to be the intended behavior of the various parts of the codebase; sure the compiler can tell us if our changes are syntactically correct, but who knows if the entire app will still compile fine but return the wrong answer to some crucial calculation it makes?

Conclusion

The most important thing about this definition of 'legacy code' (any line of code not covered by a unit test) is that its got nothing to do with its age.  Code written last week can look like legacy code even to someone else on the same project.

So, if you write code without unit tests then congratulations to you: you have just written a brand-spanking new line of legacy code that nobody (not even yourself after even a surprisingly trivially-short period of being away from it) will be able to effectively maintain.

But if you do write unit tests, then you have ensured that anyone (including yourself) that comes back to make changes to the code you just wrote will be able to effectively, efficiently, and safely make those changes in a minimum of time and with a maximum of confidence that nothing else has been broken.

And if you're lucky enough to have been on the one software development project that never needed to have its code edited, never needed to have its capabilities extended, and never needed to have a bug fixed, then please drop me a note -- we'd LOVE to hire you at any salary level because that kind of perfection is priceless in this industry .