private override

Apprenticeship/Mentorship Success!

One of my apprentices from this past summer just accepted a job… at another company.  I’m totally pumped for him, but most of the people I brag to about it say the same thing with the same reaction:

<sigh_of_defeat>Shoot, we didn’t get him.</sigh_of_defeat>

As if we failed miserably.

For me, the apprenticeship/intern process has the following 4 goals (in order of importance, most to least).

• Teach and develop the apprentice as much as they can possibly absorb.  This includes technical skills, sof-tech skills (like how to learn, what it means to be an engineer, passion, etc.), and soft skills (e.g. how to deal with your lead/PM/that annoying guy next door, etc.).
• Learn from the apprentice as much as I possibly can.  These guys are at school at an amazing time with amazing things happening.  Leech this new knowledge… it’s relatively free. (I’m unapologetically selfish in this regard… I love to learn
• Develop an environment where the apprentice feels comfortable with his mentor, and can start to learn and teach with his mentor back and forth… a true partnership.
• Oh yeah, the last/least benefit… recruiting.  (Sorry Raman)

If at the end of this he happens to also be productive, great, win-win… but that isn’t the point (again, that’s my opinion).

After that list, does this look like defeat?  Not to me.  This looks like a dead-on success.  We NAILED it.  Let’s celebrate!  Congrats Man.  Next time we meet, I’m sure I’ll have something to learn.

[I’m at least going to pretend I played some small part in this outcome.  Whether I really did or not, is debatable.]

every team needs a toolsmith

Every software project is different, and there are subtleties associated with each one.  Every project  requires unique and specific tools, and we need someone to build them, or each member of the team needs the freedom and responsibility to do it him/herself.

I have very little (zero?) tolerance for waste when it comes to automatable processes that aren’t automated because “we don’t have time”, or “we’ll discuss it later” and then it gets dropped, or any other reason that is less than justified.

Zero Friction Development is what I’m going for here. (here is an article that I found interesting around this topic… it’s not really our fault, it’s built into our nature)

What kinds of things am I talking about?  Anything that slows down my development that can be automated away to make me a happier developer.  Whoa, wait, happy? Is that a requirement I have of my workplace?  Absolutely.  I can put up with periods of un-happiness, but long-term unhappiness is not acceptable (for me).  Oops, sorry, almost derailed there for a minute.

Specific frictions I’ve addressed or have seen addressed…  just so you can get an idea about the things that I’ve seen done, that might trigger an idea for you:

• Code-diff generation – On a previous project, all the code for our product was stored in the database itself (Intersystems’ Cache), so we didn’t have a real decent way to generate diff-sets for code review.  So we wrote a tool to do it.  A previously laborious task (at least 30 minutes for a simple changeset), with much room for human error, turned into a 30-second, enter in a task number and press ‘Go’ joy.
• Code Generation – On a previous project the best way to get where we needed was simply to inspect the structure of a piece of data, and then generate code to deal with it.  You’ve probably done this one before… many times.
• Source Control Integration – Again with the Cache project, we needed a way to version our code using standard tools.  We wrote a tool to bridge between the file system (for TortoiseCVS, or any other VCS) and the database storage.
• Client requires code-diff uploaded to their CMS for each completed task – Seems like a bogus business process, but it needs done.  It’s painful because their CMS is slow and clunky.  So I wrote a ruby script, paired with selenium, to automatically create a diff of my code and upload it to their CMS with some browser automation.
• Data generation – Ever need test datasets?  Yeah, me too.  Whip out some ruby and get it done.
• Tool integration – ever have two systems that need to be kept in sync?  Yeah, it’s a pain, especially when neither have an API.  What they both usually have though is either a command line interface or a web interface.  Both of those are easy enough to script with, given some ruby magic and some browser automation.
• Time tracking – There have got to be 8 billion time tracking tools out there… if one doesn’t match your style, bust out a quick one that matches the way you work.  Need it to integrate, there’s probably either a web interface, command line, or API, go for it… it’ll make you happier (hmm… there that is again!).

What other things have you automated?  What are your thoughts on the toolsmith?  There is a whole book about doing this type of stuff with Ruby.  I’ve never read it, but I’ve heard it’s pretty good: Every Day Scripting with Ruby.  Another excellent book by the guys at the prag bookshelf is Pragmatic Project Automation.  It deals a lot with things we already do (build automation), but takes it further as well.  Here is an intro: Pragmatic Project Automation Intro.

For sake of full disclosure, this is not a new idea, and I’m not claiming to have come up with it.  It’s been tossed around for years, just wanted to bring it up again.

Do You Own Your Tools?

I saw this tweet from @unclebobmartin the other day.

Why do we feel like our company ought to buy our tools for us?

This is an interesting concept to me, because, as of late, I’ve been considering pimping my work area to be mine… just as any other craftsman might.

My dad is a skilled tradesman.  He’s a Mould Maker in a glass shop.  He’s been doing this for over 30 years… and he is what I’d call a master craftsman.  I asked about the idea of owning your own tools last weekend.  He nearly interrupted my question by saying:

Yeah, I’ve got about $6000 of my own tools.

I stood floored.  I had no idea.

Previously, I considered the idea to include things like my IDE (Visual Studio, since it is somewhat expensive), ReSharper, Profilers, Editors, Static Analysis Tools, and more.  I also feel like this applies to books (you do read [tech] books… right?).  Someone asked me the other day:

so how do you get SEP to just buy all of your books?

… uhhh, I don’t.  I use my own money.

I can only assume that all machinists have their own copy of the machinist handbook as well.

I actually do have my own copy of all the tools I [willingly] use every day.

Do you?

P.S.  I’ll leave you with one more thought.  I challenge you to add one more piece of equipment to your tool chest (or to at least think about it)…your dev machine.  Should your company provide you with a dev machine?  Why not?  Why so?  I had never considered this until I read this article talking about Hashrocket.  They all use their own machines!

Update:
I think my lack of skill in writing prose has caused some confusion or misunderstanding [Thanks for the feedback!  For Reals.]  This was really meant to be more about responsibility and craftsmanship than about money (or anything else).  The main thought I wanted to invoke was who's responsibility is it to buy/make your tools?

I also did not try to infer that SEP doesn't buy me all the things I need (I'm sure they would, in fact... I just wonder who's responsibility it really is).

Sorry for any confusion.

Stable or Stagnant?

In a recent discussion with a co-worker we made an observation on the topic of progress.  Things that look like they are working, appear to be stable.  However, from another viewpoint that very same subject is stagnant.

Which camp do you live in?

I’d say I [mostly] live in the viewing things as stagnant camp (it’s nice and cozy in my camp, won’t you come join me?).  I’m not trying to say there is anything wrong about believing and adhering to things that we know already work (stable), but what I am trying to say is that we can use stable as a platform to continually achieve better.

If you live over in stable-ville, you’re probably asking questions like:

• Why change it if it already works?
• We’ve done this before, let’s just do it that way, it’s safer (why would we possibly introduce risk!?).
• We made money doing this the last time, if we do it the same way, we’ll make money doing it again.

I admit, you ask great questions.  It’s hard to win an argument against [apparent] concrete profitability.

Here are my sentiments, however, in response to those questions.

First you must assume that things can always get and be better.  I’m not asking to make huge sweeping changes and walk away.  Rather, embrace the stable approach, incrementally make changes, measure, rinse and repeat.

Of course, if things seem to be broken, or you seem to have hit some ceiling (most likely artificial), you may need to take a step back, and take a completely alternative approach.

The key to making change to any subject for the sake of improvement is measuring.  Know what it is you’re trying to optimize, measure it, make the change, and measure it again.  That is the only way to know if you actually got better, worse, or had no impact at all.  (In a slightly related note, Steve McConnell, in Code Complete 2 drove this into my skull at least 50 times during his performance tuning chapters, and I agree whole-heartedly).

Oh, and on that profitability question?  You better always be changing (don’t forget to measure!) otherwise you’re gonna get leapfrogged into oblivion and your competitor that you didn’t even know existed is going to be raking in all your cash.  Likewise with risk.  If you’re not taking risks and just sitting in your comfort zone, you’re probably not growing as an organization or as an individual.

For me, it’s all about continuous improvement.  Don't let stable be the enemy of change, strive for improvement.

If you’re not getting better, you’re getting worse… right?

Testing Events with Awesomeness

How many of you have written this code when testing an event?

[Test]
public void LameTest()
{
    var objectWithEvent = new ClassWithEvent();
 
    var awesomeFired = false;
    objectWithEvent.AwesomeEvent += ( o, e ) => awesomeFired = true;
 
    objectWithEvent.DoSomethingAwesome();
 
    Assert.IsTrue( awesomeFired );
}
 

or its big brother:

[Test]
public void LessLameTest()
{
    var objectWithEvent = new ClassWithEvent();
 
    var awesomeCount = 0;
    objectWithEvent.AwesomeEvent += ( o, e ) => awesomeCount++;
 
    objectWithEvent.DoSomethingAwesome();
 
    Assert.AreEqual( 1, awesomeCount );
}
 

Every time I write that code, it feels WET (read: not DRY), especially when I’m doing it for more than one event in the same test.

What I’d like to see is something like:

[Test]
public void AwesomeTest()
{
    var objectWithEvent = new ClassWithEvent();
 
    var awesomeTracker = new EventTracker<EventHandler>();
    objectWithEvent.AwesomeEvent += awesomeTracker.Delegate;
 
    objectWithEvent.DoSomethingAwesome();
 
    Assert.IsTrue( awesomeTracker.WasCalled );
}
 

Yeah!  Now that’s what I’m looking for.  Is this possible?

Yup.

How?  Let’s see.

So basically what this means, is that we have to generate a method (at runtime) that matches the signature of the delegate we pass to the tracker as the type argument (so it can be added as a handler for the event).  Inside the method, we need to update our tracking variable (either setting a flag, or incrementing a counter).  We can ignore any of the arguments passed to the delegate (e.g. the sender, event args, or anything else), since for our purpose we really don’t care about them.  What I think is so cool about this is that it works for ANY type of delegate you pass to it!  Sort of like generics, but for methods (makes sense in a meta sort of way).

Here is the implementation:

public class EventTracker<TDelegate>
    where TDelegate : class
{
    public static implicit operator TDelegate( EventTracker<TDelegate> tracker )
    {
        return tracker.Delegate;
    }
 
    public EventTracker()
    {
        var delegateMeta = typeof( TDelegate ).GetMethod( "Invoke" );
        var delegateParams = delegateMeta
            .GetParameters()
            .Map( param => param.ParameterType )
            .Prepend( GetType() )
            .ToArray<Type>();
 
        var invokedMethod = GetType().GetMethod( "Invoked", BindingFlags.NonPublic | BindingFlags.Instance | BindingFlags.Public );
 
        var dynamicHandler = new DynamicMethod( "", delegateMeta.ReturnType, delegateParams, GetType(), true );
        var generator = dynamicHandler.GetILGenerator();
        generator.Emit( OpCodes.Ldarg_0 );
        generator.Emit( OpCodes.Call, invokedMethod );
        generator.Emit( OpCodes.Ret );
 
        Delegate = dynamicHandler.CreateDelegate( typeof( TDelegate ), this ) as TDelegate;
    }
 
    public TDelegate Delegate
    {
        get;
        private set;
    }
 
    public int CallCount
    {
        get;
        private set;
    }
 
    public bool WasCalled
    {
        get { return CallCount > 0; }
    }
 
    public bool WasNotCalled
    {
        get { return !WasCalled; }
    }
 
    // called via the dynamic method
    private void Invoked()
    {
        CallCount++;
    }
}

This is my first foray into IL generation… not exactly my forte.  A little more on IL generation next time.  Oh yeah, must give credit where it is due… thanks to Shawn for the help when my fu was weak.