Caffeinated Coder

Not too long ago, someone asked me to explain the fundamental differences between static languages, such as C# and Java, and dynamic languages, such as Ruby and Python.

Although I knew that duck typing and not resolving method references until runtime allowed for some nifty metaprogramming tricks that translated into not having to write as many lines of code, I was not able to provide any concrete examples of how this was done. This left both me and my friend feeling unsatisfied with my explanation.

Although learning about something at a high level through books, blogs, and podcasts can be useful, I often find that it tricks me into thinking I know more about something than I actually do. I’ve just had way too many experiences where I thought I understood something only to be proven wrong when I finally had the opportunity to roll up my sleeves and tackle some concrete examples and problems.

This is why I have recently been on the look out for some more concrete examples of how dynamic languages allow for some nifty feature that just aren’t possible in static languages (or at least too difficult to be feasible).

I finally found a good one this last week while reading about Dynamic Finders in the book Agile Web Development With Rails. These are convenience methods provided by Rails that allow you to query on various columns by simply following a naming convention for methods that concatenates Find_By or Find_All_By with the column names you want to filter on.

So, instead of having to create and implement a method like this (example from Castle’s Active Record):

   1: public static Card[] Find_By_CardType_And_ExpirationDate(int cardTypeId, DateTime expirationDate)

   2: {

   3:     return FindAll(Expression.And(Expression.Eq(“CardTypeId”, cardTypeId),

   4:                                Expression.Eq(“ExpirationDate”, expirationDate)));

   5: }

   6:

   7: …

   8:

   9: Card[] cards = Card.Find_By_CardType_And_ExpirationDate(cardTypeId, expirationDate);

All you have to do is make the call to the non-existent method that contains your column names and Rails will dynamically generate the method for you.

   1: @cards = Card.find_all_by_cardType_and_expirationDate(cardTypeId, expirationDate)

How does this work?

Unlike with static languages, Ruby doesn’t require that this method actually exists at compile time. Instead it just throws a MethodMissing exception at runtime if the method you called doesn’t exist and then allows you to react to this condition by simply defining\overriding the required method_missing signature in your class.

In order to provide Dynamic Finder functionality, Rails uses something like the Regex logic below to parse the method name that was passed in to the method_missing override and then use the resulting tokens to dynamically generate the method and its implementation, “spot weld” it onto your class, and then execute it.

   1: def method_missing(method_id, *arguments)

   2:   if match = /find_(all_by|by)_([_a-zA-Z]\w*)/.match(method_id.to_s)

   3:     # find…

   4:   elsif match = /find_or_create_by_([_a-zA-Z]\w*)/.match(method_id.to_s)

   5:     # find_or_create…

   6:   else

   7:     super

   8:   end

   9: end

Neat, huh?

