Tuesday, April 28, 2009

Brian Harry Presenting on Team System 2010 on Live Meeting


Brian Harry, a Product Unit Manager for TFS from Microsoft, will be presenting on the new features of TFS 2010 (codename Rosario) and what benefits it will bring to software development and project management. You can read more about Brian on his blog.


Where? https://www.livemeeting.com/cc/microsoft/join?id=G2K4BH&role=attend&pw=PN6.%3CQ%5Drb



When? Thursday, April 30th, 2009



What time? 3:30 to 4:30pm EST



Who should attend? Technical Decision Makers, Lead Developers, and Software Architects who want to see what new innovations are coming from Microsoft and impact they will make on business


Sunday, April 19, 2009

The Importance of Failure




Not too long ago during a technical interview a developer told me that he had "never failed on a project". This isn't the first time someone has said this to me. I assume he intended his boast to make him a more attractive candidate, but instead it made him a much riskier hire in my eyes. So you are probably thinking to yourself "Why would someone who has never failed be a risky hire?" Wouldn't a developer who has succeeded on every project they have been on be pretty darn good?

I find that people who claim to have never failed usually fit one of these scenarios:

They are really that good. It is possible that this person in their vast experience has made all the right choices and risen above all external factors to truly have succeeded in every project they have undertaken. Warning: I find that highly unlikely.



They haven't done much. If you have been on one project that succeeded you would technically be batting 1000. But who would you want on your team: the guy who has hit a home run with one single at bat or the guy who has batted 366 over 1,000 at bats?



Your exposure to the project's success was limited. When you are a developer you tend to think that if you deliver decent code on time then you have done part. And if your team delivers on time and on budget then you can count the project as a success. But there are many other factors for a project to be considered successfully that sometimes project teams are shielded from. I was on a project where my team delivered quality code, on time, within budget, and afterwards the client shelved the entire package and never used it.



Your projects have been small or less critical in nature. I have met someone who at the time had really been on several successful projects. But upon further investigation he worked in a large company on applications that were not mission critical and his projects had more lax success factors. Although he was technically a solid developer, he was very unprepared for more serious endeavors.

So now you think I want to hire people who fail all the time, right? Not exactly. Consistent failure is not good, but small, intermittent failures provide you with opportunities to learn in a way that success does not. When I hear some say they have never failed, I worry that they most likely will not see it coming when they do. And the laws of probability dictate that it will inevitably happen.

Learning from Failure

So if (and I really mean when) you fail, it can never be a total loss if you learn from it. I speak from my own experience.

I was brought onto a project for a fortune 100 company specifically because I had been successful before with implementing new technologies for Sales Force Automation. And at the time in my limited view of what I deemed a successful project, I had always been on the winning side up to that point.

I was the Architect/Team Lead for the team and was also given a good deal of influence in other areas of the project as well. I have to admit that it just fed my ego and I started to think our chances for success were bullet proof. But the project failed and even though there were many contributing factors I had a decent amount of the blame on my shoulders. One of the worst things about it was that even when things had started to go bad, I ignored the signs and thought that through pure force of will I could pull it out in the end.

It was a very humbling experience and in the months immediately afterwards I spent quite a bit of time reviewing what had gone wrong. There were some obvious technical decisions, but there were other factors that had more impact: requirements, project management, team management, customer expectations, and the intangible political environment. I had been so focused on fixing the technical issues that I (and other team members) failed to address these other issues. Even after the initial meltdown, when all the technical issues were fixed, the other factors were such that the application never saw the light of day.

The insight I gained from the failure makes a good deal what I have learned from other successes pale in comparison. I took that and applied it to every project after that, determined not to repeat those mistakes. I am happy to say I have been fairly successful at that and I have had to work hard at finding new and more inventive ways to fail! I have had definitive moments in subsequent projects where I have seen similar signs arise and have been able to try a new approach (some successful, some not so much) to try and mitigate these types of issues. And each time I find a successful way of turning that old issue around, I feel that I become that much stronger of a developer. And when I am asked about my past failures I dutifully speak of them and convey how each one taught me a lesson so that I won't be caught unawares again.

So now one of my initial interview questions for new candidates is "Tell me about a past failure." If they respond that they have never failed then they better really knock my socks off for the rest of the interview to even have a ghost of chance. Likewise if they tell me about a failure and do not follow it up with what they learned from it, in my eyes they just had their first failure.

Wednesday, April 01, 2009

Team System MVP


I was very stoked to get my confirmation email for my Team System MVP today. I was a little worried it might be an April Fools joke, but apparently it is the real deal. I am lucky to be in a group with such talented people and really look forward to getting even more invovled in the VSTS community this next year. Congrats to all my fellow MVPs announced today!