As a child I saw books all around the house. I remember seeing them in my dad’s office, in our living room, family room, and even by my parent’s nightstand.  With books going to digital formats more and more, my children will be less likely to see a book on my shelves as they grow older and will not ask, “What’s this book about” or “Hey dad would any of these be good for me to read.”  All of that is lost if all of my books are stored only in digital format.

As more books are delivered in digital formats will those piles of books disappear and reduce the desired reading of future generations?

The following is an email I wrote to the upper management in our company when asked about things we can do to improve the process and what are the next steps of things we need to fix in our application.  It remains mostly unedited and contains my thoughts on what will make our company better when it comes to the software we're writing.  It wasn't written as a blog post.  It wasn't until after I finished with it that I realized that it was decent content for a blog post.  You'll find a very "XP-ish" theme throughout, and that isn't necessarily an accident.  Hope you enjoy! Please leave feedback if something moves you.

Overview

The following contains my thoughts on software development at Super Awesome Company. While I can address the specifics of the project that I see need to be fixed and modified (the “what”), I am instead going to focus on how these items get fixed. I am choosing to do this because over time the new website will have bugs that need to be fixed, enhancements that need to be made, or new features requested. For the long term health of the project it does not matter so much “what” is implemented but rather “how”. For that reason I am avoiding specific project level tasks in this document and speaking at a higher level.

Software has been being developed for over 30 years. While the internet is relatively young, software development by comparison is not. Super Awesome Company will benefit from a commitment to good software development practices. Further, it takes a great deal of commitment and discipline to reap the benefits these practices can bring. Many of my suggestions are based on these principles, which are principles I have committed to learning and adopting over the last several years.

The overarching suggestion I would make is make quality the focus. In order to produce quality, we must slow down. In order to go fast you must go slowly. Sacrificing quality should never be an option. Consider a car manufacturer who needs to get 100 cars built in a single day. If they can only build 80 cars a day, is it better for them in the long run to get 100 cars out the door but have problems or 80 problem free cars? Building deficient cars carries more expense that just fixing the broken cars, such diminished brand reputation. If the goal is 100 cars per day, measures should be sought to increase production while keeping quality high.

We don't need to look too far to see where in a rush we've done something that we've had to revisit several more times because we were "going fast". We've been rushed for nearly a year and I can't say that we are any further along than we would have been had we approached the project more methodically. In some areas we may be further behind where we would have been since we "made sacrifices" to get things done, which have ultimately only put us further behind. Again, to go fast we must go "slow" (methodical). Put another way, quality breeds speed.

Any process, principle, practice we choose should have quality at its heart. Regardless of what process, principles, practices we adopt they will only be successful if we are disciplined enough to follow them.

Planning

Requirements

Requirements need to be clear and understood by all parties. Before developers set out to coding we need to have a clear understanding of what the problem is. The developer is not able to provide a solution until the problem is fully known and understood. Often the perceived solution to a problem is not the best solution. Failure to fully understand the problem/scenario results in rework.

Releases

We need to have planned releases. The timeframe can be discussed and agreed upon by the team. In order to have successful releases we need to plan each release. Each release should be broken down into smaller time frames, iterations. During the iteration the work should be stable for each developer. In other words, they know what they’re going to work on and accomplish (see requirements above) for any given time period.

Metrics

We need to be measuring metrics for the purposes of planning. If we get 10 units of work done each week on average and we have 20 units of work to do, we can easily figure out what is left to do. Without any metrics gathering we can’t do any planning and we’re really flying blind. This will also help with project post mortems. For example, the “web order manager” project was originally estimated to take a week worth of development effort. Three months later, it is still not finished. This is a combination of putting someone with limited knowledge of the business estimating the project, an overly aggressive developer estimate, and having no metric to pull from on how long something should take.

Flexibility

We need to be disciplined in the process of building software, but also realize when the process needs tweaking that we should respond and not be afraid to tweak the process to meet the needs of our team

Design

Simplicity

We should strive for simplicity in our designs. “Clever hacks” are often not healthy for the life time of the project. Simple designs are easier to understand and improve upon. Simple designs also allow other developers ease in working on code. This is much harder to do in practice but it always pays off in the long run.

Design aspects dovetail with testing (later in this document). Typically complex designs prove to be hard to test. When we write code based on simpler designs we’ll find that our code is easier to test. We want both, simple designs and easy-to-test code.

Coding

Standards

We should implement a standard for code development. Right now you can find three different styles/methods of coding in the code base. This makes it hard for developers to work on code they did not author. Projects I work on outside of work require all new code meet the standard, otherwise it is rejected until it meets this standard. As a consumer of these projects I’m always grateful when I can move through any of the project pieces and the code always looks the same.

Testing

Given the environment and complexity of the code, we need to require the developers to be able to test their code in an automated fashion. Visual verification is orders of magnitude slower than automated testing. Once an automated test is written, it runs every time. By having a large collection of tests we can makes changes to certain parts of the application and use existing tests as a safety net to verify nothing else has broken. We currently have over 1,150 tests (about 30% of code has tests) that run whenever someone commits code into source control. Those tests run in about 20 seconds. Imagine how long it would take a user to test each of those cases visually every time a piece of code changes.

Two weeks ago I sat in a meeting adding functionality to shipping and enhancing rules around shipping hazardous items to Canada while people were finding issues because of a solid base of tests. Before the meeting was over both issues discovered were fixed and tests were added for these specific issues so we would be guarded against this happening again.

Unit Tests

All code must have unit tests that can be run in an automated fashion. If the code cannot be unit tested (tested in isolation from other components) it should be restructured in such a way that it can be tested. Very few pieces of code are truly not testable. As such we should have very few areas in our code base which are not tested.

Proving Bug Fixes Through Tests

When bug is found a test should be written before any attempt to fix the bug. This test proves to the developer the bug exists but secondly gives the developer a marker to know when the bug is fixed. As a benefit, this new test acts as a guard against this particular bug ever happening again. This test, when first written, should fail because the developer has not fixed the bug yet. The developer should then work to make the test pass, and by extension fixing the bug. The cost of adding the test is very small when compared against having the test guard against this condition ever happening again.

Code Coverage

We should implement a standard for new code coverage, code that is tested by an automated test. I would recommend somewhere in the 80%-90% range for code coverage. In order to write tests the developers will be forced to think about their code a bit more thoroughly.

Pair Programming

We should adopt pair programming as a method to both increase shared knowledge but also as a means to quality. Pair programming is two developers sitting at one computer for a period of time while code is written. From the outside it may seem impractical to devote two developers to a single computer, thinking it is inefficient. Industry studies however show that code written in a pair has a four-fold benefit:

1. 15% less code– Studies showed that less code is written in order to implement the same functionality. Less code means less to maintain and understand. Less code is also typically simpler.
2. Less bugs – Developers, when working in pairs, can catch each other’s bugs before they ever make it to production. We therefore save time that it would take to fix the bugs that would otherwise go undiscovered.
3. Shared domain knowledge – When “pairing”, each developer is training the other and sharing knowledge and rules around the business. This avoids silos and situations where only one person knows the code.
4. Increased Skill – When “pairing”, design, coding, and testing techniques are transferred between developers. This is often why many development shops pair their senior developers with junior developers; to raise the skill level of the junior developer.

Collective Code Ownership

No one person should be a silo/bottleneck for any area of the code. Any person should be free to make suggestions, fix bugs, or refactor any part of the code. Pair programming (see above) is one tool which seeks to address this.