I found this example particularly compelling because I am working with both frameworks right now and so far find Castle’s implementation to be remarkably similar to Rail’s Active Record even though it was created using a static language (C#).

The fact that Dynamic Finders aren’t available in Castle’s Active Record and that they are implemented by a decidedly dynamic feature leads me to believe that this was one of the areas that dynamic languages outshines static languages. However, I am a self-avowed newbie in this area, so I welcome anyone with a deeper knowledge of either framework to correct me if I’m wrong.

I would also love to hear about any other concrete examples of metaprogramming magic that is made possible (or much easier) by a dynamic language feature.

If you’re interested in learning more about dynamic languages, then I highly recommend Steve Yegge’s recent blog post, Dynamic Language Strike’s Back. It’s a rather lengthy transcription of a recent talk he did at Stanford on the topic, but it addresses some questions I had about dynamic languages in terms of tooling, performance, and maintainability in some very novel and comprehensive ways so it was well worth the reading investment.

No related posts.

I’ve been working a lot with Castle’s Active Record and Ruby on Rails in the last month and as a result have written significantly fewer basic CRUD operations and database access code. It’s been an addictive experience and has caused me to rethink the proper role of hand-written database code (sprocs) within an application.

Although I feel perfectly comfortable in a set-based world writing SQL, it has traditionally been one of my least favorite areas of coding. Besides being relatively repetitive and tedious, at least when it comes to basic CRUD operations, sprocs are much more difficult to handle when it comes to source control, versioning, debugging, and unit testing.

For example, at my last job we were tasked by auditors to come up with a build and deployment process that included version traceability and rollback capabilities. It was pretty easy to put together an acceptable solution for assemblies, since automatically versioning dll’s in a trusted way is simple via the AssemblyInfo and rolling them back is trivial since everything is contained in a manageable number of dlls that simply need to be copied from one folder to the next. When it came to sprocs, however, the best we could offer auditors was some hackery around adding comments about the version at the top of each sproc definition file along with a big disclaimer that there was no guarantee that files were not modified by DBA’s along the way.

At my current job, database code causes us even more trouble because the database is larger and contains more sensitive data (thus making restores more difficult), there is a heavier reliance on shared code, and only the deltas of database code are currently under source control. It feels like I am constantly tracking down some ghost bug that is caused by my local database schema somehow being out of sync with the codebase.

Despite these misgivings, I’ve dutifully followed the traditional Microsoft recommended best practice of funneling all data access through sprocs up until recently because sprocs were supposedly faster, more secure, and provided a beneficial layer of abstraction.

Although I have heard several arguments against sprocs in the last several years, I recently embarked on a more thorough investigation while trying to convince my team to switch over from using an in-house code generation\sproc-based solution for data access to using NHibernate\ActiveRecord. Here are a few resources I found that present good counter arguments against the conventional sproc wisdom.

1. Stored procedures are bad, m’kay?: This classic post that was written by Frans Bouma of LLBLGen fame in 2003 spawned quite the flame war on the topic. Most notably, Frans counters the “Sprocs are faster because they are compiled” argument by quoting passages from the SQL Server BOL documentation that clearly suggest otherwise. He also counters security arguments by pointing out that parameterized queries prevent SQL injection just as much as sprocs and that assigning permissions to views and roles provide just as much protection as assigning execute rights on sprocs.
2. Who Needs Stored Procedures, Anyways?: This is also an older post from Jeff Atwood where he nicely summarizes the negative aspects of SQL when compared with a traditional coding languages and came up with the quotable phrase “Stored Procedures should be considered database assembly language: for use in only the most performance critical situations”. I definitely think that some developers are reluctant to embrace ORM’s for the same reasons that many old C++ programmers scoffed at the idea of letting the CLR garbage collector manage memory for them instead of manually doing it themselves with raw pointers.
3. Why I do not use Stored Procedures: Jeremy Miller dismisses performance arguments by declaring them instances of premature optimization and elaborates on all the problems caused by sprocs when it comes to maintainability, testability, and architecture. He also points out that the touted benefit of allowing DBA’s to make changes is actually a dangerous practice since it represents a breaking API change from the application’s point of view and thus should go through thorough regression testing before any DBA should be allowed to make changes.
4. Foundations of Programming - Part 6 - NHibernate: Besides offering a nice introduction to NHibernate, Karl Sequine provides a nice summary of the historical sproc debate, including a counter point for the increased network traffic argument, which he says is a moot point since most traffic occurs between a app and database servers sitting on the same internal GigE networks where bandwidth is fast, plentiful, and free.
5. DotNetRocks ORM Smackdown: For a more balanced debate, listen to this podcast episode (or download the transcripts) where Oren Eini and Ted Neward face off over the value of ORM’s in the software industry. Be sure to check out the commentary on the episode in the comment section of this Ayende post as well as the rebuttal in this post by Ted Neward.

In my opinion, one of the strongest denunciations of traditional sproc dogma comes Redmond itself, which seems to be straying from its original sproc recommendations in favor of a more more dynamic SQL generation world-view with its recent release of LINQ to SQL and the Entity Framework.

If you follow the open source world or program in some language other than .NET, then you’re bound to feel a little smug right now because ORM’s have been around for a long time. In fact, I have a vivid memory from 6 years ago of a co-worker who was fresh from the Java world being dumb-founded that Microsoft didn’t have any ORM solution. He was used to using HIbernate and the thought of manually mapping database tables to domain objects was hard for him to grasp. Even in the .NET open source world, I’ve been reading blog posts that sing the praises of NHibernate and IBatis.NET, two popular .NET ORM ports, for several years.

On one hand, Microsoft’s entrance into the fray is good news for ORM enthusiasts since it means that a larger audience of developers will begin to see the technology as legitimate. On the other hand, Microsoft clearly has some catching up to do in this space, so you might want to think twice about starting off with Microsoft’s offering rather than one of the more proven open source or third party alternatives.

If you are a .NET developer and new to ORM’s, then I recommend starting out with Castle’s Active Record, which you can learn in less than an hour by reading this Getting Started with Active Record tutorial. My co-worker’s were reluctant to try NHibernate because of the perceived learning curve and the plethora of mapping files required, but they quickly agreed to use Active Record after only a short demo.

If you are a POCO purists, which means that you want to keep your domain objects free of any non-business related concerns (such as persistance), then you’ll want to follow the repository pattern using the ActiveRecordMediator class rather than inheriting from ActiveRecordBase like the tutorial shows. Some of the more experienced ORM users seem to see ActiveRecord as more of a gateway drug to NHibernate and ultimately prefer to forgo the conveniences offered by the ActiveRecord layer in favor of the increased flexibility and loosely coupled design offered by dealing directly with NHibernate instead.

Regardless of the approach taken, I definitely no longer believe that sprocs should play any significant role in any application. The current mandate in the software industry is to strive to lower costs by increasing developer productivity and ORM’s clearly help to do this by eliminating the need to write and maintain countless simple CRUD sprocs.

It’s definitely time for all of us .NET developers to abandon our convention sproc wisdom and start playing catch-up with the rest of the industry when it comes to using ORM’s.

No related posts.

In my last post I mentioned that I had recently decided that it was time to overhaul my approach to managing tasks. The changes I implemented were mostly inspired by a book by David Allen called Getting Things Done and I have been extremely pleased with the results so far. As promised, here are some of the concrete ideas that I’ve adopted and incorporated over the last month.

1. Following a Workflow: I found that my procrastination was mostly fueled by not knowing where to start on something or else feeling that it was too big for the small time slots that I usually had available during the day. Following this workflow whenever I a faced with a new item in my inbox gives me an automatic starting place and a way to boil down a massive, disorganized, tangle of items into a relatively small set of very specific tasks that I need to do.
2. Treating Collecting, Processing, and Doing as Different Activities - The workflow diagram really only covers the processing part of the equation, which is where you make decisions about things. Two other distinctly different activities are collecting and doing. Collecting simply means recording items that are floating around in your head and placing them into some kind of trusted inbox so that you can process them later (I use rememberTheMilk.com, a Samsung smartPhone which syncs with rememberTheMilk.com, my email inbox, a physical inbox on my desk, and delicious). The idea is that each process requires a separate type of thinking, thus context switches detrimental in terms of productivity and effectiveness. I find that I also gain the most benefit in terms of peace of mind by completing the collecting and processing stages before I attempt to actually do anything (with the exception of the 2 minute rule below).
3. Transitioning from To Do’s to Next Actions - My TO DO’s used to be very vague, like ‘Get Supplemental Life Insurance’. Now I take the effort to formulate the exact action I need to take and then attach any relevant information that I will need, such as ‘Call Mark (xxx-xxxx) and ask for quote on 20 year, $xx term life policy’. Since all the preliminary decisions and information gathering have been done, I am finding that I am much more likely to actually do it when I have a free minute during the day.
4. The 2 Minute Rule - If I grab a task from my inbox that will take less than two minutes, I just do it. This keeps my list short. If it will take longer than two minutes, I force myself to put it in one of the ‘deferred’ piles (Next Action Lists) until I am finished processing so I don’t get distracted and run out of time before the processing is done.
5. Grouping Tasks according to Contexts - Another helpful hint that I picked up from the ‘Getting Things Done’ book is to organize my Next Actions according to the context required to do them (call, errand, home, work, computer, etc.). Now, whenever I am out running errands, I scan my ‘Errand’ list to see if there is any other errand I can tackle that is close to where I’ll be. I’ve been surprised at how much more I get done now that I’ve picked up the habit of scanning the appropriate context list based on where I am and what I am doing whenever.
6. WaitFor List - This is a very useful list where I now track everything that I am waiting for (the phone company to send me a rebate, the insurance guy to send me a quote, my wife to make an appointment, etc.). I set due dates on them so that I know when it is time to start bugging somebody if things aren’t getting done.
7. Someday List - By explicitly separating all the things that I am explicitly agreeing to do (my Next Action and Project lists) from the things that are interesting to me but not appropriate to tackle at the current time, I dramatically decrease my tasks list and don’t feel nearly as guilty for those things that I’m not choosing to do at the moment.
8. Reference Materials - I realized that a lot of items that I thought were TO DO items were simply things that I needed to keep as reference in a system that would allow me to quickly retrieve it when and if I should ever need it (that meant overhauling my existing black-hole-of-a-filing system). To have a good filing system, you really need to take an agile approach and constantly tweak it as new items come in and old ones become obsolete. The best way to do this is to buy an electronic label maker ($30) so that you can quickly relabel folders in a way that is neat and easy to read.
9. Delegating and Deleting - These were two activities that I was not nearly aggressive enough with over the years. By having these questions as part of the workflow, I find that I am more likely to weed items out by throwing them away or letting someone else do them instead who is better suited to the task in the first place.
10. Using Projects to Organize Multi-Step Actions - I found that the items I was most likely to procrastinate on were the things that had multiple steps involved but were too small to traditionally be considered a project. David Allen recommends considering these to be a project, which he defines simply as a place holder that is useful for periodically generating Next Action items and organizing supporting material. This is great for smaller projects because it naturally lends itself to breaking things down into more manageable chunks. He also has some great suggestions for larger projects in terms of defining goals, envisioning outcomes, and brainstorming possible tasks.

If you’re interested in learning more about these concepts, I definitely recommend buying the book (which is a quick read) or visiting some of the resources here.

Related posts:

• The Joy of Freeing Up Mental RAM

I’ve always been somewhat prone to procrastination, especially in my personal life, but I’ve watched with growing trepidation as my task list has slowly grown out of control over the last several months.

Part of this trend is due to being a new parent. I expected that having a newborn would consume the majority of my free time, although I must admit that it didn’t completely sink in until it happened. What I didn’t expect was that my “honey-do” and “male provider” lists would also grow dramatically as my both mine and my wife’s biological instincts kicked into high gear. Meanwhile, my list of new tools and technologies to explore continue to mount as suggestions pour in from twitter, my blog, and my RSS reader.

The result is that I have many times more tasks to do than before but now I only have a faction of the time to get them done. This new reality has left me feeling overwhelmed, paralyzed, and generally less productive with the time I do have.

A few weeks ago I finally came to the conclusion that I needed to severely overhaul my approach to managing my tasks if I ever had any hope of feeling calm and productive again. Someone on Twitter suggested I pick up a copy of David Allen’s Getting Things Done book, so I started there. I’ve always had an aversion to business self-help books, but desperate times called for desperate measures so I picked up a copy in the bookstore.

I was surprised by how quickly my skepticism disappeared. I was especially sold on the author’s clear explanation of the negative consequences of relying primarily on our brain (mental RAM) to juggle all of our TO DO’s. Not only is this common approach tremendously inefficient since our brain randomly reminds us of things we need to do repeatedly at times when we can’t usually do anything about it, but it also perpetually consumes a limited resource (especially in my case) thus slowing down our overall mental functioning. In other words, it is like trying to get something done on your computer while running a dozen instances of Visual Studio 2008. You can do it, but it just isn’t what I would call an optimal experience.

The premise of the book is that it is possible is overcome this dynamic and achieve a calmer and more productive state of mind by simply transferring all of your tasks from your head to a trusted external system. In GeekSpeak, it would be the equivalent of flushing all those nagging thoughts from RAM to disk, which makes sense since you really only need them in memory when you are actually in a position to do something about them.

This analogy, along with the remarkably clear and helpful diagram below, convinced me to make a several week investment in optimizing my approach to getting things done.

The results have been dramatic. Not only do I feel like a huge psychic weight has been lifted from my shoulders, but I’ve completed a huge list of tasks that I had been procrastinating on for months and in some cases years. I also find myself fitting tasks into much smaller chunks of time during the day because I have organized them in such a way that they take much less mental energy to tackle, thus I no longer feel that I need to set aside a huge block of time to do them.

Even more surprising is that I find that doing things on my “Next Action” list is slightly addictive. Crossing off an item feels like lightening the load by removing something from a heavy backpack I have to carry around with me everywhere I go. There is an immediate relief in it.

If any of this sounds familiar to you, then I would recommend picking up a copy of David Allen’s book. It’s a very quick read.

For those of you that are intrigued but not sold enough to actually buy the book, stay tuned for my next post where I’m going to share all of the concrete tips that I’ve edited out of this post so as to keep it a reasonable length for a change.

Related posts:

• 10 Practical Tips on Freeing up Mental RAM

I firmly believe that the answer to this question is…yes.

A Little Background (a.k.a. My Hermit Roots) - Like most geeks, I’m an introverted fellow by nature. I’ve never had trouble mustering the requisite polish when it came to interacting with clients and executives on the job, but when given a choice I would always rather be absorbed in code with my headphones on and a ‘do not disturb’ look of concentration on my face. Until recently, I preferred keeping to myself when it came my professional development and problem solving endeavors and routinely chose thick technical books, laser-focused research, and solo debugging efforts over blogs and community forums. I didn’t really see the point of developer communities and I doubt that I had a single person in my professional contact list that I didn’t know directly through a current or prior work experience.

The Slippery Slope into Community - I didn’t start to change my solitary ways until a few years ago when I finally decided to start subscribing to blogs in earnest (I know that I was extremely late to the game on this one). Before long, I graduated to leaving comments and then eventually to writing posts on my own blog, thus firmly entering into the realm of geek community by publicly exposing my own thoughts to the world for examination and potential (…ok probable) ridicule. Finally, through the magic of Twitter, OpenSpace conferences, and social networking sites, I began interacting with my fellow kindred geek spirits on a more informal basis and getting to know many of them personally. At the last conference, I was shocked when I realized that for the first time ever I was more excited to meet and interact with the other participants than I was to listen to the content of the sessions. That was the moment I first started to realize that my understanding and appraisal of geek community had significantly shifted.

A Place of Extremes - In the short time that I made the journey from geek hermit to neophyte community member, I have experienced the following highs and lows.

First the good…

• Real World Experience over Theory - Most of the content I see in traditional articles, books, and Knowledge Base entries seem overly theoretical and shallow because many are often based on idealized vendor technical specs or the author’s limited experiences with pet projects and demo applications. By contrast, many of the blogs or twitter rants I read are from people on the corporate front lines who are constantly dealing with the edge cases and pushing the limits of the technology. Despite being less polished than their more formally published counterparts, community based sources of information often yield much more valuable hints, insights, and warnings.
• Analysis and Recommendations over How-To - While traditional learning venues almost exclusively focus on the HOW, community discussions are often centered around the WHY. In the age of google, learning HOW to use a new tool, framework, or API often borders on the trivial, but figuring out which one to use can become an overwhelming decision. This is where being part of a network of really smart people who readily share knowledge and experience can really pay off.
• Perspective - No matter how large your IT department is, your work will be confined by a particular culture and set of technologies and practices. By contrast, online communities are usually comprised of developers from all over the world and thus offer fresh ideas and needed reality checks that you just can’t get from your co-workers. While your co-workers may be fearful or too polite to challenge your latest dumb idea, you can rest assured that developers you interact with ‘in the wild’ will be brutally honest.
• Camaraderie - Besides being a source for excellent recommendations and discussions, I find Twitter and the comment sections of blogs to be a place where I can relieve some stress from the day by being able to joke or rant. Sometimes the lack of “face to face” social constraints has a very positive affect and allows people who are normally quiet and serious in a work setting (like me) to be much more light-hearted and humorous in a virtual community. The Canadian blogging circuit in particular (Justice, Donald, D’Arcy, Tom, et. al) has been a reliable source of comedy relief for me over the last few years.

Now the bad…

• Anonymity Breeds Meanness - If you haven’t been personally zapped by an unnecessarily rude comment, then you haven’t spent much time in online discussions. In a process that makes road rage look tame, the anonymous aspect of online interactions can turn normally sane people into ranting, frothing-at-the-mouth maniacs.
• The Need to Shrink the World - The first time I looked at the world map of my readership base in google analytics or scanned the diversity of topics available on reddit, I was struck with the uncomfortable realization that the world was unbelievably ginormous place. Unfortunately, the first reaction that many have to this psychological shock is to try to shrink the world back down to a manageable size by dividing it into a small select group of enlightened technical wizards (to which they belong) and a massive group consisting of the rest of the dimwits. This is the driving force behind the formation of so many identity cliques that divide people along otherwise trivial lines with a frightening religious-like fervor (i.e. Mac vs. Linux vs. PC, Microsoft vs. Sun, Dynamic vs Static languages, Mort vs. Einsteins, etc.). The world is just a more manageable place if you have justification to dismiss a large portion of it as irrelevant.
• Flame Wars and Twisticuffs - As egos collide and tempers flare, even the most reasonable discussions quickly degrade into purse fights, twisticuffs (twitter fisticuffs), and flame wars. When this happens, the geek blood lust takes over and the pursuit of knowledge takes a back seat to the all consuming goal of winning the argument. I have occasionally been sucked into these “Lord of the Flies” type spectacles and I’ve always emerged feeling drained, dumber, and ashamed of myself.

What to Do? I admit that I occasionally have days where I am tempted to crawl back into my introverted shell and seal myself off permanently from blogs, twitter, and all other forms of geek community. Despite the silliness, meanness, and time-wasting qualities that lurk behind some online community interactions, I still have to conclude that it is the only viable option for a geek looking for self-improvement.

Nevertheless, before diving headfirst into community, you’ll need to learn to recognize the potential pitfalls and devise strategies for avoiding them. This could be as simple as unfollowing, unsubscribing, or generally avoiding people who trigger your geek rage or it could involve a more radical approach of taking a periodic hiatus from the online world to recharge your batteries. Failure to do so could lead you down the path to the geek dark side and eventually turn you into one of those curmudgeonly old trolls that lurk on mailing lists waiting for their next unsuspecting newbie victims.

In the spirit of community interaction, I leave you with the following questions for you to ponder and respond to:

1. What are the other positive and negative aspects to geek community?
2. Do you really think community is the fastest way to self-improvement?
3. If you are a believer in community, how do you avoid all the negative aspects?

No related posts.

As I mentioned in this last post, the Austin Alt.NET conference last fall was one of the best conferences that I had ever attended. Nevertheless, I liked the second one in Seattle this last weekend better.

Here are a few reasons why:

1. Alt.NET has finally been defined - There was quite a bit of time spent at the first conference and in the news groups afterwards arguing about fundamental issues like what Alt.NET meant and whether or not the name was too divisive. Although these questions were important to hash out in the beginning, the topic quickly grew stale for me and I certainly didn’t relish the idea of listening to even more debate about it. Apparently I wasn’t the only one that felt this way because the only mention of it was a topic suggestion done in jest about renaming Alt.Net which was promptly greeted by groans and eye rolling. No longer having to deal with this mental baggage meant that there was much more time to focus on substantive technical issues. For example, I was pleasantly surprised when the opening night fishbowl immediately delved into a top notch discussion about whether or not polyglot programming is a desirable industry trend.
2. Open Space Format No Longer an Issue - Another roadblock that caused the first conference to get off to a slow start was the skepticism regarding the Open Space format. While everyone eventually warmed up to this approach, I remember quite a few sarcastic barbs the opening night that were funny but ultimately detracted from the quality of the discussion. The fact that the organizers didn’t really have to waste any time explaining or converting people to the Open Spaces philosophy this time around was another contributing factor to how quickly discussions became productive.
3. Better Mix of Geek Celebrities, Alpha Geeks, and Regular Geeks - Expanding the participant list to 150 and reserving 50 spots for invitation only celebrity geeks was a stroke of genius. The mix at the first conference was great, but the mix at this one was even better. In my opinion, the biggest threat for future conferences in terms of “jumping the shark” would come from altering the number of participants or unique geek ratio too much.
4. Microsoft Employees No Longer on the Defensive - In Austin, I definitely got the sense that Microsoft employees were either walking on eggshells or else (often legitimately) defensive. Since then, I believe that the ALT.NET group has collectively decided that the ideology\movement is ultimately grounded in .NET and thus the purpose of the group is to push Microsoft into improving the current development experience rather than trying to instigate a mass exodus of developers to other platforms. I think this shift in mind set made a huge difference in how productive conversations were and how willing prominent Microsoft employees were to attend. Some of the more notable Microsoft attendees included Scott Guthrie, Scott Hanselman, Phil Haack, Brad Abrams, John Lam, Dustin Campbell, Glenn Block, Howard Dierking, and many more.
5. More Focus on Positive Examples of Microsoft Technologies- Instead of focusing too much on canonical examples of tools and technologies that Alt.NET’ers have traditionally criticized, such as the Entity Framework, Enterprise Library, or SSIS, many of the discussions focused around technologies that are being received more warmly, such as the MVC Framework, IronRuby, IronPython, and F#. Besides demonstrating how scary smart he was by diagramming out some of the internal implementation details of the DLR, John Lam impressed many Alt.NET’ers by mentioning things like his regular IM conversations with the head of the JRuby project or his team’s painstaking efforts to move towards passing 100% of the Ruby community test suite. Phil Haack enjoyed similar kudos for the efforts that he and his MVC team have made to solicit and incorporate community feedback into their product as well as learn from existing MVC frameworks in the industry and even openly release the source code.
6. Leadership - I hesitate to even mention this one because Scott Bellware contributed so much to the first conference and he was so relaxed and agreeable this weekend. But let’s face it, as a conference leader, David Laribee just doesn’t have the same baggage to contend as Scott Bellware, whose publicly confrontational demeanor tends to cause friction at every turn. Despite poking fun at him from time to time on my blog, I respect Bellware and wish he was still blogging, but I have to admit that I’m glad that Laribee took over the organizing reigns for this conference. By the way, be careful about complimenting Laribee on how well the conference was organized or he will try to rope you into helping organize the next one…:-)

