Team Sports and Developers
Not usually two words you here go hand-in-hand but here I was thinking about this over the weekend and it brought up some past thoughts I had on the subject. It's always an interesting experience the first time you play a team sport with a co-worker, we've all been there and at the end of it the reactions usually range from it having been a great experience to you preferring to have a root canal done... twice... in the same day. Having thought about this a little over the weekend I got to thinking about every interview I've ever conducted where I asked a question related to teamwork, leadership, conflict, etc (you know the soft-skills, the skills that separate the transformers from the toaster ovens);
Do you enjoy working in teams or on your own? Oh both, yessir, I am definitely a team player but I am also happy to work on my own and get the job done. (They should post that answer on StockAnswers.com and rent it out).
Or
How would you resolve a conflict with a fellow co-worker or manager? Oh, well, let's be honest we wouldn't have any disagreements (wink, wink) BUT in the odd case that we would, I'd get everyone together and talk through it calmly and rationally so we can come to a win-win conclusion for everyone involved (again see StockAnswers.com).
Now let's re-phrase the two questions into some sports venacular;
If you are on my team, are you going to pass the ball or try and take it to the net on your own, every time, even when someone is open?
Or
When someone from the other team commits a penalty against you are the type to go nuts on that player argue to the nth degree with the referee, maybe seek some retribution? Or do you move on and keep playing?
Both sets of questions are pretty much the same, the only thing that changed was the context. You might think the adreline only comes into play in sports, but you'd be wrong - I've seen developers become possessive and highly argumentative about theirs and others code - true story.
It's very probable that the answers you would get to the above questions would be from StockAnswers.com, but maybe some die-hard players would start to open up a little bit (which is what we want);
- "Well if the opposing team is running my goalie, I'm going to get in their way and block them" - alright, willing to take one for the team and protect his group - leadership potential.
- "Well the ball went out on me and the ref called it the other way so I told him it was on me" - solid, honesty and respect for other teams in the organization.
- "I scored on our team once, but went out and kept trying" - READ: when I broke last night's build, it was my fault, so I stayed later to get it up and running so QA wouldn't be too far behind.
I wish it were that easy, I love both individual and team sports - I love seeing the transitions in personality in people I work with and when you step back to watch them you can totally see the similarities in how they approach their work, their style and ethics.
I am seriously looking forward to my next Interview because I'm thinking I'm going to hold it in a gym - play a little one-on-one, floor hockey, dodgeball, anything - if they get past that phase, I'll inject some technical questions near the end. At the very least, if the interview goes sideways I would have gotten some exercise and had a fun night at the gym.
BTW - We need more examples of sportsmanship like this - http://www.youtube.com/watch?v=NOMN__ozGSI
How to build a great Framework
Developers get delirious with excitement when you give them the task to build a new SDK or a framework - they immediately think of building something that will rival any and all frameworks that have come before them and that it will be so flexible it will be able to do things you have yet to think of. Think I'm exaggerating... go ahead... ask one of your Developers and watch their eyes light up. So if the desire to write a framework is met with such unbridled enthusiasm and ambition - why do the implementations for a number of SDKs suck and what makes a good framework? It really isn't complicated when you think about what you need to do.
Imagine you are the Consumer
When I start writing a framework that other developers are going to consume, the first thing I start writing is some pseudo code (a great combo of C#, JavaScript, maybe some XML or SQL, whatever) that I use to define the interface of how users will use the API. The goal here is to make accessing your work as efficient and logical as possible. I.e., do I really need 12 overloads on that 1 method? Will someone be able to connect the dots between initializing this member before calling this function to fire this event? If you can't logically walk the steps than how do you expect your users to? There is a great book out there called Framework Design Guidelines - it's all about some of the people that wrote the .NET framework - what they did right, what they did wrong. The book is 4 years old now, but it is such a great reference for accomplishing this sort of task. My favourite part is hearing from the guys who designed the System.IO namespace - when they put it in front of some skilled developers no one could figure out how to use it. It's an incredibly powerful namespace with much more functionality then its predecessors but the usability fell flat when put in front of its core audience.
Meaningful Responses
Alright - so you've got an API that's great to work with, users are getting it and then they hit an exception or error of some sort and what they get back is completely meaningless garbage that gives them no guidance as what they should try next. I love using "mature" .NET Interop wrappers that are specifically built to wrap around the complexity of COM components to make it easier for you to use only to give you some error that gives you an HRESULT to go with. What they couldn't intercept the message and write some code around what was going on internally? If you are lucky someone on the internet has encountered the same issue, if you are really, really lucky - that person has figured out what the error means, otherwise you're on your own to start down the road of trying to figure out what this error alludes to. I use COM Interop as an example, but there are many other examples - just the other night I was using the .NET Entity Framework against SQLCE4 and kept getting some "cannot open db" error. When I drilled down 6 levels in the inheritance chain I finally found that the error was in the password of my connection string. If this had of been bubbled up to the top of the stack I could have blissfully moved on (and saved myself some time). The point here is, you know why exceptions and failures are happening, so take the time to craft some informative messages to your user: Error - Impact - Suggestion. In the case of my EntityFramework example; "Cannot connect to the database, data will not be loaded, check your datasource or password in your connectionstring". Wordy? Maybe. Useful? Hell yeah.
Document thy Work
I don't want to read a 400 page novel on how to use your API - sometimes I do, but not 85% of the time. I just want to get up and running ASAP. .NET gives you the most simplistic tools to write comments - /// - that's it, type those 3 characters over any method, class, etc and it will give you the structure to work within. But do you do it? Really do you? But how much do you depend on it to help you in your daily programming? Recently I was working with this API that applies some metadata to files - it had NO documentation and NO comments. To top it all off it had great method signatures like GET, SET, DUMP, PEEK. A lot of my time was spent trying to determine which methods I should use in my task but had to aimlessly try different implementations. Something like - GET - Opens the file exclusively to access metadata, PEEK - Accesses the file's metadata without creating an exclusive lock - would have helped immensely. If you are writing external documents that your users need to read, add a reference to it in your code - what harm does that do? Here's a secret, beyond it's self-explanatory name, no one reads the "README" file until after they have hit an error, no one. So putting a comment into your code that says - "If you are trying to do this and are encountering errors, see the ReadMe file" is not going to ruin your framework.
Test Coverage
Over the last few weeks of 2011 I've been evaluating some logging frameworks for some applications that I have been working on. (I'll blog about my favourite one in my next post). When I installed some of these frameworks, I saw they had Unit Tests - great I thought, let's run these badboys and see what this baby can do. I was blown away when some where broken and didn't run. Here I was spending time validating unit tests when I wanted to be coding MY application. If the Unit Tests are broken, surely I must have done something wrong right? Not necessarily, in some cases there were some errors in the code - either through knowledge of known issues or lack of additional frameworks. If you are going to validate your framework against Unit Tests (YES PLEASE DO) then the onus is on you to make sure these things are rock solid against each and every release. If they are not and you make the call to not fix them (that's cool) do your users a favour and yank them. No harm no foul, I see no Unit Tests, I'm not going to try and run them (heck I won't even know they were broken). The last thing you want to do is give a guy a reason to not even look at your framework because your test suite broke before they even started writing code.
So here's the thing - developers can be lazy (not all, but we are a strong and proud number) and by having a simple API, with straightforward documentation with enhanced and useful response codes/messages that is well-tested and provides (PLEASE) a valid Unit Testing project you will be well on your way to getting your framework adopted by your developer community and getting the word out on what a great framework it is. Think of the last framework, third-party API, whatever you used - when it went great what was the first thing you said - "It was easy with component ABC" - that's what you want to happen, that's your end goal, always.
Where's the love for Unit Tests?
I've been involved in some discussions on Unit Testing with developers for the last couple of months - you know - should we do them, should we not, every feature should have its own set, we should tie them into builds, etc, etc. Unit Tests seem to be one of those lightening rod topics where if you ask someone whether we should do them everyone has an opinion and the line becomes clearly drawn in the sand.
But when the topic comes up all you have to do is look around the room to see everyone's responses... they don't even need to speak - everyone always say "yes we should... but we don't have time to do them". Even faced with the a benefit/loss analysis of reduced QA time and improved product quality people still waiver on whether they want to adopt a Unit Testing methodology (and that's a heavy word, really you create a test, you write some code, and wait for the results) this is still the stock answer.
So ergo we have more Time we would then get more Unit Testing which would lead to better quality, but the lack of time prevents the creation of Unit Testing (which could save time, could but we cannot say for sure). So if we had all the time in the world everyone would Unit Test? Sorry, the answer here is still a no.
After many years of witnessing this same old battle take place it finally dawned on me today in one of those Eureka moments of clarity. The time element that might be gained from Unit Testing is derived from the investment in time of a Developer building said test. However the time weight is different when applied to the resources that are benefiting from the now saved time to the people that are investing in developing the solution - in English - Developers are writing Unit Tests instead of building Product and QA is getting all the benefits but it is hard to measure they cost savings because there is always something to test (because let's be honest, QA always gets the shaft when the time crunch is on).
I could be wrong, I could be way off base, it might work different elsewheres in the world (and yes I hope it does), but when I think back to all the times I have had these discussions the answers have always been the same. So if this is the case then how do we push the creation of Unit Testing to get done in software? The only logical conclusion that I can come to is to have QA handle the creation of test cases themselves so the time investment quotient is weighted the same. While QA is building their tests they'd still be in some way testing the product (or working towards the testing of said product) and this might be viewed as more palatable towards stakeholders.
So that's my theory, I don't know if it would fly, I'd love to try it out since I know a lot more QA people are learning coding to do their jobs in working with automation tools and the like. There would probably still need to some developer time investment but this might be minimized as the bulk of the workload would be distributed between both groups.
What's the Big Diff between Juniors and Seniors Titles?
If you were to take a quick scan of the current job market you’d see many development positions prepended with the generic – Junior, Intermediate, Senior headers in front of them. Nowadays we are getting really fancy because we need to attract new MORE qualified people by using such terms as Guru, Expert, Ninja, Rockstar, etc, etc, etc.
Can you really look at these designators and apply them so broadly to a field that is still so young and so widely influenced by external factors?
Generalist vs Specialist
Developer A is a Java back-end developer; he understands database protocols and is well-skilled in database design (particularly Oracle). He has been working in this field for approximately 12 years. His work is solid; he understands what needs to be done and the gotchas to look out for; however his experience and knowledge is solely focussed on data and no other area.
Developer B is a .NET developer; she doesn’t really specialize in any certain area, has some well-applied experience in WPF, WCF and WF. She is not nearly as experienced as Developer A but she knows how the different parts of how a system works together and what caveats need to be in place for the different technologies to align.
So – who is the Junior and who is the Senior? If you go by total years of experience then you are essentially placing your bets based on performance in a single area vs a span of information across disciplines? (forget the fact one is Java and one is .NET, that serves no value in this discussion) Although I would not think Developer B to be at the level of experience of Developer A, they do have something going for them in that they understand multiple facets and protocols of development and programming which would lend them to working in multiple areas and understand the need to twist indexes and database return results to fit the needs to small networks and such.
Veteran vs Noob
So let’s say we still have Developer A and B in our scenario, Developer B has been with Company X for her entire career to date (5 years) and has worked with the company’s products since Day 1. Developer B has come on board to solve the company’s data issues; he’s got a lot of experience but knows little about the Products. In meetings, Developer A clearly has more influence with the rest of the project team because of what she has accomplished to date and her sound knowledge of the company’s products. While on the other side Developer B is struggling to get buy in for his ideas? However, Developer B’s suggestions are incorrect in some facets, primarily because she doesn’t have the required experience in that field to make the kind of decision that developer B can but she is regarded as being a more Senior developer because of her internal experience and product knowledge.
We have now crossed over to including Product knowledge and past successes into the definition of a Developer. Developer B has delivered some pretty solid product and knows the suite inside and out (which is good) and has built up credibility with her team to trust her decisions (again good). But now she has been put into the position to make technical decisions related to a technology area she does not understand and has not worked with. In essence she was promoted into a position where she was not qualified to enter but based on what she did for the company, it seemed like the right thing to do.
Whether we like it or not, Product/Company knowledge indirectly becomes key decision criteria in determining what level a developer is at. Sure we can peg them at Junior, Intermediate or Senior on Day 1. But after that, their stock starts to go up with every release that goes out the door (and these factors are quite complimentary). Have a good understanding of the product and you’ll know how to better code for a problem. Need to implement a new feature under the gun? Well you know the codebase so get to it and Ship It!
So in the end does it matter if we call people Junior, Intermediate or Senior? When you enter a new organization, in some ways you are really a junior once again, you might re-accelerate to Senior quickly but you still have to contend with the internal product experience already acquired by internal resources that have made them more than what they were when they signed on. And really, who is going to put a new Senior Developer on a mission critical outage on Day 1? No one (at least no one in their right mind who wants to see the bug actually get resolved), so in the end why not just call us what we are – Software Developers – those of different skills, capabilities and knowledge.
Now if you’ll excuse me I have to go get ready for a dentist appointment with my Senior Dental Hygienist and Junior Dentist (see doesn’t that sound dumb)?
Setting up Impersonation for the Exchange Web Services API in Exchange 2010
What is often seen as the most difficult pieces to get setup in using the Exchange Web Services SDK (or it's companion, the Managed API) is not so.
Impersonation is the means by which the account you are connecting to Exchange with to act as somebody else. What is beautitful about Impersonation is that this user does not even need to be an Exchange User or have their own mailbox. Nope they can be just a regular joe in Active Directory.
Setting up Impersonation can be done in two ways, both involve using Powershell. On a side-note - connecting to Powershell via a local account can create some very wierd experiences in access cmdlets, always log into Powershell as an authorized domain user.
Wide-Open
New-ManagementRoleAssignment -Name:MyImpersonationGroup -Role:ApplicationImpersonation -User:mydomain\exservice
The above code, creates a new ManagementRoleAssignment, aptly named "MyImpersonationGroup" which I add to the ApplicationImpersonation role and then grant rights to the mydomain\exservice user. At this point, I have enabled Impersonation, "mydomain\exservice" now has full-blown rights to go around and impersonate users. Now let's move on to limiting the user scope.
Limited Impersonation
Chances are you are not going to want to do what I did in the Wide-Open scenario but would rather control who our "Impersonator" can Impersonate. This is accomplished by creating a scope and assignming that scope to the Management Role Assignment cmdlet.
New-ManagementScope –Name:MyExchangeScope -RecipientRestrictionFilter {Title –Like “Developer”}
New-ManagementRoleAssignment -Name:impersonationAssignmentName -Role:ApplicationImpersonation -User:mydomain\exservice –CustomRecipientWriteScope:MyExchangeScope
So, the tricky thing about creating a Management Scope is determining the restriction filter. I don't have a complete list of all the names of Active Directory fields, but in this example what I have done is create a scope whereby anyone with the Title of Developer will be allowed to be impersonated. Next, when I create my Management Role Assignment I now append the additional flag "-CustomRecipientWriteScope" and drop in the name that I gave my ManagementScope in the first step.
Now I will caution you, not being an Active Directory expert, that I did notice a delay from when I published changes to users (i.e., changed their titles to "Developer") to when I could impersonate them in my code. I would think this is based on AD publishing its data on some kind of pre-defined schedule? I know OCS/Lync has this issue with Address book changes coming down to it if you have AD groups in your Lync contact list.
So that's it that's all, now that you have impersonation all setup and running, go forth and crank out that EWS Code.