Conclusion

While the above recommendations may seem like a lot, the above items all really go hand-in-hand. Consider:

• Collective Code Ownership is had through Pair Programming
• Standards are enforced by developers when Pair Programming
• Writing Unit Tests typically leads to Simple Designs
• A commitment to Code Coverage leads to more Unit Tests
• Gathering Metrics leads to better estimates and Release planning

Adopting the above will move us in a positive direction and ensure that all projects coming from our department will be of ever heightening quality. Once the quality bar is set, then we will begin to see the pace pick up; Remember, quality is a prerequisite to speed.

I felt compelled to write after seeing this very same issue come up twice in the last week or so, once for a fellow developer and today for me.

The Problem

We use a DataSet for assistance with testing our data layer (think NDBUnit).  The problem we have is that when you generate the DataSet the XSD created contains all these table adapters that bloat the file, in our app the file bloats to about five times the regular size.  We've found that deleting the table adapters on the file makes the file open up so much faster.  However, every time we make a change to the database schema we have to regenerate the DataSet so that it matches the schema.  As the table count has grown deleting these table adapters by hand has grown wearisome.  All this is merely set up for me over-fixing the problem.

My First (Wrong) Thought

I thought to myself, "hey this is XML I'll just load up and XML document and query out the nodes (TableAdapters) I don't need and remove them from the document and save it back."  While writing a quick bit of code I found writing more code than I needed (at this point I was only at 6 lines).  Despite the file being XML, I don't need to treat it as XML.  Understand that nothing about getting rid of the TableAdapters relies on the "XML-ness" of the file, it's all just text. Reminding myself of that...here's what I came up with...

The Second (Correct) Solution

Simply treat the file as text and remove the piece you need, the only caveat is that I'm dealing with XML and so if I remove a "piece" I have to remove the whole "piece" (where "piece" means XmlNode).  The solution below simply matches TableAdapter nodes and replaces them with empty text.  Simple.

   1: var path = @"C:\dev\sandbox\Website\src\IntegrationTests\TestData\Database.xsd";

   2: var text = File.ReadAllText(path);

   3: File.WriteAllText(path, Regex.Replace(text, "<TableAdapter.*?>.*?</TableAdapter>", "", RegexOptions.Singleline));

The Point

The point is the first solution, while correct, was more complex than it needed to be.  Using a little bit of RegEx to wipe clean certain nodes, I get exactly what I want in three lines of code.  Moral of the story?  Don't overcomplicate what doesn't need to be.

I don't typically link blog and I do my best to write substantive original material, but the following is too good to pass up.  It's how I feel and how I've approach work in the last year or so.  From Ayende's Reducing The Cost Of Change blog post this morning:

That mindset, at least for me, starts from the first line of code. I treat each piece of the project as utterly disposable. Since I don't really care how each individual piece works, I am able to roughly sketch a fair amount of the application very rapidly, and then focus on each of the items in isolation, and replace that with a much better implementation. I think that I stated before that I tend to rewrite most of my application core at least two or three times before I am happy with them.

When you have disposable pieces, it is no big deal if you mess up and need to start over, because the whole project is structured in a way that allows you to do so. Going back to using my current project as an example, the algorithm used for the core part of the system is crap. I thought it up while being on a coffee break, and it is enough to demonstrate what the software is supposed to be doing. I don't really care, because the moment that I do need the real algorithm, I can drop it in (need to change the implementation of a single method).

I can't improve on that, so I won't try.

How cool is Google Chrome (new browser from Google)?  Way cool...like "too cool to run on your machine cool"

Thumbs up though for their error screen, just wish I didn't have to see it

In church last week we were talking about evolution when the term "Irreducible Complexity" came up.  For those who aren't familiar with the concept irreducible complexity is a term coined by Michael Behe to illustrate that complex system could not have evolved and therefore must have been created intelligently.  Behe defines irreducible complexity as:

A single system which is composed of several interacting parts that contribute to the basic function, and where the removal of any one of the parts causes the system to effectively cease functioning. (Darwin's Black Box p39 in the 2006 edition)

In his book Behe uses a mousetrap to illustrate an irreducible complex system. 

"If any one of the components of the mousetrap (the base, hammer, spring, catch, or holding bar) is removed, then the trap does not function. In other words, the simple little mousetrap has no ability to trap a mouse until several separate parts are all assembled. Because the mousetrap is necessarily composed of several parts, it is irreducibly complex." (Behe, 1996).

(This post does not seek to discuss the controversy of evolution vs. creationism vs. intelligent design)

How does this translate to software?  An irreducibly complex software is software that cannot be easily tested.  The "removal of any one of the parts causes the system to effectively cease functioning" really points to dependencies in software.  Do your tests rely on a database being there?  Do you get emails whenever some piece of code runs because as part of the method an email is sent?

Creationist Design

How often have you stepped into some code and have seen a method calling database, sending an email, doing some validation, and then returning some value.  Here's an example I pulled from Jimmy Bogard's post on separation of concerns:

   1: [DataObjectMethod(DataObjectMethodType.Select, false)]

   2: public static List<Customer> GetCustomers(int startRowIndex, int maximumRows)

   3: {

   4:     List<Customer> customers = null;

   5:     string key = "Customers_Customers_" + startRowIndex + "_" + maximumRows;

   6:  

   7:     if (HttpContext.Current.Cache[key] != null)

   8:     {

   9:         customers = (List<Customer>) HttpContext.Current.Cache[key];

  10:     }

  11:     else

  12:     {

  13:         customers =

  14:             (

  15:                 from

  16:                     c in DataGateway.Context.Customers

  17:                 orderby

  18:                     c.CustomerID descending

  19:                 select

  20:                     c

  21:             ).Skip(startRowIndex).Take(maximumRows).ToList();

  22:  

  23:         if ((customers != null) && (customers.Count > 0))

  24:             HttpContext.Current.Cache.Insert(key, customers, null, DateTime.Now.AddDays(1), TimeSpan.Zero);

  25:     }

  26:  

  27:     return customers;

  28: }

The code above will work however it's a bear to test, the code absolutely requires other items (database, HttpContext, ect) to be there in order to work.  I would venture to say that the person who wrote it did not build up the code through small iterations, but rather wrote it all in one fell swoop.

Evolutionary Design

In software, reducible complexity should be a goal.  A reducible complex system allows for pieces to be substituted for others so you can focus on one particular area.  Don't have a database in place, no problem, simply put a placeholder object in for all calls made to the database.  (Yes I'm alluding to mocking).  You can approach creating a reducibly complex system in two ways:

• Create the system as a whole, then reduce it's complexity
• Create the system incrementally

I prefer the former to the latter as I'm working on my TDD skillz.

Conclusion

While the analogies used here are not quite perfect, I do feel they illustrate the point adequately.  As a developer your goal shouldn't be to simply write code.  You should concern yourself with the lifetime of your application/code base.  Irreducibly complex systems, while working, can also have short life spans.  Think about the last time you've ever seen someone fix a broken mousetrap.  All the parts are too interconnected, the mousetrap is simply replaced.  If you're not careful your code may be viewed too difficult and time consuming to fix, and simply replaced.

Here's a conversation I just had with another developer who is struggling to get his team to adopt some agile practices:

