Here is a screencast of my recent Code Generation talk at Quick Solutions. This is our first recorded screencast, so we're a little rough at first, but I think this is pretty good for our first attempt. For the curious, I was connected to a network projector while Alexei Govorine was shadowing the screen with his laptop, and running Camtasia Studio to do the capture. this worked out nicely in that it left my laptop free to run the slides and demos without having to be concerned with the recording duties. I tried capturing the screen myself earlier in the week, and found that Camtasia slowed down the demos slightly, and made some Powerpoint fades and transitions a bit choppy. Anyway, this is my first screencast, so enjoy, and if you're one of my non-programming friends, and have no idea what I'm talking about, that's okay... you don't have to watch the whole thing... muggle.

"Assuming everyone else does their job, does this code do what it should?"

"Assuming everyone else does their job, does this code do what it should?"

On 12/31/08 all the 30 gb Zunes in the whole world died en masse.  This was attributed to a bug having to do with 2008 being a leap year.  Because the 31st was the 366th day of the year, something in the clock code for the Zune freaked out, locked up, and earned Microsoft a lot of scorn from the Apple fanboys of the world.

This started me thinking.  It should be easier to test what your code will do at a particular time.  Thinking aloud over Twitter, I settled on a design similar to the way TransactionScope works.  You put your code inside a using statement, and it thinks it's whatever time you want.  It's not quite that easy since we can't just replace the DateTime class, or at least not that I know of.  If someone has some Ninja tricks that would allow us to do this, I'd be glad to hear them.

In the meantime you'll have to replace all the calls to DateTime.Now and DateTime.Today with calls to similar properties on the new DateTimeContext class.  If you're not IN a DateTimeContext at the time, then these methods will return the real date or time, just like you'd expect.  If you wrap some code in a using DateTimeContext block, then they'll return whatever you've told them to.  I dislike changing code solely for the purpose of testing, but for purposes of testaBILITY is okay.

Here's a unit test I wrote that illustrates how the DateTimeContext class is used.

[TestMethod]
public void DateTimeContext_returns_expected_values()
{
    DateTime date1 = new DateTime(2008, 12, 31, 23, 59, 59);
    DateTime date2 = new DateTime(2009, 1, 1, 0, 0, 0); 

    Assert.AreEqual(DateTime.Today, DateTimeContext.Today);
    using (new DateTimeContext(date1))
    {
        Assert.AreEqual(date1, DateTimeContext.Now);
        using (new DateTimeContext(date2))
        {
            Assert.AreEqual(date2, DateTimeContext.Now);
        }
        Assert.AreEqual(date1, DateTimeContext.Now);
    }
    Assert.AreEqual(DateTime.Today, DateTimeContext.Today);
}

Notice that the Asserts that are outside of any context are comparing against Today, and the ones inside are using Now.  This is just to get around the problem where the time could have changed between two retrievals.  I could have asserted that the difference between the times was some negligibly small amount, but I wanted the excuse to hit both the Now and Today properties anyway.

Now on to how it works.  The DateTimeContext class uses Thread Local Storage to store a reference to the current instance, and provides a static "Current" property to help us get to that instance.  When we ask for Now or Today, the static methods will check to see if there is an instance on the thread, and if so, they'll return what they've been told to return.  If not, then they'll defer to the real DateTime values.

public static DateTime Now
{
    get
    {
        DateTimeContext current = Current;
        return (context == null) ? DateTime.Now : current.Value;
    }
} 

public static DateTime Today
{
    get { return Now.Date; }
}

Each instance of the class also has a "PreviousContext" property that will remember the instance that was on the thread when it was instantiated.  This lets us nest contexts, and they'll unwind properly when you've finished with them.

private object PreviousContext { get; set; }

There are multiple constructors which mirror the most commonly-used DateTime constructors as a convenience.

public DateTimeContext(long ticks)
    : this(new DateTime(ticks)) {}

public DateTimeContext(int year, int month, int day)
    : this(new DateTime(year, month, day)) {}

public DateTimeContext(int year, int month, int day, int hour, int minute, int second)
    : this(new DateTime(year, month, day, hour, minute, second)) {}

public DateTimeContext(int year, int month, int day, int hour, int minute, int second, int millisecond)
    : this(new DateTime(year, month, day, hour, minute, second, millisecond)) {}

public DateTimeContext(DateTime value)
{
    Value = value;
    var slot = Thread.GetNamedDataSlot(slotName);
    PreviousContext = Thread.GetData(slot);
    Thread.SetData(slot, this);
}

