I haven’t been posting a whole lot lately and I figured I should write out the reasons why.  Not so much because I think you guys give two shits (you might, who knows), but more because I wanted to see this in writing in the hopes that it will trigger something in me.  I’ve warned you now.  Move to the next post in your aggregator, I’m sure it’s better than this drivel.

I started this most recent gig around a month and a half ago.  Since then I’ve rode the project startup roller coaster around and around.  When I first started I was supposed to get my team geared up, learn the domain, understand the existing codebase that I was extending and start cranking out some code.  Initially I had 2 weeks until jump-off.  I love this kind of thrill.  The rush generated by the challenge to consume so much and turn out product that meets the three things that I’m in this industry for:

1. Meeting and/or exceeding the business expectations of the client.
2. Excessive quality.
3. Code maintainability.

The surge of adrenaline, in this case, was amplified by the need to convert the existing code-base from .NET 1.1 to .NET 2.0, assembling a completely new team and figuring out how to work in the new environment.  I’m an old adrenaline junkie (I rode bulls for a few years) so I embraced this situation.  After that for a start I figured I would love this environment.  One I could thrive on.  Then the roller coaster ride began.

First it was a simple change of schedule.  No longer did I have 8 months to get my team to produce.  Instead I had 6 months.  Another surge of adrenaline.  The next day I was told that my team size would increase by one.  The next thing was the changing of the start date from the middle of October to the start of November.  Then a couple days later the team size was cut by two.  Then the project timeline changed again….we get 9 months to completion, but we’re not starting until December.  Repeat ad nauseam.  This is has now gone on for over a month and, frankly, it’s getting old.  Very old.  I’m at the point now where all I can do to keep my sanity is ignore the stuff about the project.  I’m going to be like the first guy parachuting out of the plane when the airborne heads into battle.  I’ll prep as much as I can, but I won’t worry about go time until they tap me on the back or push me out.

I figured when this all started that part of my job as a developer team lead was to shield my team from the crap.  I never expected that I’d have to protect myself from it too.  It has certainly cemented for me the reasons that I was trying to insulate my team.  This type of crap sucks the will to live right out of you.  It kills momentum at a team and individual level before you even get started.

Insulating my team from the flux that the project timeline is in became only one of my concerns.  I also have to protect them from the MS Project wielding boss.  I’m not adverse to schedule.  Heck, I’ll embrace a realistic schedule with both arms and maybe one leg.  I understand the importance of setting a solid delivery schedule (iterations and their contents) for the sake of the test team and the client.  Those two things said, I don’t like to tell the developers on the team what the delivery date is for every piece of work that they’re assigned.  I don’t like seeing the MS Project wielding boss sending an updated project plan to each individual developer at the start of every week.  I haven’t seen it with the guys on my team yet (they’ve all been there less time than me), but I see the longer tenured developers looking at a task and working on it so they meet the schedule.  It doesn’t matter if they can have it done in half the time, they will always adjust to deliver when MS Project says they should.  Thank you MS Project for taking the foot off of the accelerator that controls our development velocity.

I got hired because I can lead a team of developers to a goal.  Part of that is knowing how to plan, how to meet deadlines and how to resource the work.  I don’t like having my team’s work dictated to me.  I especially dislike having my teammates told when they are doing the work I’m going to be managing.  Above both of those things I hate people who say things like “Don’t try to juggle the schedule unless you think you’re smarter than MS Project”.

As a developer team lead I have an intrinsic and intimate relationship with the schedule, the velocity of the project, the skills and comforts of each developer, and, believe it or not, I have real time knowledge of the state of the work that needs to be done.  The last time I was in MS Project I didn’t see any of these things as configurable options.  So, yes, I do think I’m better equipped than MS Project to plan work tasks, juggling my way to a quicker delivery.  No, I can’t immediately print out an updated Gantt chart.  No I can’t recite the planned percentage usage of each resource.  Instead you can sit down with me every so often and ask me questions.  Ask me how we’re doing.  I know.  Ask me if we’ll meet our deadline.  I know.  Ask me if I think I have some extra cycles on my team.  I know.  If I don’t know this stuff, I should be fired or moved into a regular developers role.  You hired me because I have experience doing this stuff.  Let me use the skills and experience you sought me for.