So what about a future Part 3 to this conference series?

I heard about 3 different potential follow up Alt.NET conferences this weekend that would take place in Canada, Austin, and possibly Boston. I’m not sure which one will emerge as the next viable option, but I’m definitely going to stay alert for any news.

I don’t know if the next conference will be as good as this one, but the odds are that it will still be much better than the passive, spoon fed material that you can expect from traditional conferences.

Related posts:

• Scott Guthrie Gets an Image Makeover
• Ode to the ALT.NET Conference Organizers

I’m currently en route to Seattle to attend my second ALT.NET conference, so I thought I would take the opportunity to organize some pre-conference thoughts.

ALT.NET in a Nutshell (at least by my reckoning)

Alt.NET is a nascent, loosely organized ideology that started as a vibrant blogosphere reaction to this post by David Laribee and has since evolved into a number of conferences, user group meetings, and mailing list discussions.

Alt.NET conversations I’ve followed tend to focus on…

• Shifting the emphasis away from the latest and greatest API and towards a discussion of sound principles and practices that transcend specific technologies.
• Shunning “Demoware” and visual designers that offer quick, flashy functionality at the expense of long-term maintainability.
• Taking a “best of breed” approach to tools and frameworks and frequently looking to the open source community or competing vendors rather than the traditional Microsoft fare to enhance the .NET development experience.
• Fostering a healthy debate regarding the best way to develop software, thus shifting learning away from a vendor-centric, how-to learning experience toward a more interactive dialog.