developer: if you were starting from scratch, which would you think is more important to setup first? CI or a unit testing process?
me: unit testing
developer: wow
developer:  ok
me: why is that surprising?
developer: i look at the mess i'm in everyday and i'd think getting a good build system in place would be first...
me: I think unit testing provides more value in that it allows you to add features knowing you haven't broken other features
developer: testing above a development process?
me: yes
me: testing provides more customer value

Let me be clear in stating that I think both are great value and a necessity, however the challenge was to choose one, presumably the most important.  I chose unit testing because one of the reasons I enjoy writing software that meets someone's needs.  As a developer one of the most nervous moments is when your code is released into the wild.  Will it work?  Will users they use it how you intended?  As a developer one of the most satisfying experiences is watching a user fire up a program you've written and it works flawlessly.  I think most customers would agree with that as well.  Having code that works is what they want.  Having code that works builds their confidence in you and reassures them that know what you're doing.  Testing provides this for me.  In advance I can test different scenarios and program that in and put my program through it's paces.

Now let me speak a bit about CI.  While I believe that testing is a component of CI, the developer in this instance meant a build server that kicks off automated builds.  While an automated build is nice, it doesn't nearly provide the value that unit testing does.  It's the things your build server does that increases it's value.  One of those things in our build system is running automated tests.  If you remove automated tests from a build server all you have is a dummy machine that compiles code.  That provides some benefit, but minimally.  You can replicate the behavior simply by updating your code often and doing a compile on your own machine.

As an agile developer I seek deliver value to stakeholders.  When viewed through that lens, I think unit testing clearly wins.

What about you?  Would you test before build server?  Or would you choose the build server?  Why?

We're all familiar with the Aesop's fable of the tortoise and the hare.  In the story, the hare, who is in every way is faster than the tortoise, loses a race to the tortoise.  The main principle of the story is that slow and steady wins the race.

In my development I am shooting to be a tortoise, really I am.  Read on and let me explain.

A few weeks ago I got some evil glares when I suggested at our .NET user group meeting that in enterprise systems that you don't have time not to test.  It's a common hurdle for those new to testing to say, "I don't have time to write tests."  Let's face it, we're all busy, that excuse is tired.  As an agile and lean practitioner I seek out ways to improve velocity and reduce waste, not take my already busy schedule and cram in another tool for the sake of another tool.  While writing tests does slow me down, it brings on tortoise like speed, which I would argue is a good thing.  Writing unit tests is one tool that provide me the ability to keep a more consistent velocity over the course of development.  Without tests I can surely write things faster, the problem arises as the codebase grows and each new feature or fix takes increasingly more time. Eventually, even simple requests become arduous to implement.  Slowly you see your velocity come to a crawl.

It's an insidious cycle that I've seen before and am currently in the throes of; an application is built from scratch implementing everything the business requires. The application is enhanced and bolted on to, until you realize that you could move much faster if you could start from scratch.  You make pleas to your boss and explain how much productivity would improve if you could shed the hideous code base.  One day he gives in, you rejoice and you make the leap, start from scratch, breathing a sigh of relief at how easy implementing the features are all the while reminiscing about the old framework and how poorly it was written.  And now that the application is rewritten from scratch the cycle, unless you were aware of it all the while, starts again.

You see, no one sets out to write crap code.  People do the best they can with the knowledge they have.  Code, following the second law of thermodynamics, tends towards chaos over time.  With unit tests in place I can refactor with more confidence and implement new features without the fear of breaking existing code.  If you have the ability to refactor, new code is no longer "bolted on" but rather "grafted in" becoming part of the system.  With a solid framework with tests in place you can much better stop the cycle of rewrites.  Quickly writing applications that degrade is the way of the hare.  Developing purposefully using unit tests causes me to be slow in the short run, but over the life of the application comes out far ahead.  In that way, I strive to be the tortoise.

Chris Sutton tagged me yesterday asking how I got started with programming. So here it goes.

How old were you when you started programming?

I suppose I first started with my TI-86 in physics class making text based adventure games.  After that it was HTML and building a website on geocities (remember them?).

What was your first programming language?

HTML, if you count that, otherwise Pascal.

What was the first real program you wrote?

I wrote a small portion of an application in VB6 for a local paper company while I was an intern in college.

If you knew then what you know know would you have started programming?

Yes, most definitely, and would kick myself for not taking advantage of the abundant resources and time while in college.

If there is one thing you learned along the way that you would tell new developers, what would it be?

First, have passion for your craft.  Second focus less on languages and specific technologies, but instead focus on principles and core fundamentals.

What’s the most fun you’ve ever had … programming?

In college I wrote my own compiler for an honors project and I used to stay up every Thursday night and program in preparation for a Friday morning meeting with my advisor.  About 2am I'd make a run to the local grocery store and buy some Mt. Dew and a box of Nutty Bars.

I'd like to hear from:

• Rhys Campbell
• Chris Missal
• Zac Harlan

Many people use open source tools, whether its NUnit, Nant, Rhino, or log4net in their professional lives.  If you use any of these tools, when was the last time you donated time and/or money to any of the open source tools you use?  That's what I thought. 

I was recently watching the Hibernating Rhinos from Ayende Rahien and I wanted to thank Oren.  Right there on the Hibernating Rhinos page it reads:

I wanted to donate.  Perhaps because the videos provided so much guidance from one of our industries finest.  Perhaps because I've met Oren and generally think he's a good guy.  Regardless, I donated some money.  Not much, but some.  Something to say, "thank you, I appreciate this.

Curious if other donate, I emailed Ayende to see what revenue, if any, his video series has generated.  I wanted to know well the community was supporting a popular training tool.  Here's the stats, lifted a few moments ago.

So how much has Oren received from this video series?  Guess.  Seriously.  $125 since September 2007.  From the stats above there have been 242,610 downloads of the videos. That breaks down to .000515 per download!!!  As a community that's quite pathetic.

From here on I've resolved to donate a dollar any time I download a free library or webcast where a donate link is presented.  Why $1?  In all honesty it is something I can commit to.  I download and use a lot of tools, so I don't want ongoing cost to hinder me.  $1 is a token to say thanks, acknowledging the work that's been put into the product.  I would challenge you to make a similar commitment for the tools you use.  Let's show the author(s) of these tools/libraries that we do appreciate the work they do!

About a month ago Jean-Paul Boodhoo announced a contest that he was sponsoring.  The contest idea centered around the idea of developing passion in others around you.  I have an immense amount of respect for JP having met him at ALT.NET Seattle.  When the contest was announced I thought I'd put in an entry as I enjoy the journey passion for my craft has taken me on with others.  Here is my entry in its entirety:

While I'm not quite sure that my entry will be legal - a bit on that in a second - I would still like to share my story.  As for the legality of my entry, the rules clearly state "Must be working full time as a software professional (not a student)" (emphasis mine).  While I am a full time software professional, I must say that I am, unequivocally, a student.  We all are, whether we realize it or not.  The one truth I keep encountering in my maturation as a developer is a bit of a paradox: the more I learn, the more I realize I don't know.  Therefore I approach software development as a student and view my coworkers as students as well.

When I started at my last place of employment I was humbled early and often by my lack of knowledge in areas I thought I knew well.  Rather than being deterred, it sparked a fire in me, and since then I've never turned back.  Being humble and realizing, for lack of better words, how stupid I was, was quite possibly the best thing for my maturation as a software professional.  That spark has matured into a passion that I can best describe as the feeling of a child on Christmas morning, eagerly shaking his sleeping brothers and sisters telling them that Santa has come.  It's the type of knowledge where you share it not to show how much smarter or better you are, but because you are, at your core, excited at the chance to share it with someone else.