Hang on a second while I pour a scotch (Ileach…very peaty and very tasty) and collect my thoughts.  Sigh.

Okay, so I’ve said my peace on project planning and trusting a development team lead to (ohmigosh!) lead.  Now I’ll move on to equipping your people so they can succeed.  When I first started this project I was pleasantly surprised to see that they had ReSharper, Reflector, nUnit, nAnt and TestDriven.NET installed on every developer workstation.  I was happy to be working with dual monitors (mine are only 17” LCDs…sniff…not 19” LCDs like the newbies are getting) and I felt that the 1 GB of RAM on each developer workstation was adequate.  What I found out later is that it’s impossible to enhance the toolkit.  I’m not a fan of developers adding third-party assemblies willy-nilly, but there are times when you need to work with a specific tool for a specific problem.  If I need Spy++ to help diagnose a problem (this did happen about a week ago) I have to file thirty-eight different forms, each in triplicate, just so I can have the trial version pushed down to my PC a week later, so I can determine if the tool is adequate in the environment.  Then I have to file another eighty-three pieces of paperwork so that I can have the tool pushed down to all the developer’s workstations, allowing them to once again be productive.  So for me to get Spy++ installed on a couple of developer workstations it was going to take almost a month.

I believe in allowing computers and software to empower the individual user to do their job more efficiently and higher quality.  A month to get a diagnosis tool installed is too long.  Three things can happen from this.

1. The defect being investigated sits idle, most likely getting worse, until the software is installed.
2. The defect gets fixed through the implementation of more effort, and a reduction in morale, while waiting for the requested software to be installed.
3. Developers install now, solve the problem now and beg forgiveness later.

We all know that developers who have installation privileges to their workstation will most likely install software when they need it.  I’ve made it a hard and fast rule on my team that the developers will install whatever tools they need and if anyone asks they did it on my say so.  Again, it’s my job to shield the team from the crap.  It’s also my job to produce.  I think my approach achieves both.

While I’m on the topic of equipping developers for success, let me say that, as contract developers, we have a responsibility to equip ourselves.  It’s incumbent upon me to grow myself.  Maybe I read blogs and write experimental code at home.  Maybe I pay my way (we are contractors after all) to a conference or some training.  Either way, I’m selling myself and, more importantly, my skill set.  Improving it will make me more valuable to anybody looking to employ me (it will also make me more money).  You, Mr/Ms Employer, should be damn happy when I ask for time off to go to training or a conference.  You should jump for bloody joy when I’m willing to pay thousands of dollars out of my own pocket so that I can bring that knowledge back to your offices and propagate it to others, ultimately increasing the quality and skill of your team.  Don’t ever balk at any one of us wanting to take a week off here and there so we can do this type of thing.  If you’re worried about the impact on the schedule, you’ve obviously planned to tightly and you’re most likely going to miss the date even if we don’t go.  It’s all about planning.  You can’t count on your developers being 8 hour resources day in and day out.  You can’t plan on them being 6 hour a day resources day after day after day.  You have to plan for holiday time.  You have to plan for training time.  You have to plan for illness.  Please include this stuff in your MS Project <gag> plan if you must.  Developers, don’t let your employers tell you that you can’t take time off for training or conferences.  If you’re a contractor, the only thing that you have to sell to the next potential employer is your skill set.  Don’t let your current employer sabotage your future employability.

Wow.  I think I’ve ranted.  Did I learn anything from spewing this?  I dunno.  Maybe.  I guess all I can do on any project is stand up for the people who I’m working with, ignore the scheduling crap and put my own skill set first as it’s all I have to sell.  Hopefully the start of my development cycle will see happier times.  I’ll still have to protect my team from the ill winds that blow, but these are good guys and I have no problems doing it for them.  All I can hope is that I’ll get to write a few production lines of code in .NET 2.0.