Finally, there are all the fiddly IDisposable bits and destructors that make it all tick.  When a DateTimeContext is disposed, it puts the previous instance back on the thread, allowing us to stack them up all we want (Or until we run out of memory).

Here's the whole class.  Hopefully it proves useful for someone.  It should make it a lot easier to test what certain code will do on or just after certain transition/edge case days.  This may not be the final version, but I couldn't stop thinking about it until I wrote it out.

public class DateTimeContext : IDisposable
{
    #region Fields

    public const string slotName = "DateTimeContext";
    private object PreviousContext { get; set; }

    #endregion

    #region Properties

    public DateTime Value { get; set; }

    public static DateTimeContext Current
    {
        get
        {
            var slot = Thread.GetNamedDataSlot(slotName);
            var current = (DateTimeContext)Thread.GetData(slot);
            return current;
        }
    }

    public static DateTime Now
    {
        get
        {
            DateTimeContext current = Current;
            return (current == null) ? DateTime.Now : current.Value;
        }
    }

    public static DateTime Today
    {
        get { return Now.Date; }
    }

    #endregion

    #region Constructors/Destructors

    public DateTimeContext(long ticks)
        : this(new DateTime(ticks)) {}

    public DateTimeContext(int year, int month, int day)
        : this(new DateTime(year, month, day)) {}

    public DateTimeContext(int year, int month, int day, int hour, int minute, int second)
        : this(new DateTime(year, month, day, hour, minute, second)) {}

    public DateTimeContext(int year, int month, int day, int hour, int minute, int second, int millisecond)
        : this(new DateTime(year, month, day, hour, minute, second, millisecond)) {}

    public DateTimeContext(DateTime value)
    {
        Value = value;
        var slot = Thread.GetNamedDataSlot(slotName);
        PreviousContext = Thread.GetData(slot);
        Thread.SetData(slot, this);
    }

    ~DateTimeContext()
    {
        RestoreState();
    }

    #endregion

    #region Methods

    private void RestoreState()
    {
        var slot = Thread.GetNamedDataSlot(slotName);
        Thread.SetData(slot, PreviousContext);
        if(PreviousContext==null)
            Thread.FreeNamedDataSlot(slotName);
    }

    public void Dispose()
    {
        RestoreState();
        GC.SuppressFinalize(this);
    }

    #endregion
}

Update 1/1/09: I decided to call the class DateTimeContext instead of the original DateTimeScope.  It just sounded better to me personally.  Also, comments about the DateTime issue "possibly" being the cause of the global Zunepocalypse were removed since that's exactly what it turned out to be in the end.

For whatever reason, developers don't universally love the Visual-Studio-generated Accessor classes, as helpful as they may be.  They do solve a lot of problems when you're writing unit tests, though.  It would be nice if you could achieve the same results without having to resort to an external class.  Now, through the magic of reflection, and extension methods, you can.

The idea started simply enough.  There are a number of places in my current project where developers (me included) have made methods public that really ought to be private or protected, just so that we can get to them for testing purposes.  Then, we've simply excluded those methods from the public interface that we are using to reference those objects.  We're using StructureMap to handle dependency injection, so virtually every logic class, service, and controller is being used via an interface.  In our particular case, this works well, but it has still always bugged me that we're changing the behavior of classes to facilitate testing, and then depending on a condition of our environment to make that "okay".  I wanted to keep those private members private, and just use reflection in the unit tests to get to the "naughty bits" that we shouldn't be exposing, but I wanted to do it without the Accessor classes that so many people seem to despise.

What I wanted was to be able to get and set private fields and properties without having to go through a lot of extra Accessor class generation, and in a way that's not going to clog up my unit tests with a lot of tedious reflection code. By writing a few extension methods against object (I know, I know), I can now write unit tests that look like this:

[TestMethod]
public void SetPrivatePropertyValue_sets_property_value()
{
    Target.SetPropertyValue("ReadOnlyProperty", "test");
    string value = Target.ReadOnlyProperty;
    Assert.AreEqual("test", value);
}

So far I've got extensions to get/set fields and properties, and to call non-public methods.  Unfortunately, I can't seem to get away from having to name the properties as "magic strings".  These extensions aren't meant for "real" day-to-day coding anyway, though.  They're meant to be used from unit tests, and if you rename a property or method in your code, the unit tests should barf the next time you run them anyway, so any problems shouldn't live long.  I've read some interesting information on Chad Meyers blog, but haven't been able to make it work with my extension methods so far, or at least not without things getting messy.