The canonical example of an Alt.NET view of the world is the vocal criticism by many in this community of the Entity Framework. Most Alt.NET’ers prefer open source ORM alternatives, such as NHibernate or Ibatis.NET, because unlike the Entity Framework they follow the principal of persistence ignorance, which removes database dependencies from the code thus allowing business objects to be tested more easily and cheaply. While this position may seem like common sense to many, it is considered “Alternative” to most because it challenges the default behavior of many executives and mainstream developers who are more comfortable with following Microsoft’s lead on all technical issues.

If you want more information on the question of “What is Alt.NET?”, I recommend reading this short MSDN article by Jeremy Miller . If you have some free slots in your podcasting queue now that lawn-mowing season has started, then I also recommend the Hanselminutes episode with David Laribee or the recent DNR episode with Laribee and Jeremy Miller. You can also read about some of my own impressions of the first conference in Austin along with a humorous pictoral retort that I put together in response to some of the public criticisms of the conference being too elitist.

Why am I in the cheap seats?

A quick glance at the participants list reveals a high number of well-known speakers, authors, tool creators, and bloggers. I was a little bit star-struck by being surrounded by such a high concentration of geek fame during the last conference and this time around the participant list is even more impressive. I would consider this group to occupy the box seats in my little sports event analogy and I’m not even close to being there. In fact the guards would probably beat me mercilessly if I even deigned to stare wistfully at this section for too long.

