Tuesday, July 22, 2008

Microsoft Source Analyzer (StyleCop) Extensions Controversy – Part Two

Copyright 2008-2009, Paul Jackson, all rights reserved

A couple weeks ago I got irritable because a blog posting on how to extend StyleCop for TFS TeamBuild had been removed “at Microsoft’s request”.  That posting got a bit of attention on dotNetKicks, quite surprising me. 

I was really pleased to see today that the redacted post that originally got my thong in bunch is now back and there’s an MSDN blog entry trying to clear up confusion around the whole issue.

Apparently the released name of the tool (Microsoft Source Analyzer – now Microsoft StyleCop) confused me a bit – in that, I assumed with a “Microsoft” prefix that it was an official offering with a project team and a budget.  Such seems to be not the case, and, according to that clarification blog, it’s actually the work of a single developer at Microsoft ("on evenings and weekends") – which makes it all the more impressive, in my opinion.  (If Jason Allor ever leaves Microsoft and shows up at your company for an interview, hire him.  StyleCop would be a phenomenal and well-designed if it had a team and a budget, for one guy in his spare time ... )

In addition, the StyleCop blog now announces an upcoming version which will include an SDK and documentation, making my own custom rules tutorial obsolete.  This is a good thing.

Another good thing is that I learned a new word from bharry's comments: "kerfufel".

kick it on DotNetKicks.com

Monday, July 7, 2008

Customer Requirements and Online Dating

Copyright 2008-2009, Paul Jackson, all rights reserved

A couple years ago, my wife and I decided to sign up for eHarmony.   You know, the Internet dating service with the patented, million-point matchmaking system?

Yes, we were already married.  No, we weren’t having trouble and needing to know what was out there.

It was kitten’s suggestion.  (I call my wife “kitten”, the reason for which I explain on my kayaking blog.)

Her theory was that we’d both sign up and see if eHarmony’s sophisticated algorithms would match us with each other.  “It’ll be fun,” she said.

Now, as soon as I heard the suggestion, I knew that there was no way this could end well.  This was an idea that, upon hearing, you just know is going to screw up your life somehow.  But kitten wanted to do it, so I agreed.  If I’d only known the true horror of what would come from this, I’d have hacked eHarmony and brought their servers to a grinding halt.

So kitten goes first, signs up, runs through all the questions and, at the end, out pops a list of hundreds, if not thousands, of compatible matches … which, for the low, low price of $49.95 a month, they’ll be happy to put her in contact with.

Then it’s my turn. 

I start filling out the questionnaire.  Question after question after question … it’s thorough as hell.  And I’m answering everything as honestly as I can.  I get to the end and ...

See, I'm not sure what would have been worse ... to get to the end and have more matches than her or less.  And what would have happened if we weren't in each other's matches?  I don't know what would be worse, because none of that's what happened.  Instead, I got a message from eHarmony. 

It was a nice message.  Politely, even cautiously, worded – with the sort of tone people use with mad dogs or, possibly, wild-eyed men running through the streets with firearms.   I don't have the exact words, but essentially it said:

We're sorry.  Very, very sorry, actually, but there's nothing we can do for you.  We have no one in our entire database who we'd even remotely consider subjecting to a date with you.  In fact, we won't even try to look anymore.

Keep your money.  Put your credit card away.  We don't want it.  Even if you insist, we still won't take your money -- there's simply nothing we can do for you.  Please consider applying the $49.95 per month to a good therapist.

Okay, so I made that last bit about the therapist up, but the rest is the gist of what they said.

That's right ... an online dating service refused to take my money.

For years now, I've been hearing about it from kitten: "You're lucky, because there's no one else who'd have you ... but me, I have options.  Hundreds of options.  Thousands, maybe.  You?  You got no options."

I can't even really argue with her.

What does this have to do with software development?

Well, eHarmony did something hard ... they told the customer "no".

They could have taken my money and matched me up with whatever hopeless, unmatchable women they let into the service to accommodate guys like me.  After all, eHarmony didn't know I was already married and just wanting to see what the list looked like ... from their perspective, I was a real customer, and what I wanted was to join a dating service, right?  They could have even told me "outlook looks bleak, but we'll try" and taken my money.

So as a customer, I told them what I wanted: to join a dating service.  And they told me "no". 

They told me "no", because they looked beyond what I said I wanted to what would really meet my underlying requirement -- joining the dating service isn't the requirement, it's what the customer thinks is the requirement.  The real requirement is to be meet someone compatible.  They looked at what the customer really needed and said "no, we can't do that".

If they went ahead and just did what the customer asked, let me join, despite my apparently unmatchable personality, I would have been a dissatisfied customer.  But their business-model is built on success-rates, not raw numbers, so they said, “no”. 

Telling the customer "no" is hard.  Whether as a consultant or as an employee where the customer is your business-user.  It's hard because that customer's paying the bills ... he's got the money ... and he's telling you exactly what he wants.  But what they want may not get them what they need ... and what they need may not be achievable.

One of the first projects I ever worked on was a program for the court clerk in traffic court.  As the judge heard cases, the clerk was to use the program to capture the outcome and sentence, then it would generate all the right paperwork.  The customer said they needed to see every option on screen at the same time.  All the controls to capture verdict, adjudication, probation, fines, jail time, community service ... everything had to be on the screen at once.  The customer said that's what they wanted.

