The other day I read a thread on some blog (sorry, I don't remember where it was) on the topic of counting lines of code to measure programmer productivity.  Fortunately, the author of this post understood just how useless this metric is.  I mean, seriously, it's just dumb.  I understand that certain organizations struggle to find a way to measure productivity but counting lines of code doesn't cut it.

There are several reasons "why" counting lines of code doesn't provide any value, so for those of you who believe you still need "something" to measure productivity consider this:

• The number of lines of code can be largely a matter of choice for the programmer since syntax typically gives us great flexibility in how we write almost anything.  For example, in .NET 3.5 I can use automatic properties and create a property on a single line, but if you're counting my lines of code I'm much more likely to skip this feature and spend a little more time to write it all out and add another ten or so lines to my code.  Here's the difference:

public string Text { get; set; }

or

private string _text;

public string Text
{
    get
    {
        return _text;
    }
    set
    {
        _text = value;
    }
}

As you can see, I added an additional ten lines of code in the second property without providing any value.  In truth, I was much less productive in the second property, but by using lines of code as a productivity metric it would appear that I'm much more productive (Yay me, I beat the system!).  Hell, I might even throw in some unnecessary validation code just to add a few lines.

• Developers would be much less inclined to refactor their duplicated code into a single, reusable method.  Why would I reduce the lines of code when I know you're counting the lines I write?  This means that now I have duplicated code which, in turn, means that any updates will have to be made in both locations.  If a bug is found in one location and I forget to fix it in the second.... you get the picture.
• Most programming languages disregard white space.  This means that I could now write that property like this:

public string Text
        {    
            get
            {
                return
                    _text;    
            }
            set
            {
                _text
                    =
                    value; 
            }
        }

I could probably go on and on but the truth is that it's not hard to understand why lines of code as a metric just doesn't make any sense.  If you're struggling for a way to measure programmer productivity I would suggest a milestone driven approach instead.  Can the programmer deliver something that works within a specified time frame?  Does it meet the requirements that were set out for it?  Whatever the case may be, counting lines of code should be eliminated altogether.  It simply doesn't provide any real metric.

Have you ever worked on a big project that went well beyond it's planned timeline or blasted through it's allotted budget?  What went wrong?  I have my own personal experience with a recently failed project that caused me to ask some hard questions.  Many of them are still unanswered but I have my theories.  I think we went through several cycles of a variety of failure points.  The most critical failure, I believe, was that the people with "the vision" wanted the software built based on an "I know what the client wants" premise, rather than actually discussing the requirements with the client.  Kind of a "Build it and they will come" mentality, if you will.  There were many problems along the way, though, that I'd like to cover so that maybe it can help someone else down the road.

• Lack of understanding by those in charge of completing the project: 
  • Stakeholders not really knowing the market, even though they may believe they do, and designing a product that nobody really wants or needs.  Not understanding the business user and not including or including incorrectly the functionality that is really needed.
  • Not understanding the technology limitations (this was a big one for us on several levels).
  • Underestimating the impact of change.  Every time we neared some milestone some management-level individual would think up some feature that the product absolutely must have by this timeline, "otherwise it won't be useful to anyone!".  Scope creep is a killer, people. 
  • The individual or entity asking for a change has no idea what they are really asking for.  In my experience this one happens more than you would think.
• Ineffective communication:
  • Stakeholders basically throw the idea over the wall and wait for the results.  This, my friend, is the road to nowhere.  Want your team to flounder for a couple of months?  This is the perfect approach, trust me.
  • Not providing sufficient documentation.  I can see where this works sometimes with very small teams but I'm guessing this would only work if all team members posses an intimate knowledge of the space they are addressing.  If the hired engineering team does not posses the same intimate knowledge of the industry as the stakeholders then well-documented requirements are a must.  An engineer that doesn't understand the market and has no real requirements is doomed.
• Unrealistic expectations from the beginning
  • Setting timelines and project costing arbitrarily based on when they want it done rather than based on what is involved or the amount of work needed to get it done.  My company currently lives by the get it done by a certain date mentality, which really sucks (especially sucks because this mentality comes from the very top).  They often provide less than half the time and budget needed and they simply will not be bothered by the reasons why it is impossible.  This little problem reaches epic failure when the stakeholders set timelines before they've even defined the project.
  • Not making adjustments to expectations as the project progresses and requirements evolve.
  • Planning for time (see above) rather than planning for effort.
  • Not staffing appropriately. Make sure you have the right skill sets for the right tasks. Not the right priced employee. 
  • Not equipping staff with the tools they need.  We did not even have the equipment specified as the minimum operating requirements (an arbitrary set of requirements, mind you) until well after we had passed our release deadline.
• Change Control
  • Scope creep.  This often stems from a project that has no true definition and/or a mentality where managers pander to every whim of the end user, rather than filtering out those requests that don't make much sense.
  • Not understanding that even small changes take time, add cost, and entail a certain amount of risk.

I'm sure I've missed several points but the picture should still be fairly clear.  This is really just a reflection of my own recent experiences and does not reflect the fact that the company I work for is definitely trying to improve their processes to avoid repeat failures.  They've had many successful projects in the past but they were often relatively small projects and one or two people, that had intimate industry knowledge, doing all the work.  Now that we have a larger team of people involved and projects on a much larger scale we absolutely must implement measurable and enforceable process, plan,  and document requirements.

I feel it was a general lack of understanding of the marketplace, of the technologies, of the capabilities of those involved, of the impact of change, etc. that led to the many levels of failures we experienced.  This project completed but it was 1.5 years past due.

I think it's also important to stress that if you're going to outsource a project you make damned sure that the company you're outsourcing to has the resources and is completely qualified to complete the project.  I can't even begin to describe how insanely difficult it was to work with the team we had outsourced our project to initially.

Good luck!

I first tried Maxthon about 4 months ago and was impressed but still didn't use it much.  Lately, though, I've started using it as my main browser.  I've been experiencing some slowdowns on my connection over the past few days, due to some work the cable company is doing, that have caused many slower sites to timeout on both IE and FireFox but in Maxthon they come up fine and fairly quickly.  Also, while I haven't done any benchmarks to compare with either IE or FireFox, I can honestly say that Maxthon feels much, much faster in most cases.  They have a bunch of plugins (I haven't tried any of these), theme customization, screen capture, file sniffer, ad hunter, filter packs, etc. 

 Just to be clear - I have no affiliation with Maxthon.  I'm just a fan of the browser so I have no problem promoting it, that's it. 

Click the image below to check it out

Scott Guthrie announced today that they've released the Preview 3 build of the ASP.NET MVC framework.  This new build includes features not included in last month's build including Visual Studio tool integration and documentation plus some enhancements/refinements.

Read the entire article

Download an integrated ASP.NET MVC Preview setup package here.

Download the ASP.NET MVC Preview 3 framework source code and framework unit tests here.

Most people concerned about SEO (Search Engine Optimization) know that search engines use the links on your pages to travel the depths of your site for content.  So how does a LinkButton fit into this strategy?  Take a look:

<asp:LinkButton ID="lbtnAbout" runat="server" PostBackUrl="~/About.aspx">About</asp:LinkButton> 

This tag renders like this:

<a id="lbtnAbout" href="javascript:WebForm_DoPostBackWithOptions(new WebForm_PostBackOptions(&quot;lbtnAbout&quot;, &quot;&quot;, false, &quot;&quot;, &quot;About.aspx&quot;, false, true))">About</a> 

Notice that the link is actually a JavaScript call.  At most, the search engine will extract the title of the hyperlink and include it as part of the body, but it won't touch the javascript.  What does this mean?  It means that the link is essentially invisible to search engines.  When thinking in terms of SEO this is BAD.

I won't argue that there won't ever be uses for LinkButtons (like when you need to execute server-side code on the postback), but if you're optimizing for SEO then it may make sense to just use a regular hyperlink, when possible.

"Janko at Warp Speed" has a great article that demonstrates how to create an ASP.NET user control that supports different message types and how to style them using CSS.  It also explains how to style ValidationSummary similarly.  It's a very nice CSS example.

Read the entire post 

Somehow I missed this announcement a few days back, but here it is anyway:

The sixth release of the enterprise library has been released and it includes all the blocks you're already familiar with updated for Visual Studio 2008, plus the new Unity Application Block for dependency injection.

What’s New in v4.0?

This release of Enterprise Library includes the following:

• Integration with the Unity Application Block
• Windows Management Instrumentation (WMI) 2.0 support and improved instrumentation
• Performance improvements (particularly, in the Logging Application Block)
• Pluggable Cache Managers
• Visual Studio 2008 support
• Bug fixes

Note: existing public APIs (v3.1) are still supported.

The Application Block Software Factory and the Strong Naming Guidance Package are not included in this release but are available as a separate download. Thus, there is no longer a dependency on Guidance Automation Extensions (GAX).

 Read the entire article at Tom Hollander's blog:  http://blogs.msdn.com/tomholl/archive/2008/05/17/enterprise-library-4-0-get-it-while-it-s-hot.aspx

Quick Links:

– MSDN site: http://msdn.microsoft.com/entlib

– Community Forum: http://go.microsoft.com/fwlink/?LinkID=119312

– Community Extensions: http://codeplex.com/entlibcontrib

In what areas does Google look for keywords?  There are 3 documented areas; URL, Title, and the body of your content.  How does Google find the keywords in URLs?  Does the order of the keywords matter?  Rob Howard answers these questions and more in his post SEO & ASP.NET: Put keywords in the URL.  If you're at all interested in SEO I recommend taking a look.  I haven't read the entire series yet but it appears to be extremely informative and an easy read.

I've recently discovered Matt Berseth's blog and can say, quite honestly, that it is full of excellent posts including this one which shows a bunch of very cool themes with which you can style the TabContainer control in the ASP.NET AJAX Control Toolkit.  Be sure to check out the live gallery while you're there too.

I'm working on an application where I have the need to display properly scaled images within an area of limited size.  I considered two different approaches for this problem.  First, I can use the framework's image class to resize the image on disk when the user initially downloads it, but since I also need to display at a larger size I would need to keep two copies.  The primary benefit to this approach, as I see it, is that it would reduce the size of the image on disk, therefore reducing the amount of data downloaded by the user.  The second approach, and the one I'll demonstrate here, involves simply setting the size attributes of an img tag to display the properly scaled image within the specified area.

    /// <summary>
    /// Creates the markup to display an image scaled to a specified size.
    /// </summary>
    /// <param name="maxWidth">A <see cref="T:System.Int"></see> indicating the maximum available width.</param>
    /// <param name="maxHeight">A <see cref="T:System.Int"></see> indicating the maximum available height.</param>
    /// <param name="relativeImagePath">The relative path to the image.</param>
    /// <returns></returns>
    public static string GetThumbnailMarkup(int maxWidth, int maxHeight, string relativeImagePath)
    {
        if (string.IsNullOrEmpty(relativeImagePath))
            throw new ArgumentNullException("relativeImagePath");

        System.Drawing.Image currentImg = null;
        string fullPath = HttpContext.Current.Server.MapPath(relativeImagePath);

        using (currentImg = System.Drawing.Image.FromFile(fullPath))
        {
            int sourceWidth = currentImg.Width;
            int sourceHeight = currentImg.Height;
            float percent;
            float heightPercentage;
            float widthPercentage;

            widthPercentage = ((float)maxWidth / (float)sourceWidth);
            heightPercentage = ((float)maxHeight / (float)sourceHeight);
            if (heightPercentage < widthPercentage)
            {
                percent = heightPercentage;
            }
            else
            {
                percent = widthPercentage;
            }

            int scaledWidth = (int)(sourceWidth * percent);
            int scaledHeight = (int)(sourceHeight * percent);

            return @"<img src=""" + relativeImagePath + @""" height=""" + scaledHeight.ToString() + @""" width=""" + scaledWidth.ToString() + @""">";
        }
        
        return string.Empty;
    }

I'm sure there are better ways to do this, so if you know of one please feel free to share.