Next comes the middle seats. These are the ones occupied by the B-List bloggers and dedicated open source contributors. I hadn’t heard of many in this group before, but was duly impressed last time with their extensive experience with topics that I only had a cursory knowledge of, such as Domain Driven Design, Behavior Driven Development, DSL’s, IoC Containers, MVC Frameworks, and Mocking containers. Unfortunately, I’m not in this group either.

That leaves the cheap seats. That is where those of us who are seasoned developers and agree with the alt.net principles, but have little experience with most of the tools and practices discussed at the event sit. Last time I mostly just shut up, listened, and tried to learn a few things while sitting in this section. Although lurkers are not generally appreciated at an open spaces event like this, I was at least comforted by the thought that I might eventually help spread the good word to my fellow Joe-developers back in the trenches.

I’m afraid I am destined to sit in the same section this time around. I’ll do my best to be a more active participant in conversations, but realistically I still don’t have enough experience with most of the popular ALT.NET tools and concepts to shed my lurker ways just yet. So, if you see a little unobtrusive speck high up in the nose bleed section of the conference, that is probably me.

What am I hoping to gain from the cheap seats of the conference?

1. Feel more stupid than I do now - My primary professional growth strategy so far has been to surround myself with really smart people in hopes that I will learn something by osmosis. I’m pretty sure this will be one of those situations. One unfortunate side effect of this approach is that I am perpetually humbled, which makes it really difficult to bask in the glow of a good old fashioned geek superiority complex. However, it is a small price to pay for all the fancy new developer tricks I learn.
2. Improve my criteria for evaluating tools and products - The one thing that prevents this type of gathering from devolving into a geek popularity contest based on which tools you use is the genuine attempt by most of the participants to define somewhat objective criteria by which to judge technology. For example, if I explain to my coworkers that we should use NHibernate instead of the Entity Framework and or the MVC Framework instead of WebForms, then I want to be able to articulate that these products are inherently more testable, which will help us modify our applications more quickly and with less risk. This type of approach tends to hold much more sway in the IT world than the old standby “all the cool kids are using it” argument.
3. Explore the development landscape - The .NET open source community may be relatively young and small compared to the Java community, but it nevertheless represents an overwhelmingly enormous amount of information for one person to sift through. When you throw on top of that the deluge of technologies being released by Microsoft as well as all of the relevant competing vendor products, then there is simply no way to adequately survey the development landscape other than through a sharing of ideas by passionate developers with diverse experiences in conferences like this.
4. Finally meet people I know - Huh? It sounds weird, but in the last year I’ve corresponded with a large number of people through blogging and tweeting. It seems that most of them will be in attendance this weekend. The small, open space format of this conference is ideal for making and strengthening professional contacts and becoming more engaged with the developer community. While google is still my fallback research tool of choice, I’ve been amazed at how valuable the daily conversations I have over email, twitter, and blog comment sections with like-minded developers all over the world can be. Hopefully this weekend will help me begin to tune into and use the developer community even more effectively.