Among things like reading blogs, starting a blog of my own, listening to podcasts, I started to teach more. There are a great many people who believe that the best way to learn is to teach others.  I fall squarely in that camp.  I began by timidly teaching a few of the weekly developer trainings that the company offered.  Soon, I was teaching quite regularly and in 2007, I taught more than anyone else in the company.  I focused many of my talks on areas where I struggled and on things I wanted to learn, realizing that if I struggled learning a concept/language/framework, others probably did as well.  In one training session I created an elaborate hands-on demonstration of how events and delegates work.  Participants were given a card stating what they should do when a specific event occurred.  It started innocently with me turning off the light switch and, at it's height, had people walking all over the room, some making marks on the white board, others moving objects around the room, and still others doing various assigned tasks.  I was told later by someone that, "...it was the best training of events and delegates they ever had seen."  That comment was special to me. 

Why do I think I deserve to win this contest?  Honestly, I don't know that I do.  I'm not an "alpha" type, I haven't produced tons of tutorials or webcasts to help the community, and most of you probably have never heard of me.  However, I believe that if you ask current and former coworkers, they would say that I seek to help and mentor others as well as offer myself up to be mentored.  To me, more than having a large internet following, I desire to impact those around me.  Below are two recent such examples.  The first is an email I received a bit after I left my last place of employment:

Hey Tim,

How are you and howz your new work? Hope you have settled down.

Here same as usual , I got to take your big desk J yeeeeee . Josh A is sitting at your place with my small desk.

Hey listen thanks for introducing Rhino mock , I am getting better at it and I like it ….

Usharani Kachegere

The second example is is from a younger developer, Toran Billups, who emailed me one day out of the blue when he saw that I updated my alumni page on our college website.  Toran emailed me innocently one day asking about my work experience.  We started chatting more and more and I provided whatever guidance I could to him.  I have enjoyed my time mentoring Toran, as it's been a bit more focused with one-on-one time.  I've gotten the chance to see him grow in his skill, and more importantly, his passion.  Below are some of his comments about his experience over the last year and a half in a recent chat:

"I think from the moment I 'emailed you' to ask for some 'mentor like advice' you have shown a true passion for software development/learning/etc."

"your words have pushed me to a level I only dreamed of 11 months ago"

"I'm knee deep in TDD and in part because of your words!"

"I just built a house - otherwise ... i would move just to work with you- honestly"

"it's like something happened after talking to you last year ... I never had anyone challenge me like you did"

"but again - without your 'patience' / 'care for others in the community' -- you could have brushed me off with a simple 'newb' comment instead - you took the time (out of your busy day) to help ask the 'right questions'

If you're reading this and you've found yourself losing passion for your craft, family, or faith, don't sit idly by.  Do something, anything, to get back into it.  Do what whatever it takes to reawaken your passion and foster that passion, you'll be much happier person for it.  I wrote last summer on my blog about passion in a post titled "Passion in Programmers", and I believe what I wrote in that post to be as true today as the day I wrote it.  In it I wrote, "Passion in my mind is a key characteristic of being a great developer.  A passionate developer will never stop learning and enjoys the journey of learning and thus is an asset to any team."

"But you have the source!"

I heard that statement a little over a month ago at the Alt.Net Open Spaces event in Seattle.  It's no secret to those who know the community, that open source technologies are at the very least promoted and in many cases you'll find many open source project committers within the Alt.Net community.  Heck, David Laribee, a founding member if there is such a thing, in a post defined Alt.Net as (emphasis mine):

1. You’re the type of developer who uses what works while keeping an eye out for a better way.
2. You reach outside the mainstream to adopt the best of any community: Open Source, Agile, Java, Ruby, etc.
3. You’re not content with the status quo. Things can always be better expressed, more elegant and simple, more mutable, higher quality, etc.
4. You know tools are great, but they only take you so far. It’s the principles and knowledge that really matter. The best tools are those that embed the knowledge and encourage the principles (e.g. Resharper.)

The quote, and many like it, came in a session titled "Mature Open Source projects versus first generation Microsoft projects".  The discussion centered around why some (many) developers, managers, and executives feel comfortable choosing a brand-new Microsoft product when a far more mature open source alternative exists.  One the fears surrounding the adoption of open source is the lack of surety that open source project will exist in perpetuity.  One needs to look no further than two projects, NVelocity and NDoc, to find historical evidence of an open source project vanishing.  The main counter-point to that argument, and many others, was the quote above, that with open source, you were never truly left high-and-dry, since you had the source.

It's a noble thought, but really, who wants to manage another codebase in addition to their own?  In fact I turn to open source project many times so I don't have to write my own code.  Why re-invent what someone else has already done and guided to maturity?  The idea that I can compile and manage another, possibly large, and probably complex codebase is hardly a comfort to me.  It wasn't until a few weeks ago that I realize that the open source pundits were correct.

I have been working on a project for the last year that has, as of two versions ago, started using Watin to automate the downloading of a file from the internet.  Watin is a testing framework but is used by many to automate business processes, which is what I use it for.  If you haven't checked it out yet, it's beautifully simple.

Watin provides handlers to download a file, however, the code was hanging at the point where it should've cleared the download.  I looked at every documentation page, blog post, and blog comment I could to see if I was missing something.  My usage was correct.  So I dug in a bit further using WinDowse to find the handle of the button that should be clicked.  As it turns out the handle of the Save button in a FileDownload Dialog changed from 4424 to 4427 in IE7, who would've guessed it right?  Well, since I had the source I went in and made the change, and voila, I'm back in business.

It gave me some confidence that if an open source project does cease, I can pick it up and patch it up.  I still don't want to manage multiple codebases from many different source, but in the end the pro open-source guys were right, "You have the source!"

Last year when I built a new machine I purposefully built the machine with lots of power so that I could have multiple different environments and insulate myself from the loads of crap-ware that inevitably ends up on my machine.

Virtual machines allow me to download and try some utility in a sandbox where I know I can return to a previous state.

I opened one of my virtual machines and saw the screen posted on the right.  If this were on my host machine I think I'd need a new pair of underwear.  I don't have the time to rebuild a machine and so screens like the one of the right scare me.  However that is a virtual machine that had the ASP.NET MVC Framework Preview 2 on it.  So, am I going to try and diagnose?  Nope.  Just create another...it's beautiful.

I've just come off a whirlwind few weeks.  The largest change is my departure from Geonetric, a health-care content management system (CMS) software maker, and moving to J & P Cycles, a after-market motorcycle parts dealer.  A week an a half ago I also attended a Get Motivated event here in Cedar Rapids.  I was particularly interested in hearing/seeing Zig Ziglar speak, as I'm a big fan of his books/audio.  Then last weekend I attended the Alt.NET conference in Seattle.  Then this weekend I went to a workshop on investing.

Being around the type of company at these types of events (whether technical, motivational or other) really inspires one to be better.  At the Alt.NET conference I had a chance to sit with a small handful of developers at the TypeMock sponsored dinner.  Sitting among the likes of Roy Osherove, Jeremy Miller, Dru Sellers, Oren Eini, and Steven "Doc" List and realizing that these guys are masters of their areas is really quite inspiring.  Just listening to the talk of IoC containers and mocking frameworks (with two mock framework authors) is something one cannot put a price tag on.

