Our firm is taking the plunge into code analysis with Visual Studio 2010.  We work primarily with Microsoft CRM and were excited to see the new enhancements in the CRM SDK 4.0.12, which can generate strongly-typed entities.  When I gave this a test run with a sample project and then ran code analysis, I was gobsmacked when I saw not hundreds, not thousands, but tens of thousands of warnings (25,356 to be exact, and we’re not even using the full ruleset).

If the generated code conformed to the code analysis rules, that would be fine.  If the generated code was tagged with the GeneratedCode attribute, that would also be fine.  To not follow either practice results in code that we have to either manually tag as GeneratedCode or wrap it in its own project in such a way that the code analysis tools simply ignore it, while supervising the rest of our code.

My question is: why do Microsoft product teams selectively use these tools and techniques and what can we do to change this for the better?  For example, CRM5 is coming out soon and it would be great if this functionality in the CRM5 SDK used the GeneratedCode attribute.

I believe that this code generation tool in the SDK is a huge leap forward for us as developers, but its introduction is marred by the limited support it provides for code analysis, especially when it would be so simple to include the GeneratedCode attribute.  I’d like to see generated code marked as generated code and I’m beginning my proverbial march to Washington (Redmond) to make it so.  Stay tuned to the original forum post about GeneratedCode to see if anything comes of it or to add your own $0.02.

For those of you new to code analysis, I strongly recommend perusing the Microsoft Code Analysis team blog; if you are migrating to VS2010 Premium or Ultimate edition, you can jump straight to their post on what’s new in VS2010 code analysis.  In essence, you can configure the code analysis tool (or FxCop if you don’t have VS2010 Premium or Ultimate) to walk through your code (intermediate language following a build, to be precise) and alert you about rules that your code violates.  As you learn about the warnings and update your code, you become a better coder, your code becomes more [performant|readable|maintainable|secure] and the sun shines just a little bit brighter.

Our vision is to ease our developer team in to the code analysis world by applying a basic ruleset – for us, this was everything except Microsoft.Reliability and Microsoft.Globalization, but subject to change - and begin enforcing it on all new projects.  Initially, as developers get accustomed to fixing warnings and ensuring zero-warning code, we’re going to leave the enforcement on at the developer machine level.  We do this by utilizing a project template that is preconfigured to use our ruleset and our custom dictionary.  Eventually, when the developers are all acquainted with this process, we are going to enable build-level enforcement of the rules on the build box.  There are already some resources on the web that describe the process, but when we go ahead and set build-level enforcement, I’ll post about the process and our experience.

Get the tools now and make something interesting.

At 3:40pm, after opening up one of the files I would be modifying next week, I noticed that there were changes to this file.  Visual Studio occasionally injects unnecessary changes to files due to the code/designer file relationship.  I hate to maintain these changes and often revert the file back to its original state after I open it.  Almost instinctively, I right-clicked, selected “Revert” and happily began to inspect this code… until I realized that this was the key file that I had been modifying over the course of this week.  Subversion does not offer a way to “unrevert,” assuming that explicitly reverting is always intentional.  Visual Studio doesn’t recognize the “Revert” command because it is the result of an add-in tool, so there’s no “Undo” at the application level.  In one second, I obliterated several hours of code that I had written.  To add to the irony, I had just read this Dinosaur Comics strip during my lunch break.

The clock was on now.  To save face and avoiding looking like a jerk, I had about one hour to review the file, remember where and what I had changed, recode and validate.  Happily for me, most of the work time involved in this task was still in my brain, so I managed to get a working version of the file wrapped up by 5:05pm, just shortly before I had hoped to leave for the weekend.  Yeah, I know, you’re probably thinking that my story turned out rather anti-climactic, but here’s the kicker – this wasn’t the first time I had lost code like this.

Like all other developers, I am fallible… and hate to admit it.  I am sharing my story today because I believe that there is something to be learned from this (aside from the fact that I was a bit of a dumb-ass).  It has not yet come to me exactly what that lesson is, but when I figure it out, you’ll be the first to know.

Since I have officially made my announcement of departure at Chase (and have a going-away lunch tomorrow!), I wanted to share with all of you – who have found my blog at least slightly engaging - that I have found an exciting new opportunity.  On April 5, I will be starting as a developer lead at Sonoma Partners, LLC, a premier CRM consulting firm.  Literally the folks who wrote the book on Microsoft Dynamics CRM, they seemed like such an engaged and passionate bunch that I decided Sonoma Partners was the place for me.  In case you had not guessed, Sonoma Partners was the firm that had me complete a real-world development exercise as part of my interview.  To affirm what I already felt was a good decision, they sent me a “care package” with a t-shirt, the book Programming Microsoft Dynamics CRM 4.0 (Pro-Developer) and a portable, wire-bound notebook for jotting ideas.  My CRM experience leans more towards SalesForce.com, SalesNet and Outlook Business Contact Manager, so this unexpected package is quite welcome and shows me a simple way that Sonoma Partners demonstrates how they value their employees.