In conclusion, I’m obviously excited about this weekend, despite my relatively lowly status on the ALT.NET food chain.

If you’re new to ALT.NET, I highly recommend attending one of the upcoming conferences or joining one the main mailing list to find out for yourself what all they hype is about.

No related posts.

I remember reading the eXtreme Programming Core Practices several years ago and smirking when I got to the practice that called for regular 40 hour work weeks for programmers.

Like many of my fellow developers, I saw overtime as a geek badge of honor and felt pride at having enough stamina to regularly work 60-80 hours a week on my death march project.

Although I occasionally received half-hearted warnings from management to slow my pace down in order to avoid burn-out, the underlying message from above was clearly that my willingness to work long hours made me an exemplary employee and that overtime was one of the surest paths to professional growth and advancement.

While I may have agreed with the XP practice of capping the work week at 40 hours in theory, my traditional geek machismo prevented me from accepting it as anything other than a naive and idealistic goal that would probably never be gain widespread acceptance in corporate America.

That was then.

Now, when given a choice, I rarely opt to work overtime for my employer (at least not directly according to my task list). I would never hesitate to work extra hours prior to a release or due to unexpected production problems, but I now view anything more frequent than that as a serious problem and even as a potential reason to start looking for another job.

Why the dramatic change in attitude?