On the plane ride back, it was evident in fellow attendee Chris Sutton that he was inspired the way I was.  I've since spent the evenings cracking open books that have been collecting dust for some time and rereading them (Chris is doing the same since watching his Twitter account).  At the same time I've been working to shut the TV off, not entirely but the mindless time I spend in front of the tube has got to go if I aspire to be on the level with these programmers.

I've spent the better part of this post talking specifically about Alt.NET but Alt.NET really was just one of the events in which I interacted/saw inspiring people.  These past two weeks have been quite a kick in the pants.  I would encourage readers of this post to question themselves about what you're improving yourself on whether it's your coding, your golf game, investing foundations, or some other hobby.  My eyes have really been opened lately to the vast number of winners out there and the vast number of mediocre people.

Don't be mediocre, better yourself, starting today.

The new Resharper seems to favor the "var" keyword and I don't understand why.  Is it some performance benefit?  To me, if you know the type, then write it as such.  Consider the following:

Person p = new Person("Tim", "Barcz");

Resharper doesn't like this and suggests the following:

var p = new Person("Tim", "Barcz");

Why?  Just because you can do something, I don't think you should.  Maybe my brain hasn't shifted back to a var world yet, but the second snippet is less readable than the first.  To me it's a case of Don't Make Me Think.  With "var", I now have to stop and think, even for a second, what type is being returned.

I've thought about writing this post several times over the past two years.  Having had regular expressions come up three times last week, I thought it time to address the lack of programmers out there who understand regular expressions.  The sheer amount of fear surrounding regular expressions and the work that goes into avoiding them is astonishing.

Last year I used to troll around the asp.net forums and quite frequently I would answer the regex questions.  One question was posted which illustrates the problem with regexes among developers.

"...and i also i need to add a validator for the password textbox where the user is required to fill atleast [sic] 6 characters"

I suggested a solution to the problem using a regular expression validator. Making sure there are at least 6 characters, is a simple regex (example: \w{6,}), and yet my solution was met with skepticism.  The following was said, in the event a change was requested,

"Putting a new version of a web site can take a surprising amount of time than can go into man-weeks". 

Man-weeks?!?!?  To change a regular expression?!?!?  I see two problems, first the original developer who didn't know that regex would easily solve their problem.  The second problem is the other developer who doesn't know regex advocating his way as "the way", in effect, spreading his ignorance.  The first developer is easily forgiven, the second is not.

It's been said programmers can't program when faced with a simple FizzBuzz test, Imran states:

"Want to know something scary? - the majority of comp sci graduates can’t. I’ve also seen self-proclaimed senior programmers take more than 10-15 minutes to write a solution."

I'll pile on.  You want to know something scary?  The majority of professional programmers can't write regular expressions, even simple ones.  I'm not the first to say this.  Last year, at the ALT.NET conference, Scott Guthrie made the following statement when talking about routes in the new MVC framework:

"It's pluggable, so you can use Regexes...<some incoherent stuff>...if you wanna use regexes you can.  What we found is, regexes are super powerful, but only about 10% of people actually understand 'em."

Are regular expressions easy to understand? Well, let me ask you, was HTML easy when you started?  Were you born understanding the following HTML?

<fieldset class="CheckRadio">
    <div id="OngoingEventContainer">
        <input type="checkbox" id="OngoingEvent" name="OngoingEvent" value="1" />
        <label for="OngoingEvent">
            This is an ongoing event (no dates and times)
        </label>
    </div>
</fieldset>

If you understand the above, you didn't always.  My guess is that at some point you buckled down and learned HTML because you're job requires it.  Well, if you're a programmer, web or windows, you need to know regular expressions, your job requires it, it's that simple. 

Regular expressions have been around so long that they're deeply ingrained in many of the tools we use.  Christopher Bennage illustrates how regular expressions solved a recent problems in Visual Studio.  In a recent post he posts:

"Then I realized that I was missing the simple solution. Ctrl+F and a regular expression!"

I don't know that many people would be able to come to the conclusion that Christoper did.  It's my belief that regular expressions are fundamental, yet the average developer doesn't treat them as such.  They're ultimately doing themselves a disservice.

Regular Expressions are a tool that should be in every programmers bag.  If you don't understand regular expressions and do a google search every time you need a regular expression, shame on you!  It's time to bite the bullet and learn regular expressions.

Over the past year or two I've really tried to improve coding abilities by thinking on objects.  By talking about, and programming, real-world objects you can reduce the impedance with clients when discussing the problem.  I'm not alone, Karl Seguin comments about domain objects in a recent blog series about the foundations of programming:

Anyone who's gone through the above knows that learning a new business is the most complicated part of any programming job. For that reason, there are real benefits to making our code resemble, as much as possible, the domain. Essentially what I'm talking about is communication. If your users are talking about Strategic Outcomes, which a month ago meant nothing to you, and your code talks about StrategicOutcome then some of the ambiguity and much of the potential misinterpretation is cleaned up. Many people, myself included, believe that a good place to start is with key noun-words that your business experts and users use.

While looking at LINQ over the last few days I've become disappointed to find out that many-to-many relationships aren't supported.  Sure you can hack you're way around it, but anyone can hack their way around anything.  If you question whether or not it's a hack, consider all the language features implemented to make LINQ work and still many-to-many isn't supported.

LINQ requires an intermediate class in order to do a join.  In the real world there is no such this as OrderProductJoin or TopicCategoryJoin, so why do I have to have that object in code?  That smells funny.

I feel the pain of Hamilton Verissimo, the founder of CastleProject, when he comments about FUD surrounding Castle.  ActiveRecord, as an ORM, has respected the domain object for quite some time while providing Many-to-Many support.  LINQ however requires an DBML file, the usage of DataContext everywhere, and doesn't support many-to-many joins.

David Hayden, respected blogger and Microsoft MVP defends LINQ to SQL but adds:

DLinq is perfect for those developers who focus on small applications and Microsoft-related technologies.

After having used both NHibernate/ActiveRecord and LINQ, the clear winner right now in my mind is NHibernate/ActiveRecord, despite LINQ having the backing of Microsoft.  ActiveRecord respects the domain model allowing you to talk about objects with a shallower learning that LINQ.

A friend of mine visiting from Dallas last night was telling me about GrandCentral, a service that allows you register a phone number and have any calls to that number forwarded to your real number.  My friend has a season tickets to the Dallas Mavericks and sells his tickets.  He sells the tickets through craigslist and doesn't want to reveal his real phone number.  GrandCentral work much like I the spam management tools I wrote about recently.

I just went to sign up for GrandCentral and see that the service is available in Iowa:

When trying to sign up however using the area code I am told that no numbers are available:

I reason to myself that it's not a big deal since Iowa has a few area codes, so I'll see what numbers are available by selecting the state from the provided drop down.  Can you spot the problem:

Iowa is not in the list.  So how does an Iowan sign up for GrandCentral?

Nope, this isn't a slam on Microsoft or a post about Big Brother.  Rather it's a praise.  I have been impressed by Microsoft over the past few months and the attention they pay to the "blogosphere".  I don't know if it is a Microsoft policy or if it is product developers keeping an eye on what is being said about their product, but they are watching.  Two of my posts about Microsoft products have generated an email conversation with someone from Microsoft who works on the product.  A few weeks ago I posted about how Windows Live Writer was deleting my DasBlog posts which received the following comment from Charles Teague:

"Hey Tim,
Sorry that this is happening. Can you clarify what you mean about the post being gone? I can see the Linux post
just fine in both IE and Firefox.
Best,
Charles (MSFT)"