Here is my current set of reflection extension methods:

public static class ReflectionHelper
{
    private const BindingFlags bindingFlags =
        BindingFlags.Instance | BindingFlags.NonPublic | BindingFlags.Public | BindingFlags.Static;

    #region Field operations

    public static FieldInfo GetFieldInfo<TClass>(string name)
    {
        FieldInfo fieldInfo = typeof(TClass).GetField(name, bindingFlags);
        return fieldInfo;
    }

    public static object GetFieldValue<TClass>(this TClass instance, string fieldName) where TClass : class
    {
        if (instance == null)
            throw new ArgumentNullException("instance");
        return GetFieldInfo<TClass>(fieldName).GetValue(instance);
    }

    public static void SetFieldValue<TClass>(this TClass instance, string fieldName, object value) where TClass : class
    {
        if (instance == null)
            throw new ArgumentNullException("instance");
        instance.GetType().GetField(fieldName, bindingFlags).SetValue(instance, value);
    }

    #endregion

    #region Property operations

    public static PropertyInfo GetPropertyInfo<TClass>(string name)
    {
        PropertyInfo result = typeof(TClass).GetProperty(name, bindingFlags);
        return result;
    }

    public static object GetPropertyValue<TClass>(this TClass instance, string propertyName) where TClass : class
    {
        if (instance == null)
            throw new ArgumentNullException("instance");
        return GetPropertyInfo<TClass>(propertyName).GetValue(instance, null);
    }

    public static object GetPropertyValue<TClass>(this TClass instance, string propertyName, object[] index) where TClass : class
    {
        if (instance == null)
            throw new ArgumentNullException("instance");
        return GetPropertyInfo<TClass>(propertyName).GetValue(instance, index);
    }

    public static void SetPropertyValue<TClass>(this TClass instance, string propertyName, object value) where TClass : class
    {
        if (instance == null)
            throw new ArgumentNullException("instance");
        instance.GetType().GetProperty(propertyName, bindingFlags).SetValue(instance, value, null);
    }

    public static void SetPropertyValue<TClass>(this TClass instance, string propertyName, object value, object[] index) where TClass : class
    {
        if (instance == null)
            throw new ArgumentNullException("instance");
        instance.GetType().GetProperty(propertyName, bindingFlags).SetValue(instance, value, index);
    }

    #endregion

    #region Method operations

    public static MethodInfo GetMethodInfo<TClass>(string methodName)
    {
        MethodInfo result = typeof(TClass).GetMethod(methodName, bindingFlags);
        return result;
    }

    public static object CallMethod<TClass>(this TClass instance, string methodName) where TClass : class
    {
        if (instance == null)
            throw new ArgumentNullException("instance");
        return instance.GetType().GetMethod(methodName, bindingFlags).Invoke(instance, null);
    }

    public static object CallMethod<TClass>(this TClass instance, string methodName, params object[] parameters) where TClass : class
    {
        if(instance==null)
            throw new ArgumentNullException("instance");
        return instance.GetType().GetMethod(methodName, bindingFlags).Invoke(instance, parameters);
    }

    #endregion
}

I'll probably end up adding more later, but this is fine for my current needs.

The Goal:

On my current project, we need to disable the UI while performing long-running operations such as the loading and saving of data.  We started off using some dirt-simple code that would wrap the long-running process in a try/finally block, disabling the form at the beginning of the "try", and re-enabling it in the "finally".  It was simple, and worked just fine at first, but started showing its limitations as things have got a little more complicated.  Our forms host UserControl "Views" which sometimes wrap other views as children.  Any one of these views, parent or child, might need to trigger a long-running processes.  To complicate matters further, some of the child views' processes can be expected to be called as part of the parent views' processing.

For instance, lets say we have an order processing system, and the customer details view is considered a parent view.  Within that view are multiple child views for displaying things like address information, or a list of that customer's order history.  Loading, saving, or refreshing the parent view automatically results in the loading, saving, or refreshing of the child views.  In addition, some child views can be loaded, saved, or refreshed individually, and therein lies the problem.  I can't just repeat my el cheapo try/finally trick in the child views because as each child view finishes its individual processing it will automatically re-enable itself, but the other views may not be finished with their processing yet.  In short, each child should remain disabled until they've all finished their work.  This scenario is a complete fabrication, but it illustrates the point.