Here are some reasons that finally caused me to stop seeing overtime as a heroic effort and start seeing it as a destructive practice that is a sign of a seriously broken process within an IT organization.

1. Lost Opportunity Costs in Professional Growth - Once I completed a handful of large projects in my career, the opportunities I saw for professional growth started coming more and more from external sources outside of my job. While I  still learn plenty during the day by observing my co-workers and attempting to solve common problems in novel ways, I often feel that my skills grow faster outside of work through reading, writing, presenting, social networking, and pet projects. It is sometimes tempting to spend 10 extra hours a week clearing the items from my daily TO DO list, but I believe that I am accomplishing much more for my professional career by devoting those hours to catching up on my RSS feeds, working my way through my tech book reading list, or exploring new programming languages instead.
2. Increased Professional Risk from Lack of Diversification - Everyone knows that diversification is the key to managing financial risk, but few people seem to apply this principal to their professional careers. Most developer shops are relatively limited when it comes to the number of technologies and problem domains they deal with. If you want to diversify your resume without job hopping every year, then it makes sense to actively seek out technology experiences that are different from the ones you use in your day job. By this reasoning, working overtime will increase your professional risk by reinforcing skills you already have whereas working on open source or pet projects that require you to learn new skills will mitigate your professional risk and make you more marketable should you ever decide to leave your current job.
3. Decreased Professional Passion - To paraphrase Jean-Paul Boodhoo, the best fuel for professional growth is always a developer’s joy and passion for his or her craft. I find it much easier to sustain this passion when I am allowed free reign to follow my curiosity. Work doesn’t usually allow for this type of unstructured exploration, but free time does.
4. Lost Productivity - Overtime work is highly susceptible to the law of diminishing returns. Spending long hours on the same tasks in a high stress environment leads to fatigue, which in turn leads to producing poorer quality work at a slower pace. When you factor in the time it takes to find and fix bugs and design flaws produced by overly tired developers, the net gain for twenty hours a week of overtime probably drops down to only a few hours while at the same time greatly increasing the risk to the project. Overtime just doesn’t yield the results promised by management Gantt Charts which provide an oversimplified view of the software development process by only measuring the quantity of the hours spent on tasks without also taking into consideration the quality of the time.
5. Poor Code Quality - Besides being more likely to miss obvious errors, developers who are under pressure and fatigued are far more likely to cut corners and engage in shallow thinking when it comes to design solutions. Besides driving up the long term cost of a project by making it more difficult to maintain, code quality issues can put the whole project or even business at risk by introducing critical errors and undermining customer confidence and loyalty.
6. Lost Personal Revenue - If you are a salaried employee and your are concerned with maximizing your personal income, then you should read this post by Max Pool where he points out that you are almost always financially better off to focus your time across multiple revenue streams rather than allowing your time to be sucked up by one job through excessive overtime.
7. The Usual Personal Reasons - These are all the usual things that workaholics neglect until it is too late, such as family, friends, health, and entertainment. Although I think they are among the most important reasons, many of us seem to have blind spots when it comes to these issues due to cultural biases so I chose to focus on other more novel arguments about overtime in this post instead. Nevertheless, these are some of the most compelling reasons to question any work schedule that consistently includes overtime.

If you are convinced about the evils of chronic overtime but don’t know how to break out of your current overtime cycle at work, then meditate on the following two concepts:

1. Time Should Be Fixed, but Features Should Always Be in Flux - If a customer went into a store and put more items in their shopping cart than they had money for, then they would reasonably expect to have to put a few items back while checking out. This is exactly how it should work in software, but the reality is often that customers naturally have a very difficult time connecting their feature requests to a real cost because IT departments have traditionally been so willing to hide the extra cost through overtime. Agile iteration planning and planning poker does a great job of addressing this issue by having developers assign a relative point cost to each feature, tracking an average velocity of points completed each week, and then only allowing customers to choose enough features to equal the velocity points in any given iteration. Besides providing a much more realistic expectation of what can be accomplished in an iteration, this approach emphasizes that developer time is a fixed resource and that feature requests must be variable based on continual assessment and reprioritization.
2. A Large Number of Proposed Project Features are Unnecessary and even Harmful to the Project - It is amazing how many "must-have" features suddenly become unimportant when a project is time-boxed and resource-boxed in an effective way. I’ve actually seen overall  product quality and customer satisfaction increase in these circumstances because it helps focus stakeholders on what is essential about a project and aids them in more easily spotting bloatware features that would otherwise delay implementation, increase cost, and hinder usability without returning discernible value.

Sometimes you just can’t change the way your processes work or management thinks, but you can always change your own attitude by resisting self-imposed or peer pressure to work overtime. I’m guessing that the majority of overtime is not officially mandated, but rather manipulated through subtle peer pressure. If that is the case, just say no.

If your goal is constantly to maximize your own professional growth, then you’ll be surprised at how much respect you can still win without playing the overtime game. For example, who do you think is going to get noticed more, someone who closes a few more issue in the bug tracking system, or someone who is able to introduce a new concept, process, tool, or technology to the group because of work done in their spare time?