Looking into Charles' about page reveals that he works for Microsoft working for the Windows Live Writer team.  I'm impressed that they're watching, whether it is policy or not.  I think it shows quite a bit about the people that work for Microsoft.  All too often there are anti-Microsoft rants and ravings and not enough praise.  I am glad to see that they're paying attention to adopters of their software and that in many ways their seeking out their customer base and watching the reactions instead of having me go and search for a resolution.

So thank you to you Charles for being aware of what's going on with your product and being so willing to help.  If any of you Microsoft employees come upon this post, I'm curious if this is a corporate policy or a personal one?

Scott Hanselmen posted this morning about aideRSS.  I decided to run aideRSS over my blog to see what would the results would be.  Apparently I have only one "Great Post" which made me chuckle:

Apparently my test post from yesterday was "Great".  I wonder if that's an indictment on all my other posts or something internally goofy with aideRSS's calculations.  I was impressed that AideRSS correctly labeled my Vista Printer Installed - Dell All-In-One 922 Now Printing and Nant Setup for Visual Studio 2008 and .net 3.5 as having the high scores in the PostRank column.  These two posts are clearly the most trafficked when I look at site statistics.

I have to say I'm impressed with what how it works:

"...in a nutshell you enter the URL of the feed that you would like to have filtered and we do some math and checking around the web to learn about this feed, its statistics, and people’s reaction to it. We then assign PostRank™ scores to all articles in the feed and provide you with a variety of tools to sort and parse these items of interest into manageable lots for you to scan and digest at your leisure."

Scott's explanation may be more meaty:

"Well, since it can't really measure quality it infers it indirectly by creating a metric based on the number of del.icio.us bookmarks, diggs, Blogger references, Technorati references, Google BlogSearch reference, IceRocket references and a few others."

As I'm blogging more I intend to check in on AideRSS every so often as I think this is just another way to see which posts are worthwhile and which aren't.  However, I will say that it briefly crossed my mind to retire from blogging seeing as how 100% of my posts are "Good", easily beating two of my favorite bloggers Scott Hanselman (61%) and Jeff Atwood (75%).

Recently I was at lunch who two fellow developers.  The discussion focused on various technologies and the future of technology as it seemingly always does when a group of nerds gather.  The discussion somehow meandered it's way to Linux, where I admitted that I didn't understand or get it and ask both developers to explain Linux to me.  Both were happy to talk about Linux from the different distributions to why Linux is so neat.  Still a few weeks later and after it was passionately explained to me, I still don't get it.

For home users Linux must meet or exceed current Windows functionality.  Windows has long been the operating system of "choice" in the home.  The (un)fortunate side effect is that you can buy any peripheral or software for your computer and most likely it will work.  The same can't be said of Linux.  I don't see Linux breaking into the home market for quite some time, if ever.  Here's an article from Joe Brockmeier on the subject, he states:

"Linux isn't a direct Windows replacement, and users seeking a drop-in replacement for Windows often come away disappointed. Not because Linux is unusable as a desktop, but because it just isn't Windows. A lot of people, though, don't really need Windows. They just need a system that handles basic functions and doesn't cost an arm and a leg."

Joe seems to get it.  Linux may be better in many ways but it's worse in one, it's not Windows.  Users are used to Windows.  If Linux is too different, people won't switch, if it's too similar, people won't justify the move for something so similar.  Further there's the stigma that only the über-technical work in and with Linux.  The "basic functions" that Joe speaks of is what Apple has in it's iLife package.  Apple has been running the "I'm a Mac, I'm a PC" (getamac) commercials for awhile now, hammering home the "we just work the way you do" mantra.

According to Wikipedia, Linux has 1% desktop market share.  Every now and then a new Linux distribution will pop up purporting to be the answer, first it was Red Hat, then Suse, and now Ubuntu.  If after 15 years (Linux dropped in 1992) there is only 1% adoption, I wonder if a meaningful market share will ever be realized, regardless of the distribution Linux is packaged in.  There are articles that say that 2008 is the Year of the Linux Desktop, which is sharply but in check when Joe reminds us:

"Yes, yes. I know — we've all heard this before. If I recall correctly, 2001 through 2007 have also been" the year of the Linux desktop,"

Other articles are more accurate when they say Linux Desktop is More Popular Than Ever.  But while that may be true, it's not hard to have great growth when you're small.  Similar to the day the number of subscribers to my blog doubled.  Sounds pretty impressive until you find out that there were only two, which doubled to four.

Linux has support which is evidenced by it's strong, ardent community. That community however is mostly comprised of developers and the techno elite.  Until that community starts reaching out to the people that "need a system that handles basic function and doesn't cost an arm and a leg" Linux will remain a enthusiast OS.

Has this ever happened to you?  You been asked to put together something quickly to demonstrate some functionality and it somehow has ended up in production?  I have, and for that reason, I believe there is no such thing as a prototype.

When I'm asked to see if something is possible, I, being a good pragmatic programmer, run off to implement a quick prototype.  Author David Thomas explains the idea of a prototype:

Prototypes by their nature are not designed to be long lasting code. Prototypes are designed to be thrown away. They're one-offs. It is inappropriate to over-engineer a prototype. A prototype is like a town in a western movie. It's all facade. There's nothing behind it. You cannot move in and raise a family in one of those houses.

If you've been around for any period of time in development, you've probably written something yourself, or at the very least seen something that has weaseled it's way to production that was never meant for production.

Believe it or not, the site below is in production. 

Currently the site performs limited, but somewhat crucial, functionality.  The administrative home page clearly leaves something to be desired.  However, I happen to know the developer who worked on this site and he explains that it was never intended to go live in it's current state.  Business rules/needs trump gold-plating, it's a concept that the business-brain part of me understand, but the developer/craftman.

Talking with another developer today, he recalled a system he put together as a consultant to demonstrate some piece of functionality.  Some time later another developer was putting a pretty UI on it, since it had made it's way to production.

I think somewhere deep inside of developers, we know that when asked to prototype something it may someday end up in production, whether we build it for production or not.  Developers are prideful, artistic creatures.  Our code is our craft!  We're also learnable.  I now tend to make prototype code something I would be proud of if I were to show it someone else.

Ultimately I think prototypes are a great tool, but there's a danger in the prototype going live, which from the definition above isn't sustainable.  Ultimately that's why I'm jaded a bit and say that a prototype is an imaginary thing, only production and soon to be production.

• Sarah - Sarah is a wonderful wife.  People from the outside probably don't *get* us but that's ok, we get each other and it works great!  Together we make a great team and I consider myself lucky for having it that way.
  
• Lincoln's health - while I'm thankful for Lincoln, I'm more thankful at this point that he's healthy and developing well.  There's nothing like getting up in the morning and seeing him smile up at you from his crib.
• Hope and Vision - I'm going somewhere, I've got goals, however I was reminded again how easily I take those for granted while driving through a "not so nice neighborhood".  I thought to myself that day that if I lived in that neighborhood how easily it would be to lose my hopes and dreams.
• Health - Despite a raging Mt. Dew addiction, I remain in fairly good health.  Sure I'm heavier than when I was in my early twenties, but that's to be expected.  I still get to run on a semi-regular basis and I enjoy it.
• Work - I strongly feel that it's in a man's bones to work.  What makes it easier is that I enjoy my work.  I've worked at enough places that I don't care for to realize the last few places I've worked are wonderful.  I enjoy getting up and working at Geonetric.  Sure there are bad days, but usually there only bad because I care.  In fact I'm not the only one who likes Geonetric, it was recently voted best place to work in our area.
• Faith - I'm thankful for a higher power.  Despite my best attempts, I find that I'm rarely the example I should be.

