I had an interesting conversation with some friends last night and it got me thinking more about the roles that testers play in the software development process.  Thankfully I've worked with a number of testers through my career (although I could do with a few more now) and they've all approached the task differently.  Regardless of their methods and effectiveness, all have had to create and monitor defects.  Once that defect had been created and logged (you are using a defect/bug tracking system aren't you?) testers, developers and managers all begin to position and promote defects based on their position's perceived importance of each one.  This is where I've seen things get really interesting.

Some defects are obviously critical to fix and all involved will quickly agree to their importance.  Others are no so cut and dry and it will be these that cause the most heated and passionate debate.  Looking back on the many meetings and conversations that I've had that have degraded into pissing matches over the importance of a defect, I'm starting to realize that they often waste more time and energy than just making the damn change. 

There are bigger issues that the time and energy used in arguing vs. fixing.  In my mind, part of the role of a tester is to be an advocate for the user.  With that responsibility comes the requirement that they do step up and passionately argue defects.  What I've seen in a number of testers that I've worked with, is the feeling that they need to tirelessly argue for the user on all defects.  By pursuing all the defects with the same vigour, the testers that I've worked with have, over time, worked themselves into positions where they're seen as calling wolf. 

When this happens the people triaging and fixing the defects will begin to immunize themselves from the testers arguments.  They will begin to reject defects out of spite, apathy and disillusionment with the tester.  Having this type of situation can make meetings heated and they often seem to degrade into personal shoving matches.  Testers hate the development team for appearing not to care about fixing the applications.  Developers hate dealing with the testers because they know that this one defect is not nearly as highly prioritized as the other things that they are working on.  Triaging defects becomes a nightmare where you can't win.  People begin to loose confidence in the team and the system.  Morale plummets, and a death knell rings for your team.

My advice to testers is to be passionate about the defects that they are finding.  Pursue 'defect free' like a dog after a bone.  Be careful though.  Don't demand that all defect receive the same resourcing and attention.  Instead know that the attention they are receiving during triage is the same, but after that some defects are going to be ignored until time, resource and/or money become available.  If you feel that a specific defect has not received the attention that it deserves then pursue it.  Pick your battles though.  Fight for the defects that you believe have been mis-prioritized and that the User will receive the most benefit from.  When you're doing this make sure that you can present a clear argument outlining how this is going to affect the User in ways that demand the priority be re-evaluated.  Developers, managers, other testers and, most importantly, the Users will appreciate you doing this.  If you're not arguing every defect and you're presenting good reasons for changing the defect's priority, most people won't have any animosity to your efforts.  This will allow you to be more effective when you present concerns to the team.  It will also greatly increase the overall quality of your team.

To all the testers out there that I've worked with.  Thanks.  After spending the last three to four weeks managing a small group who's focus has been to test a huge portion of an application, I have a much better appreciation of what you do and how you're perceived within the team.

One of the great additions in Visual Studio 2005 are SmartTags.  These are the little drop down menus that appear in the IDE when you're writing code.  The one I use the most is 'Add Using' functionality.  What I don't like about SmartTags is the default key stroke (Ctrl+Alt+F10) that ships with Visual Studio 2005.  Who can feel comfortable with this monstrosity of finger yoga?  The first thing that I do when I start working with a fresh IDE is to remap the View.SmartTagShow View.ShowSmartTag item to Ctrl+Alt+Down Arrow.  I find that it is more intuitive (you are, after all, trying to make something appear in a downward fashion) and much more physically comfortable.

Athletes do it.  Musicians do it.  Artists do it.  How may developers do it?  The skills that we use everyday don't just magically appear.  Lots of developers learn and hone these skills by working on real world projects.  Is this right?  I don't think so.  Companies pay good money to hire us with the expectation that we know what we're doing in some area.  They don't pay us all this dough so that we can show up and try out some cool new thing on their unsuspecting clients.

Practicing development isn't easy.  You have to come up with problems to solve.  Sometimes that's harder than solving the problems.  Insert Billy McCafferty here.  He's creating a challenge every week where you submit your solution to a refactoring problem for the chance of winning a book.  Who cares about the book.  Billy is creating the problems for you!  Solve them.  Explore them.  Practice with them.

The rules and explanation are here.

Challenge #1 is here.

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.

The place I'm working right now doesn't allow me to install software, no matter what it is, onto my development desktop.  I can understand their concerns with licensing, viruses and the such, but I'm struggling without a full toolkit. 

Developers need tools, and there are times when we don't see the need for them until we're right in the middle of trying to track down some odd behaviour in our applications.  We also need tools so we can stay productive.  I don't mind the fact that you're willing to pay me a bunch of money to come in and write code, but let me at least try to give you the best return on my time as I possibly can.  I will give kudos out to my current employer.  They have tried to adopt good tools for the developers.  All workstations have ReSharper, TestDriven.NET, Textpad and a few other in-house utilities.  This is all great, but it's not quite as far as I'd like to see it.  On top of that I don't have the patience to work through a month or more of process to get the next tool installed on the developer workstations.

This has led me into the world of portable apps.  Right now I have 3 that I'm using and I'm sure the list will grow.  

The first is Firefox.  There are a whole bunch of explanations on the web about setting it up to run off on a USB drive so I won't get into it here.

Second is SlickRun.  Now this one did have a few starter examples on the web, but none that I found took it to the point that the application is fully operational from a USB drive.  Here's how you do it.

1. Install SlickRun on any PC.  Part of the installation process will be to install the Delphi runtime if it isn't already.
2. Copy the SlickRun installation folder (C:\Program Files\SlickRun) to a folder on your USB Drive.
3. Copy the Delphi runtime files (rtl60.bpl, vcl60.bpl, vclx60.bpl) from C:\WINDOWS\SYSTEM32 into the SlickRun folder on your USB Drive.  These files must be in the folder that contains the sr.exe file.

Running SlickRun is as easy as double clicking on the sr.exe file.  A couple of things to note.  First is that SlickRun will create a set of folders on your USB Drive to hold Application Data, Cookies, Desktop, etc.  I haven't figured out a way to tell SlickRun where to look for these on my local machine.  Because of this you will want to leave your USB drive plugged in until you have completely logged off or shut down your computer.  If you don't it may cause synchronization problems.  I also encountered problems with SlickRun starting some applications, like Visual Studio, and not recognizing the right locations to pickup things like the ReSharper license that I had installed on that PC.

The third application that I have installed is Notepad++.  This one is easy.  Just copy the installation folder from C:\Program Files\NotePad++ onto your USB Drive and you're done.

Hope this helps and let me know if you have any other development tools/aids that you run from your USB Drive.