Thanks again to the folks who attended my talk on Effective Distributed Teams during the Cincinnati Day of Agile on Saturday.
You can find my slides up on my site.
I really appreciated the interaction from folks during the talk. It’s great to hear what tools and practices work for other folks running with team members scattered around the globe!
Skype’s Firefox extension gets installed whether you want it to or not. Uncool. This plugin is notoriously unstable and resource hogish. Moreover, Skype actually has the Big Brass Ones to disable the Uninstall button in the Add-ons UI:
There’s a way around this. Directions below for FF3.6 or higher.
I love Skype and use it for hours each week, but pushing stuff on me without my consent isn’t cool.
Adam Goucher has a great blog post on looking for comment-based code smells in software you’re testing.
Every occurrence of //TODO, //HACK, or God forbid, //FIX, is a pointer to a spot in the codebase where someone took a shortcut. More often than not those shortcuts highlight unfinished or outright sloppy work – spots rife for bugs, complexity, and all the other messes associated with pain.
Adam’s post has a Python script you can use to report on these problems. PowerShell lets you do the same thing as well in a bit terser fashion. Here’s how I skinned this cat in PowerShell:
Get-ChildItem . -include *.cs -recurse | Select-String -pattern "//todo","//hack","//fix"
Tests\FunctionalTests\Telligent.Evolution.Tests.Selenium\Telligent.Evolution.Tests.Selenium\Common\Utilities.cs:158: //HACK: TolLower is a workaround for Unfuddle 3458. Remove when fixed.
[1] The offending author of that line is rumored to look suspiciously like this blog’s author who declined to comment on the matter.
Updated: Fixed snippet formatting
Calling out folks in your organization for things they’ve done and milestones they’ve achieved is not only cheap, it’s a highly effective way of keeping your team motivated and fired up. There are a number of neat ways to handle this; I thought I’d pass on a few I’ve been involved with over the last few years which I think work particularly well.
First off, look to call out folks in your regular meetings: your team’s dailies (you are doing daily standups, aren’t you?), your regular iteration closeouts/demos, or even your organization’s (hopefully!) regular broader meetings.
In Telligent’s Product Development group where I work we have bi-weekly iteration demo meetings. The group gets together and shows off features we’ve closed out and discusses status of the products we’re working on. My former boss Josh Ledgard started a “Shout Out” section of the meeting where folks can call out others in Telligent who’ve been particularly helpful. We generally take five or ten minutes to call out folks for things like great mentoring or pairing sessions, support from our IT staff, etc. Seeing an individual’s hard work recognized in front of their peers is a sweet thing.
Secondly, look to call out folks for specific actions which have a larger impact your organization.
Not long after he came on board at Telligent, our CEO, Patrick Brandt, made everyone in the company read Raving Fans, a very interesting book on how to focus on amazing customer service. Shortly after that Telligent started handing out Raving Fans awards at the company-wide quarterly meetings. Winners get a neat wooden letter/number corresponding to the Raving Fan category they won in. (Find ‘Em, Get ‘Em, Launch ‘Em, Wow ‘Em, Support ‘Em, Plus 1%. Read the book, is all I can say.) Winners also get a very nice, sizable gift card at Amazon.
These Raving Fans awards tie back to our company’s core values and vision around how we’ll be successful by ensuring our customers love our products, services, and support. Regularly recognizing your staff for those contributions ensures those values and goals are fresh in everyone’s minds – and moreover, that those values and goals aren’t just the empty-hot-air-phrase-of-the-day they are at far too many organizations.
Finally, look to recognize folks for hitting significant milestones. Shipping software is hard work, regardless of whether you’re in a product group, services company, or internal development division. You’re running the gamut of communication issues, technical problems, politics, and all the other myriad of difficulties that contribute to our industry’s far-too-high failure rate.
Focus on delivering great value to your customers, then CELEBRATE that accomplishment with your team. Maybe you can’t afford $200,000 release parties, but you certainly should set aside some budget for at least a few small things.
One of my most-cherished pieces of memorabilia from my entire working career is this project card from my days at Quick Solutions, Inc. I joined Quick and got placed on a project which ran in to a number of difficulties both on our side and the customer’s. It didn’t quite turn in to a death march. Quite. We finally got things settled down and delivered a lot of really neat functionality – and the team that had pushed through a lot of pain had by that time formed some very strong bonds.
This project card lists folks who worked on the project (we missed Jeff Blankenburg who left Quick for Microsoft before the project ended), a bit about the project, and some screenshots of the apps.
Every project at Quick’s Solutions group got one of these cards. Every project. Folks who’d been at Quick for a long time had a wall full of these things, and it was an awesome reflection of the value they’d shipped to our customers and the accomplishments they’d made happen for the company.
The three things I’ve talked about in this post don’t have to be over the top expensive or extravagant. Small things matter. Just figure out some way to call out your folks for the hard work they do.
It’s cheap, it’s effective, it’s an easy thing to do.
Update: Fixed a grammar nit (sorry, misplaced apostrophe’s kill me) and corrected the busted Twitter handle for Jeff.
Driving Technical Change by Terrence Ryan. Pub by Pragmatic Press. ISBN 1934356603
Having problems convincing your team, organization, company, customer, etc. to adopt a new methodology or technology? Like that’s never happened to anyone else before…
Terrence Ryan’s Driving Technical Change is a nice collection of insightful tips and strategies for dealing with people skeptical of the change you’re trying to push through. Ryan’s writing style is very clear and approachable, and the book’s perfectly sized at 130 pages – there’s just the right amount of content without belaboring various concepts.
Ryan starts off with a couple short chapters helping you focus whatever it is you’re trying to pitch (Defining the Problem, and Solve the Right Problem), then lays out his list of types of skeptics, along with insights on what drives them and advice on how to deal with them:
The next two sections of the book, Techniques and Strategy, lay out guidance for dealing with the skeptics. The Techniques section is very tactical in nature, offering up pattern-like approaches such as Gain Expertise, Create Trust, and Build Something Compelling. Each of the chapters follows the same template, and Ryan tells you which approach works best for what sort of skeptic.
The Strategy section of the book helps you with broader issues in dealing with groups, and Ryan starts off with what I think is a terrific piece of advice: “Ignore The Irrational.” The Irrational skeptics have no logic behind their objections and won’t ever be swayed – so don’t spend your energy trying to deal with them. Engage them in dialog when they approach you, but focus on other groups who you’ve got a chance at impacting.
Ryan finishes up with a final chapter on some hard knocks he’s learned through various successes and failures. It’s a nice closer to a solid, useful book for figuring out how to best deal with people skeptical of change you’re trying to implement in your organizations.
The great Cincinnati Day of Agile conference is coming up SOON!
I’m honored to have been picked up to give a talk on making distributed teams work effectively. I’m really excited about this talk because it’s been something close to home – I’ve been part of and have overseen a number of distributed teams over the last several years. As a result I’ve got plenty of scars but also plenty of successes to share.
As a note: many of the items I’ll be discussing work for making teams run great regardless of whether you’re in the same room or on different continents.
I hope to see you there!
Clarity of an API’s intent and behavior is critical when you’re developing an API, be it internal or external. Overloads seem like a sexy way to pile up a lot of options for your API’s consumers; however, you’re doing no one any favors by overloading behavioral changes based on differing parameter combinations.
Much of the .NET framework is awful about this; SharePoint’s APIs take that a horrific step further. It’s Emeril’s “BAM!” on crack, but not as cute and charming.
Today I spent far too long trying to decipher why I wasn’t able to upload a file to a SharePoint document library. Two different usages of a call to SPList.RootFolder.Files.Add(), two completely different results.
This call caused an Access Denied exception to get thrown:
DateTime created = DateTime.Now;
DateTime modified = DateTime.Now;
bool overwrite = targetList.EnableVersioning;
SPFile newFile = targetList.RootFolder.Files.Add(name, file, ht, author, author,
created, modified, overwrite);
This call successfully uploaded the file:
bool overwrite = targetList.EnableVersioning;
SPFile newFile = targetList.RootFolder.Files.Add(name, file, ht, overwrite);
Have a look at the documentation for SPFilesCollection.Add. It has 24 overloads. Twenty-frickin-four, ladies and gentlemen. The signatures vary from two parameters to eight – some with two DateTime and Boolean parameters. Worse yet, there’s no indication in any of the overloaded descriptions that they’ve differing requirements or prerequisites. (Thankfully the SharePoint crew named the parameters somewhat clearly so it’s somewhat helpful deciphering intent while in the IDE.)
After a couple hours of troubleshooting, I found the first invocation was successful when the invoking user had Full Control rights to the doclib but would fail when the user only had Contribute.
The documentation didn’t provide any help, so I spent a bit of time trying to understand why the two different results. I can only assume (and I’m using the word advisedly) the first method requires the additional privileges to set properties about the file as it’s being uploaded. This is my complete assumption because, as you may have noticed, the documentation wasn’t any help.
So stepping back from my regular rants about SharePoint’s awful developer experience, let’s have a look at the root problem: two different invocations of the same method with completely different behaviors behind them. #FAIL.
The right way to do this would be to NOT overload those particular calls and instead refactor them out to completely different calls. That first method call should instead look something like
SPFile newFile = targetList.RootFolder.Files.AddAndModifyFileProperties(name, file, ht,
author, author, created, modified, overwrite);
Overloads are absolutely appropriate when you’re offering up the same behavior (see your favorite unit test framework’s overloads for AreEqual, etc.) – but overloads are flat evil when you’re offering them up and backing them with completely different behaviors.
Please don’t overload methods with behavioral changes. If you’re feeling that evil go kick a kitten or promote Richard Simmons for President. Just don’t do the overloads. Please.
UPDATED: Whoops. I was so fired up I confused the Liskov principle with the Law of Demeter. Thankfully Jim Weirich pointed out my error! Corrected.
Problem: You’re seeing odd SharePoint exception behavior throwing vague “Unable to evaluate expression because the code is optimized or a native frame is on top of the call stack” messages as a general exception.
Issue: You may likely be seeing an Access Denied issue; however, SharePoint “helpfully” adds custom handling for that and bypasses general exception handling for you.
Solution: Turn off the CatchAccessDeniedException property, then reset it after you’re done with your code. See the example in MSDN documentation for specifics.
(Hat tip: Paul-Jan on StackOverflow)
Subscribe (RSS)
The Leadership Journey