I'm on the cusp of purchasing parts for a new computer.  My mouse is hovering on the "Checkout" button on newegg.com.  As I'm going over the parts of my computer I'm agonizing over the choices I've made.  Most of the parts are inspired from lists that were put out by Scott Hanselman and his ultimate developer rig post as well as Jeff Atwood and his "Now It's Your Turn" post.

The question right now is Quad Core vs. Dual Core.  It's been questioned how much is really gained by going from two to four cores.  Graphs and benchmarks show that there isn't much to be gained right now with going to a Quad core.  Sure there isn't a difference now, but what about the future.  Multi-core systems are the norm now, but a few years ago that wasn't the case.  As programs start building for multi-core desktops I would imagine that more cores would be better.  So I'm curious, though a quad core machine today offers a neglible benefit, what about the future, two or even four years from now?

What do you think?

Tim

"Reason 4: We're helping save lives!

We are connecting patients, physicians, and communities using Internet technology. We're helping an industry that has traditionally done a miserable job of using Internet technology successfully. One of our clients launched a Weblog of a morbidly obese patient undergoing bariatric surgery that helped 40 patients find this life-saving surgery. There's something very fulfilling and rewarding about doing things that help save lives!"

The other day I ran a credit report and a coworker asked if I could blog about how I did that.  I didn't want to inadvertently forget to post a requested topic since I've been gardening a lot.

Here's the skinny on credit reports.  Back in 2003, Congress passed the Fair and Accurate Credit Transactions Act (FACT Act). There is a provision in there allowing consumers a free credit report from each of the three credit reporting agencies (Equifax, TransUnion, and Experian) once a year.

The method I use to get my credit report is to use AnnualCreditReport.com.  You simply go to their home page, select your state in the "Start Here" area and you're off.  You will have to verify a few pieces of information but once you've done that you can select which site(s) you would like to recieve your report from. 

Since you are allotted one report per 12 month period from each agency, I typically run on a 4 month schedule pulling a single report at a time.  Here's how I do it.

• October 07 - Experian
• November 07
• December 07
• January 08
• February 08 - Equifax
• March 08
• April 08
• May 08
• June 08 - TransUnion
• July 08
• August 08
• September 08
• October 08 - Experian
• November 08
• December 08
• January 09
• February 09 - Equifax
• March 09
• April 09
• May 09
• June 09 - TransUnion
• July 09
• August 09
• September 09

That way without paying a dime I get a credit report once every four months.

If you haven't ran a report in awhile, do it today, it's free and you've got nothing to lose.

I'm exploring the new HealthVault beta from Microsoft.  Every document on the MSDN site regarding HealthVault is downloadable as an .xps file.  In my attempt to print a document, I've read numerous blogs posts this morning about how XPS (Xml Paper Specification) is supposed to be superior to PDF but I would strongly disagree.  Here's my experience trying to simply print a .xps document (which hopefully you won't experience):

