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)
Continuing with more reviews I’m horribly overdue on…
Agile Coaching by Rachel Davies and Liz Sedley. Published by Pragmatic Press, ISBN 1934356433.
I’m amazed that this book covers so may critical topics so well and in such a short length! It’s a terrific book that can help guide you to building highly effective teams regardless of whether you’re a professional coach or team lead.
The book is formatted in four major sections (Coaching Basics, Planning as a Team, Caring About Quality, and Listening to Feedback), each with a few chapters around areas fundamental to good teams. The chapters are comprised of short sections working through details on things like good user stories, hijacked standup meetings, or defining what “Done” means.
I love the concise, easy-to-read style of the authors, and the content in the book is extremely helpful. They hit all the obvious topics, but they also lay out common tough issues like driving change in your organization, keeping meetings effective, and helping resolve team issues of culture and respect. Coaching’s easy when everything’s easy – but the real world requires great coaches to deal with tough problems and this book’s a tremendous help in that aspect.
I also love the authors focusing on issues that are so core to my own notions of great software teams: effective team environments, concise and simple user stories, listening to your teams, and fostering scads of communication. It was also great seeing an entire section of three chapters devoted to software quality, but then I may be a bit biased in that direction…
This book gave me a number of highly useful insights and made me re-think some approaches to common problems I see. It’s a great addition to my bookshelf.
Agile Retrospectives by Esther Derby and Diana Larsen. Published by Pragmatic Press, ISBN 0977616649.
I’ve been a firm believer in retrospectives for a number of years. I’ve used them on many projects in my last two jobs and the benefits have been tremendous. This book is a great help for me in tuning up and improving how retrospectives work.
The writing is extremely concise, well-done, and in a great tone. The authors cover the basics of retrospectives (Set the Stage, Gather Data, Generate Insights, Decide What to Do, and Close the Retrospective), but then head off into a number of other critical topics.
I really enjoyed the authors not shying away from dealing with potentially tough emotional parts of retrospectives. You’ll find short, extremely helpful tips on dealing with the occasional shouters, criers, stompers-off, etc. Retrospectives can be intense, and too many books skip over the unfortunate reality that on occasion you may have some drama to work through. Derby and Larsen don’t shy away; they’re practical in their advice.
Agile Retrospectives also emphasizes teams need to find a retrospective formula that works for them. They offer up a number of different approaches (fishbones, brainstorming, etc.) and lay out situations where those are helpful. (The section on fishbones was particularly helpful to me.) They also have a section on how to run longer post-release or post-project retrospectives – a horse of a completely different color.
Overall this has been a tremendously useful book, and I’ll continue to pull it off my shelf to brush up.
I occasionally need a larger disk in one of my VMWare VMs, and I always forget how to do it. I’m writing this post to save myself time the next time I need to do it!
Problem: You need a larger disk in one of your VMWare VMs.
Solution: Expand the disk first in VMWare, then inside the guest OS use Disk Management to extend the disk. (Of course this is somewhat centric to Windows 200*, Vista, or Windows 7 guest OSes. Steps 1-4 apply are the same regardless of your guest OS.)
Note: You can’t extend volumes in VMWare if the VM has any snapshots.
Problem: Internet Explorer 8 won’t clear out authentication credentials and keeps signing you on to a site with a set of undesired creds. In this instance, you’ve likely told Internet Explorer to remember a user’s logon creds for a site with Windows authentication turned on. You want to log on to that same site with different user credentials, but you can’t get IE to bring back up the user logon dialog. Clearing out all browser data (Tools | Internet Options | Browsing History | Delete | check all boxes, clear Preserve favorite website data) doesn’t solve the issue.
Solution: Use Fiddler to delete the browser’s cookie header. Start Fiddler and use Tools | Automatic Breakpoints | Before Request. Open IE and navigate to the bothersome site. Click on the last entry in the sessions pane, then right click on the Authorization cookie in the right Headers pane and select Remove Header.
Flip back to IE and clear out all browser data again (Tools | Internet Options | Browsing History | Delete | check all boxes, clear Preserve favorite website data) .
Now switch back to Fiddler and click Run to Completion in the lower left pane.
At this point you should be presented with the familiar login dialog.
Problem: Your code snippet fomatting in Blogger looks like poo – extra line breaks “helpfully” injected by Blogger leave your snippets with more whitespace than a third grader’s resume.
Solution: From a forum post by Daniel Carrarini on MSDN: Go to your Blogger’s control panel and select Settings | Formatting. Then change Convert Line Breaks from Yes to No.
Voila!
Repeatedly typing out msbuild command lines with configuration switches (release, debug) and clean/regular, FTL.
Here’s a quick Ruby script to let you specify –d, –r, –c for debug, release, and clean, respectively. –d and –r are mutually exclusive, but you need one.
Oh! the joy of optparse. Dunno how many times I’ve written a command line parser for just this sort of use case. Love how well this works OOB.
require 'optparse'
def process_command_args
$options = {}
opts = OptionParser.new
opts.banner = "Usage: build [options]"
opts.on( "-r", "--release", "release configuration" ) do
$options[:releaseconfig] = true
end
opts.on( "-d", "--debug", "debug config" ) do
$options[:debugconfig] = true
end
opts.on( "-c", "--clean", "clean build" ) do
$options[:clean] = true
end
opts.on("-h", "--help", "Display this screen") do
puts opts
exit
end
opts.parse(ARGV)
if ($options[:releaseconfig].nil? && $options[:debugconfig].nil?)
puts "Red pill or blue, your choice. Try -d or -r.ac"
puts opts
exit
end
if ($options[:releaseconfig] && $options[:debugconfig])
puts "Make up your mind: release OR debug, not both"
puts opts
exit
end
end
def do_the_work
if $options[:releaseconfig]
$config= "release"
end
if $options[:debugconfig]
$config = "debug"
end
$sln = Dir.glob("*.sln")
if ($sln.length > 1)
puts "More than one .sln file here. Can't figure it out, bailing."
exit
end
$command = "msbuild " + $sln[0] + " /p:configuration=" + $config
if $options[:clean]
$command += " /t:clean"
end
system($command)
end
process_command_args()
do_the_work()
If you want an effective project team, then you need to ensure everyone on the team is able to make the right things happen. This is especially important on projects which are in critical phases or are suffering through a painful spot with your clients/stakeholders. You can’t get through tough spots in a project if members of that team have to constantly run back to their supervisory chain to get approval for every decision, or if they can’t help you get roadblocks out of the way.
Sometimes it’s apparent that a member of the team was put there for no other reason than to have a token presence at the table. That member has no authority to make decisions and is unable to commit to anything because they’re constantly having to go elsewhere to get approval for fundamental actions. There’s a great term used to describe these people: “The Meeting Guy.” (Or “The Meeting Gal” if you prefer.)
I’ve run in to this a couple times in my career, and it’s never pleasant. You need someone to bust through impediments, and instead you’re saddled with someone who never delivers on anything because they can’t make anything happen. The Meeting Guy may be a wonderful, happy person, but at the end of the day they’re an impediment to the success of your project.
Having The Meeting Guy on your team is frustrating because your project’s progress suffers. Worse yet, this may be a dangerous sign of a lack of commitment from your client or stakeholder: they may not care enough about the project to fully support it. The worst of all situations might have someone seeking to actively sabotage the effort by saddling the project with a Meeting Guy – thankfully a situation I’ve never run in to.
Identifying the Meeting Guy
Sometimes it’s obvious right away if The Meeting Guy is on your team; other times it may take a few iterations/releases/weeks or an outright crisis to unmask the person. Daily standups are the biggest help in determining if you’re saddled with a Meeting Guy. Is someone on the team regularly missing commitments with reasons like “I’m waiting on <x> to give me approval for <y>,” or “We’re blocked on that while I coordinate with <z>?” Potential Meeting Guy.
Note that I said “regularly.” Stuff happens, and not everyone can get every roadblock instantly out of the way. Meeting Guys/Gals are repeat offenders.
Dealing with the Meeting Guy
There are no easy answers when you’re stuck with The Meeting Guy. You have to get communication flowing to find out what the real issue is – because The Meeting Guy is a symptom, not a root cause.
You need to have a frank, open discussion with your project’s stakeholders and potentially with the project’s executive sponsors. Take a breath and leave your frustrations behind. Approach the conversation from the business value aspect: “We’re not able to deliver the amount of value we should be because we’re not able to get through roadblocks in a timely fashion. Having the right people committed to the team will help us deliver more quickly.”
What’s the Root Cause?
You also need to step back and re-evaluate the need for the project. If stakeholders and sponsors won’t get the right people at the table, is there actually a real need for the project? Perhaps the business environment has changed and the project isn’t as high a priority any more. That’s not an easy topic to bring up with the people responsible for the project, but it’s a hard question that you need to get answered. Again, approach it from the business value aspect: “If the business situation’s changed so much, maybe we should stop this project and figure out a better place to spend our time and effort. What other cool things can we do for the business?”
Never, ever approach these conversations with a demanding mindset or tone. Yes, you need to clearly identify impediments and risks, but you can’t slip over in to metaphorical hostage taking or blackmail!
These are tough conversations to have with the people and organizations responsible for the project, but you must have them. Something is preventing you from delivering the best business value to the client/organization/stakeholders. Find the root cause, solve it, and focus on helping your organization/clients get the best value for their money!
It’s been a long time since I’ve written up reviews on anything from my book pile. Here’s an overdue catch up post with short reviews of several books I’ve read over the last six months or so.
Growing Object-Oriented Software, Guided By Tests by Steve Freeman and Nat Price. Pub Addison-Wesley, ISBN 0321503627.
The first part of this book seemed scattered, jumping all over the place and making a lot of reference to things which weren’t defined until later in the book. However, once you get used to the style, this book jumps off a cliff and hits a lot of great topics, and hits them in depth.
Tooling, design, culture, methodologies – it’s all covered, and it’s covered fairly well. I particularly enjoyed the authors carrying the same detailed, practical example through the book. Too many software books use trivial examples specific to one topic. Freeman and Price evolve an “Auction Sniper” as they go through the book; the consistency is a great asset.
I also enjoyed the authors speaking emphatically about using acceptance tests as the starting point for features, not just unit tests. There’s an important differentiation between acceptance and unit tests, and the authors specifically call out acceptance tests “using only terminology from the application’s domain” – speaking to the feature’s business driver, not the underlying technology.
Also as critical to me is the authors’ emphasis on keeping the test side of the codebase clean. Your tests ARE production code. Treat them with the same approach about solid design and refactoring as you treat the code you’re deploying to your customers.
This isn’t a simple 100-level book. The authors dive deep in to design, practices, and lifecycle. They do it well enough that they’ll hook newcomers to testing as well as teach accomplished folks new things too.
Great read.
Cooking for Geeks by Jeff Potter. Pub by O’Reilly, ISBN 0596805888.
OK, this book is just plain fun. The recipes are straight-forward and tasty, and it’s terrific to dive deep in to how and why food transforms itself during the cooking process.
Potter covers everything from Calibrating Your Instruments to creating your own sous vide immersion cooker. Along the way you’ll learn about how leaveners work, discover a new taste factor you may not have known of (Umami), figure out some key time/temperature figures critical to food safety, and get exposed to some interesting molecular gastronomy.
The writing style is exceedingly well-done. Potter does a great job walking readers through the recipes and the science behind them – and it’s extremely apparent that he’s writing about something he loves.
I’m a very serious, very accomplished home cook and I got a tremendous amount out of this book. More importantly, I had scads of fun reading it.
Apprenticeship Patterns by Dave H. Hoover and Adewale Oshineye. Pub by O’Reilly, ISBN 0596518382.
Short, concise, well-written, highly useful. Other books such as Chad Fowler’s The Passionate Programmer cover similar things, but this book sits absolutely well in that company.
This book is a series of very short articles (“patterns”) around specific things you can do to guide and improve your career as a software craftsman. The articles all follow the same template: discuss the context of an environment/situation you’re in, lay out a problem you need to solve, then offer up a solution for you to apply to that problem. Many of the articles are interwoven, linking common ideas or useful concepts.
This book echoes a number of things in Passionate Programmer like the concepts of being the worst in your group (work with folks that are a LOT better than you so you’ll learn more), but it’s a very worthwhile read on its own.
Apprenticeship Patterns is particularly nicely done in that the authors don’t push a specific path they expect you to follow. They lay out a number of options and encourage you to find the path that works best for you.
I also GREATLY appreciated the authors being pragmatic over dogmatic in their approach to software craftsmanship. Certain zealots in the craftsmanship movement have completely lost site of the primary purpose of our trade: delivering value to customers. In their section “Craft over Art” he authors specifically and emphatically point out that we need to deliver “value to customers over advancing your own self-interests.” They don’t promote getting sloppy with one’s work, but emphasize doing your work well while keeping the folks in mind who are writing the checks.
All in all, this is a solid read.
Problem: You have the physical files for a Hyper-V virtual machine and you need to convert it to VMWare. (Maybe you’ve downloaded one of Microsoft’s demo systems such as their SharePoint 2010 Information Worker Evaluation VM.)
Solution: If you have access to HyperV, load the image in HyperV and use VMWare’s stand alone converter. It’s awesome. Point it at your HyperV server, select the server, and the converter does the rest.
If you don’t have access to HyperV, all is not lost.
Option 1: Install Virtual PC, create a new virtual system, use the VHD from the image you have. Start that system up in VPC, ensure it’s running, shut it down, then use VMWare’s Import feature to read the .vmc file Virtual PC created. (VMWare’s Import will deal with .vmc files from VPC, but not the .xml or .exp files from HyperV.)
Unfortunately, the image I was trying to import wouldn’t come up in VPC, so I was left with the less elegant, funky sledgehammer approach of
Option 2: Grab WinImage, a nifty piece of shareware that lets you convert a VHD directly to a VMDK – the format VMWare uses. Download it, install it, launch it, use Disk | Convert Virtual Hard Disk image. Select the source VHD, choose to use a fixed or dynamic target disk type, then give it the name and location of the target VMDK. (See the very nice HOWTO.)
Now you can create a new VMWare image and use the existing VMDK. The VMDK’s format is from an older version of VMWare, but VMWare will nicely upgrade it for you.
Power on your VM and bask in your geeky awesomeness.
Then go pay for WinImage because they’ve saved your bacon and you should throw some money their way. That’s how shareware works, folks.
Problem: In VMWare 6.x and 7.x I constantly run in to the problem where I set the VM to full screen mode and then have the cursor in the VM go completely bonkers – clicking anywhere in the VM causes the cursor to shoot to the upper left corner. Occasionally a number of items on the screen will get selected.
Solution (sort of): Toggle the VM to multiple-monitor mode, minimize VMWare, maximize it again, and finally switch back to single-monitor mode. It’s ugly, but it works.
Problem: You get the infamous, unhelpful error message screen in SharePoint 2010 (“Click here to troubleshoot problems with SharePoint Foundation”) when trying to access Site Actions | Site Settings | Manage site features (or Site collection features).
Error logs show entries from the w3wp.exe process, usually entries such as “System.IO.IOException: The file or directory is corrupted and unreadable” followed by other exceptions with “...Context.RunAsProcess(CodeToRunElevated secureCode)” as their entry.
Solution: I checked the app pool for my SharePoint web app and found it was running with Network Service. For whatever reason, that account wasn’t given read access to SharePoint’s 14 hive (C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14) during installation or site collection creation.
It’s hacky, and I’ve not done a lot of validation, but simply granting Network Service read/write/modify privs to this folder solved my problem.
IMPORANT NOTE: This was on a dev box. I’ll dig deeper before doing the same on a production system. You should too!
CodeMash 2011 is in the can and I’m mostly recovered after a weekend at the Kalahari and several naps yesterday.
Behind the scenes we organizers had a number of issues that gave us a load of last-minute grief, but hopefully we did a good enough job that most of those issues never leaked out in to public.
One of the big things we’ll refactor for next year is our approach to keynoters. Every year in the previous conferences we’ve had the same basic setup: 20 – 30 minutes for attendees to get their food prior to the keynoter kicking off their talk. This let us hold meal periods to 90 minutes, enabling us to not lose an additional breakout session right after keynoters. This also enabled us to get three great keynoters each conference, something I don’t think any other conference around does.
This arrangement has worked extremely well in the past; however, this year attendees made it clear by their Tweets and especially their behavior during the keynotes that they wanted a better separation of meals and keynotes. As a result next year we’ll likely drop down to one single keynote following a longer meal period. We’ll lose one additional breakout timeslot, but it will give everyone more time to deal with the logistics of getting though the food lines. I’m personally saddened by the loss of the two additional keynoter slots, but we need to follow what our attendees are pushing for.
Note on the food lines: Unfortunately, we had two meals that were quite honestly train wrecks regarding long lines at the buffets. I’ll personally take the hits on these due to some miscommunications with the venue’s catering folks regarding timing. This is the first time in five conferences we’ve ever had this problem. I covered the issues with the Kalahari’s awesome staff during the post-conference wrap up with them. Please trust me: the problem of grossly backed up buffet lines will never happen again. Ever.
Note on the Thursday lunch “keynote”: It wasn’t a keynote. This was specifically a special launch event. We thought it was a wonderful opportunity to have something of a global impact showcased at CodeMash. We’d be happy to consider other vendors approaching us for future events of a similar nature. We’ll also work harder to ensure everyone understands the differentiation between launches and keynotes.
We’re also going to consider refactoring the notion of allowing family members to eat with the attendees. As was very obvious, CodeMash has been extremely limited in venue space the last couple years – the dining hall is completely full with attendees, so there’s no physical space for family members or guests to eat meals alongside the attendees. Previously it’s also been a nightmare to deal with the separate billing required to cover food costs.Thankfully two things have happened that remove a couple significant roadblocks.
First, our move to Eventbrite for ticketing has GREATLY reduced the headaches associated with our registration system. We should be able to handle the mechanics around separate meal-only tickets now. Secondly, the Kalahari is adding on new construction that jumps their conference space from the current 18,000 square feet to well over 120,000 square feet. As a result, we’ll have physical space to seat a lot more folks. We won’t turn CodeMash in to a huge 5,000 attendee conference, but we certainly should have the space for attendees and guests to chow down together.
To be clear: Guests during mealtimes isn’t a done deal, but we’re certainly going to have a hard look at it.
OK, so on to a few things I consider highlights of CodeMash 2011 – and I have a much different view of things I personally find successful than most other attendees.
On a closing note, I have to thank the amazing crew who puts on CodeMash. A large number of newcomers to CodeMash don’t understand that the conference is organized and executed completely by volunteers – and a tiny crew of them at that. I’ve heard of similarly-sized events having volunteer staff of 30 – 100 staffers. We do CodeMash every year with SEVEN, plus a couple on-site helpers.
The core organizing committee, aside from myself, are:
All youse folks are awesome, and it’s amazing to work with you again and see you do tremendous things. (Want more details on how cool these folks are? Read my post from last year I am not CodeMash.)
Thanks to Joe Fiorini, I have an awesome countdown tool that helps me know exactly how close CodeMash 2011 is!
It’s been an amazing run putting CodeMash together this year. We’ve had an amazing turnout from sponsors (we sold out of physical spots!), the best sessions from the best speakers of any CodeMash so far, an amazing lineup of PreCompiler workshops, and of course we are still a bit shell shocked that we sold out in 3.5 days. The screenshot of the CodeMash newsfeed says it all: registration open, registration closed.
There are a huge number of things I’m looking forward to at this year’s CodeMash, but here are a few of my personal favorites in no particular order:
I hope to see you there! If not, hopefully at the 2012 event!
Subscribe (RSS)
The Leadership Journey