It occurred to me today that the problem of disabling and enabling the forms was very much like the problem of changing the cursor to and from the hourglass.  I've been using a customized and renamed variant of Doogal Bell's CursorHandler class (http://www.doogal.co.uk/cursor.php) to handle setting and restoring the hourglass cursor on my last couple projects.  It's simple to use, and you can stack up as many calls to it as you want, and they will always unwind properly.  I thought I'd try something similar to handle my enabling/disabling needs.  Parent view controllers would perform their work inside a using block, which would automatically restore both the hourglass and the enabled/disabled state of a control when it's finished.

The Difficulty: (Skip ahead if you want, I won't be offended)

In theory, this should be very simple.  In reality it requires a few tricks.  First of all, if you disable a container control such as a UserControl, a Panel, or a GroupBox, you'll see that all of the controls inside that container get disabled for you automatically.  When you re-enable the container, the children will go back to their original states.  This is very convenient, and takes a lot of work off our hands normally but it interferes with my plans in this particular scenario.  If you ask the child controls of a disabled parent whether they are enabled or not, they will say they are disabled even when it's really their parent that's disabled.

So things would go pretty much like this.  My parent view instantiates a new WaitContext (As I'm calling it), which looks at the parent control and memorizes that it was enabled when it started, and then disables it.  The parent view initiates some process on the child view which in turn instantiates its own WaitContext which looks at the child and memorizes that it was disabled when it started.  The child view's process completes, and its WaitContext tries to "restore" the original setting, which it remembers as being disabled.  The parent view then wraps up its work and unwinds its WaitContext, which properly sets the parent view back to enabled.  Because the inner WaitContext disabled the child view we now have an enabled parent with a disabled child.  This isn't what we started with, though.  What we really need is to know whether each individual control is really disabled, or is just disabled by virtue of being contained in a disabled parent.

Thanks to the miracle of Lutz Roeder's Reflector, I found out that Enabled isn't just a simple boolean property.  When you ask a control whether it's enabled, the answer you get back depends on a couple of things.  First of all, it depends on whether that individual control is disabled, and secondly on whether that control's parent is disabled.  It's that first part that we're interested in.  Determining whether a control has been explicitly disabled is done by checking bit 4 of the control's "state" field via the GetState method.  State contains a number of flags indicating all kinds of things like whether the control is Enabled, Visible, or in the middle of doing something.  Unfortunately for us, the state field is private, and the GetState method is marked Internal, so we can't see either one of them.

Since I know the name of the method I want, and I know which bit I'm looking for, I can still get what I want via Reflection.  The call to get the original Enabled state of the control looks like this:

OriginalEnabled = (bool)Control.GetType().InvokeMember("GetState", 
    BindingFlags.Instance | BindingFlags.InvokeMethod | BindingFlags.NonPublic, 
    null, Control, new Object[] { 4 });

Setting the enabled state actually takes two steps.  The call to "SetState" sets the bitfield, and the call to "OnEnabledChanged" forces the control to notice the change and repaint itself.

Control.GetType().InvokeMember("SetState", 
    BindingFlags.Instance | BindingFlags.InvokeMethod | BindingFlags.NonPublic, 
    null, Control, new Object[] { StateEnabled, enabled });
Control.GetType().InvokeMember("OnEnabledChanged", 
    BindingFlags.Instance | BindingFlags.InvokeMethod | BindingFlags.NonPublic, 
    null, Control, new Object[] { EventArgs.Empty });

The Result:

Wrap your long-running code inside a Using block that instantiates a WaitContext object like this:

using (new WaitContext(this))
{
    // long-running code goes here.
}

There are three different constructors.  The parameterless constructor will change the cursor to the hourglass without disabling anything, and makes the class work just like Doogal's CursorHandler.  The second constructor takes a Control reference, which is the control to disable.  It changes the cursor to the hourglass (Or spinning donut for Vista users), as well as disabling the specified control.  The third, and final constructor allows you to specify the control to disable as well as what cursor should be displayed.  It's probably not going to get used, but I like to include it for completeness and flexibility.

The Class:

Here is the finished WaitContext class.

public class WaitContext : IDisposable
{
    #region Fields

    private const BindingFlags flags = 
        BindingFlags.Instance | BindingFlags.InvokeMethod | BindingFlags.NonPublic;
    private const int StateEnabled = 4;

    #endregion

    #region Properties

    private Control Control { get; set; }
    private Cursor OriginalCursor { get; set; }
    private bool OriginalEnabled { get; set; }

    #endregion

    #region Constructors / Destructors

    public WaitContext()
        : this(null)
    { }

    public WaitContext(Control control)
        : this(control, Cursors.WaitCursor)
    { }

    public WaitContext(Control control, Cursor newCursor)
    {
        SaveState(control, newCursor);
    }

    ~WaitContext()
    {
        RestoreState();
    }

    #endregion

    #region Methods

    [ReflectionPermission(SecurityAction.Demand, MemberAccess = true)]
    private void EnableControl(bool enabled)
    {
        Control.GetType().InvokeMember("SetState", 
            flags, null, Control, new Object[] { StateEnabled, enabled });
        Control.GetType().InvokeMember("OnEnabledChanged", 
            flags, null, Control, new Object[] { EventArgs.Empty });
    }

    private void RestoreState()
    {
        if (Control != null)
        {
            Control.Cursor = OriginalCursor;
            EnableControl(OriginalEnabled);
        }
        else
        {
            Cursor.Current = OriginalCursor;
        }
    }

    [ReflectionPermission(SecurityAction.Demand, MemberAccess = true)]
    private void SaveState(Control control, Cursor newCursor)
    {
        Control = control;
        if (control != null)
        {
            OriginalCursor = Control.Cursor;
            Control.Cursor = newCursor;

            OriginalEnabled = (bool)Control.GetType().InvokeMember("GetState", 
                flags, null, Control, new Object[] { StateEnabled });
            EnableControl(false);
        }
        else
        {
            OriginalCursor = Cursor.Current;
            Cursor.Current = newCursor;
        }
    }

    #endregion

    #region IDisposable Members

    public void Dispose()
    {
        RestoreState();
        GC.SuppressFinalize(this);
    }

    #endregion
}

Footnote: Why yes, I am an adherent of "Oxford commas".

I found an interesting bug this morning, and figured I'd better write about it so that maybe I'll remember to avoid it in the future.  We have a Linq query that involves a couple Joins.  The main table we're interested in is already provided for us by a "FilteredNotes" property like this:

IQueryable<Note> notes = DataContext.Notes;
if (!canViewAllNoteTypes)
{
    if (canViewLegalNoteTypes)
        return DataContext.Notes.Where(n => legalCategoryIds.Contains(n.CategoryId));
    else
        return new List<Note>().AsQueryable();
}
...

The results of this pre-filtered set of data are then joined to two other tables to provide some additional filtering like so:

IQueryable<NoteSummary> results =
    from d in this.FilteredNotes
    join c in this.DataContext.Claims on d.ParentId equals c.ClaimId
    join e in this.DataContext.Enrollees on c.EnrolleeId equals e.EnrolleeId
    where d.ResponsiblePersonId == userId &&
          d.CompletedDate == null &&
          d.ScheduledDate >= startDate &&
          d.ScheduledDate <= endDate
    orderby d.ScheduledDate ascending
    select new NoteSummary
               {
                   ...
               };

return results.ToList();

This code has been working great, until I started testing a new security role type.  When I am under the guise of this new type, the query would run for a long time, and then explode with an OutOfMemoryException.  The problem is actually really simple once you see it.  In that first section of code, the author wanted to return an empty list to join against, since the user wasn't authorized to view any of the categories of notes that we're interested in here.  The trouble is the way the empty list was created.  Creating a new list with nothing in it, and then calling AsQueryable() generated an empty IQueryable, but it did it in memory.  Since this is the main list to which we're joining the others, Linq wants to pull them ALL into memory and do the join there.  Normally you might not notice, but since this database has millions of rows in each of the tables we're joining to, it tends to make things bog down a bit.

The solution is to create our empty list, but to do it in a different way.  We want an IQueryable of Notes that will become part of a single Linq query sent to the database.  We can solve this by changing the FilteredNotes property to retrieve the IQueryable<Note> in a way that defers its execution, but still guarantees it will be blank:

IQueryable<Note> notes = DataContext.Notes;
if (!canViewAllNoteTypes)
{
    if (canViewLegalNoteTypes)
        return DataContext.Notes.Where(n => legalCategoryIds.Contains(n.CategoryId));
    else
        return DataContext.Notes.Where(n => false);
}
...

There, by changing the condition to be simple "false", the retrieval of the Notes can now be part of one big query, but we know that it'll be empty when that happens.  Problem solved.

Today I needed to retrieve a Type by name, but from a foreign assembly.  Without going into the gory details, it's related to instantiating Windows Workflow Foundation's RuleSetDialog after a rule has been loaded in from a database.

I could have made a call to Assembly.GetExecutingAssembly().GetReferencedAssemblies(), and iterated over the results looking for the one I wanted, but I'd still have to end up looking for it by name, and anyone who knows me knows that I hate string comparisons.  Since I already knew what assembly the thing I'm looking for is in, that also seems like a waste of time.  So I found a bit of a cheat.  I'm happy enough with it to put it here in the hopes that it will be useful to someone else someday.

Since I already know what assembly my business entities are in, I should be able to get a reference to the assembly by starting with one of the types from there.  In this case I chose the BusinessEntityBase class because it's nicely meaningless on its own, and because the whole world would collapse anyway if this class were to be moved or renamed, so it seems like a stable thing to anchor myself to.  From there, I can easily get to that type's Assembly property, and call GetType() on it, passing the name of the actual business entity I really want.  Here it is in its full two lines of glory.

Type businessEntityBaseType = typeof(BusinessEntityBase);
Type entityType = businessEntityBaseType.Assembly.GetType(typeName);

Here, typeName is a string containing the fully qualified name of the business entity I want to edit a rule for.

Wow... exciting topic, eh?  It is actually somewhat interesting, though.

Background:
I'm working on a project where we've had to split validation away from the business entities for a couple reasons.  First of all, business entities live at a lower level than the logic classes responsible for loading and saving them.  They are kind of ignorant of their surroundings, and so not all validation rules can be expressed from there.  Instead, the validation rules are considered "business logic", and as such, they live in the "logic" assembly.  The problem is that we need validation to be kicked off by Linq attempting to save the entities via the OnValidate method.

What we settled on was a ValidationManager class which lives in the Business assembly, but gets populated from the Logic assembly at runtime with a dictionary which is used to look up the proper validator for a given entity.  The IValidator<TEntity> interface is defined in the Business assembly, but any common assembly would do.  So the business entities know what a validator looks like without having to have a reference to the validators themselves.

The next hurdle, and the one responsible for this post's title, is doing the registration.  At first, we just had a static constructor for the base logic class that had one line for each validator, associating it with the business entity it validates and pushing it into the dictionary.  This works just fine, but it turns out it's pretty easy to forget to register a validator when a new type of entity is created.  You've got the entity, and you've got the validator, but unless you register them, nothing will actually happen during the OnValidate method.

Solution:
Instead of manually adding code to register each validator, I'm now using some reflection code to find all the classes which implement IValidator<T>, and register them automatically.  The code is short, and pretty sweet if I must say so myself.

    Type validatorType = typeof(IValidator<>);
    foreach (Type objType in Assembly.GetExecutingAssembly().GetTypes())
    {
        foreach (Type interfaceType in objType.GetInterfaces())
        {
            if (interfaceType.IsGenericType && (interfaceType.GetGenericTypeDefinition() == validatorType))
            {
                Type argType = interfaceType.GetGenericArguments()[0];
                ValidationManager.RegisterValidator(argType, objType);
            }
        }
    }

I just finished with Neal Ford's keynote, and am waiting for Jeff Blankenburg to start his talk in lieu of Jesse Liberty on Silverlight.  I have to say I disagree with Neal about his choice of metaphors for software engineering.  Having worked in a RUP shop before, I'd liken the blueprints of traditional engineering with the UML diagrams popular in the RUP methodology.  Neal was saying that the actual code we write is the equivalent of a blueprint, and that the compiler is the manufacturing phase, but had to admit that the metaphor doesn't fit exactly because in traditional engineering, the manufacturing part is the most expensive and time consuming phase.  Well obviously the writing of the actual code is the most time consuming, expensive part of software engineering.  The compiler is more like the tools that the laborers use to DO the manufacturing.

Agile practices eliminate the UML dependency of traditional RUP practices, and so the metaphor starts to break down from that side as well, but there's not much we can do about that.  I suppose in our agile development practices, it's closer to having the engineers do the actual construction, sometimes with the assistance and guidance of a "senior" engineer with whom they must discuss all design decisions before committing them to concrete.

I totally agree with most of the rest of the talk, though.  Except maybe that last part about the type safety... I loves me some type safety... it's my thing.  Sorry.