• Click on download link (using Firefox), I'm then asked if I'd like to open the .xps document with "XPS Viewer" to which I say yes, only to find that another tab is opened in FireFox asking me the question again.  Another affirmative answer opens another blank tab asking the question again, you can see where this is going.
• I'm smart, so I'll save the .xps document to my desktop and open in IE.  Sure enough, the file opens and I can read it fine.  I go to print however and I only have 3 printers to choose from, none of which are my actual printers (you know the things that spit out paper and have cryptic messages like "PC Load Letter" .  Normally I have nine printers, but now I have three, so I start seeing what I can do with these:
  • Microsoft Office Document Image Writer - This "printer" is there but selecting it disables the print button.
  • Microsoft XPS Document Writer - This "printer" asks me where I want to save my file...as another .xps document.
  • PrimoPDF - When choosing to "print" to a pdf file I encounter an error.
• Now I'm at the point where I'm googling for a solution.  I can't find squat, maybe this problem is limited to me.  I do find a pack to download the viewer on Microsoft's site, so I try to download a viewer, hoping that the problems I have may be fixed in a new version.  The installation comes in the .NET 3.0 redistributable, and low and behold it fails to install, saying I already have the .NET 3.0 redist.
• So I find another option on the Microsoft XPS page for the "Microsoft XPS Essentials Pack".  Mind you there's a nice note telling me the option explored in the previous step is "recommended for your system configuration."  I download and install the "Essentials" pack with no problems.
• Now I open the .xps file in the standalone xps viewer and am please to see that when I go to print that all of my printers are there.  So I attempt to print to the default printer and everything seemingly works...until I see that only 11 pages print of the 58 pages.  I print to a different printer, this time 19 pages.  Better...but still wildly deficient.  Next I try printing to pdf, I open the PDF and all 58 pages are there.  I print from my PDF reader and all 58 pages come out of the printer.

That's it...simple.  What I don't get is why people are so afraid to embrace new technology?

So to summarize, here is how to print a .xps file:

1. Download the "Microsoft XPS Essentials Pack".
1. Make sure you have the .net 3.0 redistributable.
1. You first need the .net 2.0 and .net 1.1 before you can install the 3.0
2. Change the default program to handle .xps documents.
3. Print your file, selecting the "PrimoPDF" printer.
   1. Install PrimoPDF if not installed.
4. Now open the result PDF in your reader of choice.
5. Print your file, selecting the hardware printer of your chioce.

There it is, easy as 1...1a...1aI..2...3...3a....4....5

I've recently finished reading Steve Krug's Don't Make Me Think which was highly recommended by both Jeff Atwood and David Sturtz, Geonetric's information architect.  One of the points the book makes is that the users of your website nowadays have been so conditioned by Google that they expect to see a search box. My contention is that adding "search" to your website is no trivial matter.

There seem to be few categories your site can fall into, here are three that I'm familiar with:

Scenario 1:

My father has a website, with a number of pages of static content.  The pages are .aspx pages only to utilize features of .NET like MasterPages and/or themes.  The content is static.  To implement a search I need to somehow index the content, which should be easy, in theory since the content is static.

Scenario 2:

I've built a small CMS system for myself, to manage pages and content.  The pages are dynamic in that when you request a page, no page exists on disk and is loaded from a database.

Scenario 3:

A large CMS with multiple different "objects".  You may at various points want to search for specific "objects" or search across all "objects".  I'm thinking back to my last job where we had a large site to manage baseball tournaments.  There were three primary "objects", players, teams, tournaments.  There was a general search that had to search everything and individual searches for each object that would only return those objects.  In other words the site wide search for "Blue Devils" would return both the "Cleveland Blue Devils" team as well as the "Duke Blue Devils Classic" tournament.  The same search in the team and tournament section would only return the team and the tournament, respectively.

Options:

• I could use Google to search my site.  You've seen the "search this site" boxes on websites.
  • Pros
    • Google indexes well
    • Easy?
  • Cons
    • lose the "look" of your site since you're using google for the search results page.
    • Can't index "objects".  Google can index only public facing web pages/documents.  Therefore (using Scenario 3) a tournament could only be found if the name appear prominently somewhere where Google will find it.  In other words you're relying on Google, a lot.
    • Cannot limit Google to certain "objects".  I can't say, "search only pages that are about Teams", where I could do that quite easily implementing my own search
• Implement my own search
  • Pro
    • The algorithm is my own and I can change it if I'd like.
    • Keep "look" of site by never leaving site.
  • Cons
    • Much more work.  Writing my own SQL to search and aggregate the results.  Do I full-text index on tables?  Do I use a third party solution?

It's a very tricky proposition.  Krug says that users will look for a search box, so that means you should put one there right?  If you put a search box on your site that doesn't produce reasonably good results then the user will lose faith in your website and may leave.  If you don't provide a way to search your pages/data, of which there may be quite a bit, then the user may struggle to find what they're looking for and leave.  The only option you seemingly have is too implement search and implement it well.

• HTML
• Javascript
• CSS
• Presentational Logic
  
• Business Logic
• Data Acess Logic
• Data Access

Jay Kimble posted recently about why live.com search sucks. In the post Jay talks about his troubles find the download page for a particular Microsoft product using Microsoft's live.com search engine, ultimately resorting to using Google to get his answer after live.com failed.  I generally enjoyed and agreed with the post, however I lost Jay on his final comment:

I'm not one to bite the hand that (sort of) feeds me, but come on!!??  The best search engine for MS' properties should be an MS Search Engine!!

In principal I agree, but I wholeheartedly disagree that the MS engine should be best for MS properties simply because they are MS properties.  The Microsoft engine should be the best at finding MS Properties because it's the best engine.  PERIOD.  As Jay pointed out this simply wasn't the case.

Google is dominant because of the quality of the result the engine provides.  If Microsoft operated as Jay suggests, my search for "Blue Shoes" could possibly return "Indigo" results at the top or a search for "Whales" returning a link to the latest download of Orcas, clearly not what I want in either case.  If live.com is to be the best resource for searching for MS properties it should solely be because of the quality of the backing algorithm and not some artificial elevation because it's MS owned as Jay suggests.

The Model View Controller pattern (MVC) seems to be the pattern du jour in many development shops.  That is until of course, some literate nerd reminds everyone, that there is "No Silver Bullet."  The recent rush to Ruby on Rails, which implement this pattern out of the box, has only served to add to the number of people singing the praise of MVC.  Microsoft marketing fed programmers seemed to be quick to retort that the WebForm in Asp.NET is in fact an MVC implementation.  I can't speak for others, but "the codebehind is the controller" always felt a bit like kissing your sister.

The other day I started playing with MonoRail, Castle's MVC implementation for the .NET framework.

"MonoRail differs from the standard WebForms way of development as it enforces separation of concerns; controllers just handle application flow, models represent the data, and the view is just concerned about presentation logic. Consequently, you write less code and end up with a more maintainable application."

My first reaction after overcoming the newness and understanding the project/solution layout was that this felt like how it should be.  I was programming a class and that class held nothing more than data about the object.  My controller for that "model" was shuffling things around and making the decision about what to do and when.

There are obviously some things you give up when going to MonoRail but I hope to assuage your fears and mine by digging in a little further.  Here are the items I have on my notepad to learn:

• Are base class library tools (TextBox, CheckBoxList, ect) as well as third party tools (ie. Component Art or Telerik) no longer available?  If they're no longer available are the counterpart offerings as good as what is offered using WebForms?
• Ajax?  Seemingly ASP.NET Ajax is out if you go with MonoRail, so what to use instead?  Has MonoRail adopted one of the javascript libraries as it's main provider for javascripting/ajax?  If so how does it compare in ease of use when compared to ASP.NET Ajax?
• Af first glance, there also no longer seems to be ways to use server controls or user controls?  Is this statement accurrate?  If so what is the proposed method of getting the same functionality.

The MonoRail/Castle team has done an incredible job in my mind at making this a viable option instead of WebForms.   I still have a lot of reservations about the end-to-end usage, but I've let down my guard immensely after getting my feet wet.  Judging from the user base out there by viewing blog posts and/or forums about MonoRail there's enough of a following that I'm fairly certain the issues above are solved.  If they are in fact solved, then I have great confidence that they'll be just as easy and "right" to use as MonoRail, which will make MonoRail hard to ignore for future projects.

Occasionally I interview prospective employees at the company I work for.  In the course of the interview I of course look for technical competency, but I also look for passion.  Passion in my mind is the opposite of boredom.  I think 9 times out of 10 I'd take a passionate programmer instead of the bored all-star.  Why?  I think passion for the technology you're working with will ultimately be visible in the product you're developing.  Passion can manifest itself in different ways, so don't look for it always in the same place.  Geonetric in many ways has done an excellent job in hiring passionate employees.  I want to give you two recent examples, but some of my co-workers read this so I'll keep the following as minimal as possible. 

• We have one developer who was in the break/lunch room with me and we got to talking about a problem.  The discussion got to the point where we needed to go look at a computer screen, the discussion went something like this:

Me: Yada Yada Yada....I'll show you later after you eat.

Developer: Let's go look now.

Me: Now?

Developer: Yes, learn first.

"Learn first."  That's passion.

• Another developer, fresh out of college, has jumped right in to the project to the point where I don't look at him at all like a fresh college grad anymore.  His passion is a project on the side where he's seeing if he can better deliver web content using XSLT and XML rather than delivering (x)html (sorry Scott if I've butchered the goal).  Is it relevant to what we do daily at work? Maybe.  Maybe not.  The point is that he is passionate about XSLT/XML and jiggering with the technology to bend it to do what he wants.  That's the kind of guy I want on my team.

Passion in my mind is a key characteristic of being a great developer.  A passionate developer is will never stop learning and enjoys the journey of learning and thus is an asset to any team.

An analogy: A person does not pack the same for a overnight trip the same things as they would for a month long trip.  The month long trip requires not only more luggage but also has to take into account things that wouldn't need to be accounted for on an overnight trip.  In other words, you have to pack adequately for the trip you are going on.  The luggage you'd take on a month long trip is too much for an overnight and the same is true for a single overnight bag taken on a month long trip.

In software terms I'm finding myself to be like the guy who too has taken many weekend or short vacations packing only a single pair of underwear and a toothbrush and thinking the same will be adequate for a weeklong cruise to Alaska.  It's not.  What works in a smaller environment and brings success there does not inherently bring success on a larger scale.  In keeping with the analogy, I can't say to the Maître de on the cruise, "My bathing suit is surely adequate for this formal dinner, I've worn this bathing suit hundreds of time before."  The analogy is silly, but the point is that what works in one situation doesn't work elsewhere.  Where a bathing suit is adequate for a weekend camping trip it's not for a cruise.  On that cruise there are expectation of other passengers and the dining room that you will dress appropriately.

In terms of software that means planning better, capturing requirements better, understanding the business behind the decisions, keeping fellow developers excited and passionate about what they're working on, dealing with interpersonal communication better, and making sure that everyone is on the same page and that we're all working toward a common unified target.  As we grow, I need to perform better in these areas.  It's not something I can put off and figure out later.  If I/we don't plan properly and "pack correctly" there may not be a later.

So wherever you are and whatever software project you may be working on ask yourself what the goal or aim of that software is and if you've packed properly for it.  Because if you haven't, you may not get a seat at the table.

• the first 2.5% of the adopters are the "innovators"

• the next 13.5% of the adopters are the "early adopters"

• the next 34% of the adopters are the "early majority"

• the next 34% of the adopters are the "late majority"

• the last 16% of the adopters are the "laggards"