Visual Basic 1.0 -- we quickly ran out of GDI handles, stooping to putting graphics containers on the form and drawing the static text in order to free up the handles from the labels.

We ran out of screen space -- this was when the typical resolution was 640x480, but $500 ATI graphics cards got us up to 1024x768 and solved that problem.

The user's couldn't see the small controls at that resolution, too small.  $1500, 17" NEC monitors solved  that one for us.

Clerk of Courts, remember -- it's a government contract so money is no object.

And the customer got what they asked for.  They hated it.  That user-interface sucked.

Then we went to write a similar application for criminal court.  How'd we get that contract when the traffic app sucked?  It's local politics, you don't want to know the things the owner of that company did to keep their business.

So we meet with the criminal clerks to find out their requirements, and what do you think they want?  One of the first things they say is, "everything has to be right there on the screen all the time."

This time we said, "no."  This time we asked, "why?"

Turns out, it wasn't about the user being able to see everything at once, it was about speed.  They had to get to things fast enough to keep up with the judge speaking.  Being able to get to things quickly enough was the real requirement, not having everything visible at once.  They weren’t giving us the requirement when they said “everything on screen at once”, they were giving us the technical solution.

The real requirement was one we could meet in other ways, and the criminal application was much better and more usable than the traffic app.

The first time around, we did what the customer told us they wanted -- we let the customer drive the technical solution, instead of having them articulate the problem and then presenting them with a solution.

I've always been glad that I encountered that early in my career, because I've seen the same sort of “requirement” over and over again and that lesson has always served as a reminder to look beyond the customer’s statements – and tell the customer that we aren’t going to do it that way.

As software developers, we should be prepared to analyze every requirement under the microscope of “why”, get to the real, underlying need that the customer has, and present them with a technical solution that meets their real needs.

We also need to manage their expectations – just like eHarmony does.

I recently joined a project and I find myself saying something quite often in response to the customer’s requirements: “Instantaneous is not a service-level agreement.”

Some of the customers have an unrealistic expectations – as unrealistic, apparently, as my finding someone other than kitten who’ll put up with me.

If I don’t manage that expectation and tell them, “no, you will not get an ‘instantaneous’ response to your request, it will actually take some time”, then they’ll be dissatisfied with the result and the project will have failed. 

It’s hard and they don’t like it, but we have to remember to do it.

Today, a customer asked us to change the key that moves the focus from field-to-field in a Windows application from Tab to the semi-colon (;).  I’ll be telling them “no”.

Thursday, July 3, 2008

Come On, Microsoft, Isn’t This a Little Ridiculous?

Copyright 2008-2009, Paul Jackson, all rights reserved

Update July 22, 2008: There've been some clarification and updates that make this a non-issue.

I started this blog last month with a series of posts on Microsoft Source Analyzer, or StyleCop, a new product released on Code Gallery and which can best be described as fxCop for source code.  Where fxCop works on the compiled binary, StyleCop works on the source code itself.  Since we’re currently reviewing our coding standards here, I jumped on this product because checking source code for naming, spacing, etc. standards is a royal pain.

The first thing I ran into was a conflict between our standards and those that ship with StyleCop.  We require an underscore start the name of private fields.  So, assuming that StyleCop was extensible, as fxCop is, I did a quick Google for “customizing stylecop rules” and found nothing.  So I did a little digging (with Reflector) in the public interface of MSA and figured out how to do it.  Since the information wasn’t already out there, I figured I now had something to contribute to the community other than long-winded discourse on the need to learn how do do Manycore programming well.  And to let people know about it, I responded to posts in the StyleCop forum about custom rules.

In response, I caught some crap from the Microsoft team about violating the license agreement by using Reflector.  A few of my posts were deleted.  The community argued the whole license issue, because there are two license agreements involved – the Code Gallery one that pops up when you download and the StyleCop-version when you install.  I don’t think anyone had a reasonable expectation when installing the product that these would be different. 

In any case, the whole discussion about licensing disappeared from the forum and no more was said about it.

Then today I see this thread in the forum.

Apparently, someone wanted to integrate StyleCop with the Team Foundation Server build process.  So he did a little digging with Reflector, figured out how to do it, and blogged about it.  Then he responded to a forum query on how do this.  Sound familiar?

Where his story differs from mine, is that he apparently had more communication with Microsoft than I did.  His blog entry now reads only:

“This MSBuild task has been removed per request by Microsoft.”

Hey, Redmond!  What were you thinking?

You released this product to a community of people interested in how technology works … customization and integration with other tools are critical to our work process … how could you not know we’d try to figure it out and make it work for us?

Yeah, maybe these things will start breaking with a future version of StyleCop, but the community wants them now.  We’re not idiots, we know that if the API changes our stuff will break … that’s a risk we’re willing to take because we want the functionality now.  We want to use the product now because it’s useful to us, but not without these features.  Fine, you didn’t have time to provide them in this release … let us do it!  That’s what “community” is about.

Or are you seriously suggesting that our use of Reflector somehow endangers your intellectual property.  Gentlemen, if it’s truly that important to you, then I submit to you that .Net was the wrong environment to write it in. 

There are a lot of smart people out here who are willing to take your work, build on it the things you didn’t have time to, and make your products more useful and better.  By making things like custom rules and MSBuild tasks available now, StyleCop becomes more beneficial to more people … people who, without those things, would shrug and say, “Nice idea, but it doesn’t do what I need”, and delete the whole damn thing.


kick it on DotNetKicks.com