In conclusion, the next time the opportunity for overtime arises, ask yourself if you are really maximizing your professional growth or if you are just focusing too much on short term job goals and not enough on long term career goals .

Related posts:

• What ever happened to that whooshing sound?

Don’t worry, I’m not going to join the growing ranks of developers with false claims of responsibility for the the Alt.NET pursefight blog (i.e. Bil Simser, Donald Belcham, Derik Whittaker, Sergio Pereira, Tom Openorth, David Woods, and Kyle Baley) .

My confession is way more shocking.

The more astute among you have noticed that D’Arcy Lussier has shown signs of instability and even mental illness lately. Who can forget the now infamous post that featured many Paint.NET atrocities that are now banned in most civilized nations?

The reason for this disturbing behavior is simple.

His entire blog has been an elaborate hoax that I invented while freebasing experimental, synthetically engineered, black-market coffee beans during a mind-numbing HR meeting one day.

Yes, I have been ghost writing the 50 plus posts a day for years under the guise of a batcrap crazy Canadian to keep up this charade. I even went as far as to hire a homeless guy who I found mumbling to himself on a street corner to impersonate this fictitious D’Arcy character of mine at various User Group meetings and conferences to lend credence to my misguided prank.

But no more…

Due to the recent addition to my family, I’ve decided to expose my blogging sins and turn full control of the blog over to the homeless guy, Burt. For those of you who actually do like D’Arcy’s blog, I’m sure that Burt will be able to maintain the quality of the content that you have grown accustomed to in between his frequent drinking binges.

Forgive me dear readers and may God have mercy on my soul for the havoc I have wreaked on the blogosphere with this cruel practical joke.

No related posts.

It is my great pleasure to introduce my new daughter, Sofia Isabel Ball.

She decided to make her grand entrance in the wee hours of the morning on the first day of Spring, March 21st, 2008. Sofia wiggled her way out into the world less than 90 minutes after we arrived at the hospital, thus demonstrating that she takes after both her mother and I when it comes to patience or rather lack thereof.

It has been a little over a week since she joined our little family, but I am just now emerging from my new parent stupor enough to give her a proper blogosphere introduction.

Below you can see me attempting to explain anonymous delegates to her.

Here are a few things that she has taught her newbie father so far:

1. Epidurals Keep Daddies Safe - Contrary to the mild false contractions that my wife experienced in the weeks leading up to that night, the actual labor contractions came on fast and furious. Despite treating all the red lights as stop signs on the way to the hospital, we still didn’t arrive until she was still over 8 cm dilated so she rode out a full hour of intense labor pains while the hospital staff did the prerequisite blood work, tests, and IV prior to administering the epidural. My primary responsibility during that time was endure her kung-fu labor grip, pretend that I wasn’t worried, and not say anything stupid. Once I surreptitiously removed my wedding ring, I was able to endure her freakishly strong grip, but all was nearly lost when I made the mistake of trying to sooth her by saying sh-sh-sh (in my defense it works for babies). She interpreted that as me telling her to be quiet and promptly yelled at me, much to the amusement of the nurses. I managed to avoid any further labor induced abuse until the epidural finally took affect, at which point I could probably have said just about anything.
2. Babies are more Addictive than Crack Cocaine - I distinctly remember rolling my eyes at people who fawned excessively over babies as little as 5-10 years ago. Now I am physically incapable of not grinning like an idiot every time I look at her. Other addictive behaviors that I’ve noticed in myself include staring at her features as though in a trance, taking ungodly amounts of photos, sharing baby stories with complete strangers, inventing a new pet name every 5 minutes, and reacting to toxic diaper born substances with enthusiasm rather than the normal repulsion.
3. WWF Style Swaddling - I am seriously considering writing a letter to the hospital and recommending that they have professional wrestlers rather than nurses demonstrate swaddling and diaper changing techniques. There is nothing like trying to swaddle a flailing baby at 4 am in a semi-dark room while sleep deprived to humble a man. I won’t even speak of the dangers of changing a stinky diaper in similar conditions for fear of traumatizing some of my younger readers.
4. The Truth about Sleep Deprivation - I can’t believe that I was actually foolish enough to think that my late night blogging habit would prepare me for the sleep deprivation havoc wreaked by a new born. On a good night, I’ve gotten a few hours of light sleep at a time (…was that the sound of the baby choking?). On a bad night, Sofia plays this game where she cries every time I put her down and then watches with big innocent eyes as daddy starts to hallucinate while pacing the halls with her. The worst part is that even though she is a perfect angel during the day, I still can’t do anything productive because my mental acuity is so diminished from the night before that I have to struggle to even keep up with reality TV shows. I recently heard that sleep deprivation is sometimes used as a torture technique and now I know why.
5. Best Activity to Soothe a Fussy Baby - My television repertoire is normally pretty limited since I am usually focused on my laptop whenever the TV happens to be on at our house. However, with a fussy baby in one arm and my intellectual capacities greatly diminished due to sleep deprivation, I have a whole new appreciation for TV. The best find of the week was definitely “My Redneck Wedding” hosted by Tom Arnold. I usually hate reality TV shows, but this one is pure comedic genius.

I’ll leave you with a few parting images:

This is Sofia trying to convince me that she needs coffee to wake up. I’ve decided to hold firm on this issue and not allow her to have any caffeine until she’s at least 2 years old.

This is me demonstrating to Sofia what to do during an Audit or HR meeting.

Finally, this is Sofia all decked out in her Road Warrior attire.

In summary, a) I love being a new daddy and b) please excuse the lower number of posts over the next few weeks as we all adjusts to the new lifestyle.

Related posts:

• A New Name For Caffeinated Coder Jr.