Ok, I’m going to wrap up now, since I’m running the risk  of trying to cover too much in one blog post.  Long story short – it’s been a fruitful, but busy, job search.  From my experience, the market is improving (at least in software), so if you are looking, stay determined, stay positive and you’ll find new opportunity!

• Written/Computer-based Test
  • My Experience – This type of tech screening mimics a professional certification exam.  I have experience with Microsoft developer certifications (five or six exams at this point, depending on how you count them) and the test I took in January was much like each of these tests, in format and content.  The key difference (unless MS certs have changed as well) was that this exam was adaptive – as I answered questions correctly or incorrectly, the next question would be more difficult or easier, respectively.  Additionally, each question had five answers, up to three of which were correct – you lost points for a) wrong answers marked as correct and b) correct answers not marked as correct.  The test had a lengthy introduction explaining how to approach answering the questions.  In my opinion, if a test requires intricate instructions, it’s not actually testing what it purports to be testing.
  • The Merit of this Format – Until a firm is going to pay me to answer multiple-choice tests for 40 hours a week, I consider this screening method to be the weakest approach.  It can demonstrate the memory acts of recall or recognition, but not the cognitive act of application.  At best, this method demonstrates awareness, which is why I’m not terribly fond of certification exam formats either.  They do not prove competency.
  • How to Prepare – If you find yourself in a situation where you are asked to take a multiple-choice written or computer-based screening exam, ask the interviewer about the subject matter.  It might be worth dusting off your old Wrox, O’Reilly or APress books before you boot up the exam.  Yes, I know some people would view this as cramming, but you aren’t going to be paid to complete tests, so you just need to prove familiarity with the subject matter… by any means necessary (except cheating - no need to go all Kobayashi Maru).
• Oral Q&A/Problem-solving (phone or in-person)
  • My Experience – The bulk of my tech screenings were oral-problem solving – two in-person and two by phone.  The phone interviews tended to be more of a straight-forward Q&A – what does <term> mean, do you have experience with <technology> – whereas the in-person interviews tended to be focused more on observing problem-solving approaches.  Let me first state that I much prefer the in-person style.  From my time at Microsoft (prior to the “ban” on puzzle questions), I found that one of the most interesting parts of the interview – as an interviewee - was the puzzle question.  You had the opportunity to stretch your brain around a complex mathematical or strategy problem and show how you approach the problem and reach an answer.  Even working toward the answer was invigorating, whether or not you immediately “saw” the solution.
  • The Merit of this Format – The Q&A model is similar to the “Written/Computer-based Test” approach – the key difference being that you are speaking with a real person, who can better adapt the questions.  If done well, this is an effective means of testing awareness and experience, especially if the interviewer is technical and experienced in the domain.  There is a chance, however, that the interviewer may approach the situation as “how does this candidate compare to me?” rather than “how good a match is this candidate for this position?”  The problem-solving approach can allow the interviewer to get a more “real-world” reaction from the interviewee.  By watching the candidate approach the problem, an interviewer can observe how the interviewee thinks, where they get stuck and how they deal with obstacles to their solution.
  • How to Prepare – For this type of interview, spend some time (maybe 1-2 hours) brainstorming examples of how your past experience is relevant to this new opportunity – what technologies did you use, what are some problem scenarios you solved with creative or elegant coding, etc.  In the interview itself, for Q&A-type questions, be sure to listen closely to the interviewer’s questions, think carefully about your responses and speak confidently or clearly state if you don’t know or are unsure.  Making up answers is a no-no.  For problem-solving questions, verbalize as much as you can about the problem – interviewers want to understand your thought process – ex. do you understand how data structures work? or are you concerned about finding a correct AND efficient solution?  It’s ok to ask interviewers to clarify the problem or aspects of the situation.  A little bonus tidbit – always verbally run tests against your solution; it shows that you are confident of your solution and want to ensure that there are no exception cases not being handled.
• Applied Skills Demonstration
  • My Experience – Hand’s down, this is my favorite approach.  I’ve had two experiences with applied skill demonstrations – one in-person and one take-home assignment.  The in-person assessment was the quintessential “Hello, World” application – my interviewer wanted to see that I was comfortable in the Visual Studio 2008 environment.  To be honest, I was confident that I could do it, but concerned that the task was so easy that I must be missing something.  I completed the application in a couple of minutes (slow computer) and found that this was all he wanted to see.  In the other instance, I was given a compiled DLL, a Word document with a couple of screenshots and instructions to duplicate the application that I was shown.  Easily one of the best interview experiences I’ve ever had.  For the sake of the firm involved, I won’t go into detail about the solution, but I loved the approach of letting me work in the environment in which I felt comfortable (VS Web Developer Express) and within a realistic timeframe (one week) to complete the task – this was a true assessment of my abilities.
  • The Merit of this Format – Aside from a contract-to-hire situation, in which you can observe the candidate in the field, this is the truest test of a subject’s knowledge and skills.  Giving candidates a real-world scenario and asking them to approach it as a professional provides candidates with the flexibility to approach the problem as they would like, while providing enough constraints to make it manageable.
  • How to Prepare – The beauty of this approach is that you don’t have to prepare.  All of the work that you have done up to this point in your career should be preparation enough.  You will need to think strategically and feel comfortable asking clarifying questions about the assignment, just like you would if the employer were your client.  Similarly, you’ll need to understand the requirements and deliver on time (or early).

What technical screening experiences have you had?  Positive or negative?  Challenging or easy?  Share your thoughts below and we can have a discussion around the pros and cons of various approaches – perhaps helping job seekers and employers at the same time.

I thought I was plumb out of luck, but I gave the southern hemisphere of the office a chance. As luck would have it, the water cooler on that side appears to have been inadvertantly left on and I could enjoy a cup of tea.

Then I saw the email that came on Saturday, saying I didn’t need to come in today… now I just feel like Marvin the Paranoid Android.

More than money, however, I feel I have developed some new skills on cloud computing.  For the most part, Windows Azure allows you to leverage your existing .NET skills.  While I was working on the project, I discovered a few “gotchas” that I wanted to share in case you find yourself working on an Azure project.

• There is a development storage option that you can use while building your application or service.  There is only one account name and account key that you can use for this to work properly; do NOT try to use your production account name and key, as they won’t work.  This MSDN article on differences between development storage and Windows Azure Storage Services will fill you in on the name and key to use, in addition to other differences you need to know.
• Get familiar with the storage service URI format – you will use URIs to access your storage queues, blobs and tables.  That part is fairly straightforward.  Queues, I discovered, have additional naming limitations; essentially they have to be all lowercase and only the “-” is allowed, symbol-wise.  It took several attempts at debugging with cryptic error messages before I stumbled upon the article that walked me through this.  It’s too late to put back the hair I pulled out while “debugging” this one.
• When building your solution for deployment, it’s not as simple as going to the Visual Studio 2008/2010 Build menu.  To acquire the two files necessary to deploy to your Windows Azure account – a config (*.xxcfg) and package (*.xxpkg) where “xx” == language code for your .NET language of choice, you need to right-click on the Windows Azure project in your solution and select Publish.  Conveniently, Visual Studio picks up from there, opening an Explorer window with the two files and a browser window directing you to sign in to Windows Azure.  It would be nice if the Windows Azure VS add-in group went the extra mile and give you a deployment dialog to push the project right up at publish time – perhaps in a later release.

Have you dabbled in Windows Azure?  Learned any neat tricks?  Stumbled upon any frustrations?  Tell your tales here – we’re listening.

From an information architecture perspective, the first thing we need to decide is what raw data we will use to calculate the path values and how we will gather this data.  Although either the what or the how could influence the other, I have opted to begin with the how discussion and transition from there to what we will be gathering.

How to gather the data

It would seem that there are three approaches to gathering the data that we will need: completely manual, completely automated, or a hybrid approach.

• completely manual – users have to complete a survey or submit details of relationships.  This approach would be labor-intensive, assumes that users can accurately assess the strength of their relationships and relies on a significant number of users to submit information before the system would truly be of any value.  VOTE: NO WAY!
• hybrid – a hybrid approach – using some available data and relying on users to augment the information – could be valuable to improve the information LinkedIn already possesses, but holds many of the same weaknesses as the completely manual system.  This might be suitable for a long-term approach, but not good to get the system up and running quickly.  VOTE: MAYBE IN THE FUTURE
• completely automated – an automated system relies on the existing information in the LinkedIn databases.  Conveniently, LinkedIn has a plethora of information (see below) available through their new API that developers can access via code and use to calculate the CPV figures that we will need in the future.  VOTE: YES, BEST APPROACH FOR PROTOTYPE PROJECT

Now that we’ve determined to rely on existing data, at least until the system is tested and found useful enough to enhance, we can figure out which data will be useful in determining the value of paths.

What data to use

I am certainly no psychology expert.  Although I have identified a few pieces of information that I suspect are either available in the LinkedIn API or somewhere in LinkedIn’s database (if they decided to implement this directly), there certainly is room for other data that could provide more proof of peer-to-peer relationship strength.  When we get to determining the strength of multiple paths, the individual peer-to-peer values that I explore below will be of significant import.

There are two types of data that will be relevant: user-specific and user-to-user.  User-specific data is information about an individual that could make him or her a valuable node on any LinkedIn connection path.  User-to-user data is specific to a 1:1 relationship between connections, showing a relative value over other connectors.

This may be a pipe dream, but if I could consume any data that I would imagine is already in the LinkedIn database system, it would be the following:

User-specific

• average response time on introduction requests – from the time a user reads an introduction request to the time that they pass it along or decline it
• percent of successful introductions in which this party played an intermediary (either 2nd or 3rd person in a 3 or 4-person introduction path, respectively)

User-to-user

• how long two connections have been connected
• which party made the connection request
• does either party recommend the other party; if so, which
• when was the pair’s most recent exchange on LinkedIn – message, intro request, recommendation, etc.
• user-specific data: response time on introduction requests, introduction success rate

I am confident that these values alone provide enough insight to know if and when a particular user would be a good choice for a connection request.  In my next post, likely coming in the new year due to holiday plans with my wife’s extended family, I will explore a strategy for taking these raw values and converting them into relative CPV data to use in my proposed user experience enhancement for LinkedIn.