Are you a 'dual'?

Last month at Tech-Ed, I was discussing with someone from the Solution Accelerators team about how I wished that Microsoft would produce some administration documentation for developers, and/or developer documentation for administrators, so that the two groups would be able to talk the same language.

[As a f'rinstance, back in the days of Windows 2000 and before, if you were a developer writing code to log a user on to the system and run a process (say, for instance, in your spiffy little FTP server), you would face an error if your code wasn't running in the context of an account with SE_TCB_NAME privilege.

But you couldn't tell an administrator to enable the SE_TCB_NAME privilege on the application's account, because he'd have no idea what you mean.

To an administrator, that privilege is called "Act as part of the operating system".]

"Well," said my conversational partner, "That's because you're a jewel."

"That's awfully nice of you to say, you're somewhat of a gem yourself."

"No, not 'jewel', a 'dual' - you span the two worlds of IT Pros and Developers."

He went on to explain that there are few duals, and that this was why there were few resources that address the disparity between what is developed, and what is administered.

A lot of the examples I came up with (e.g. the name LUA versus UAC) were rooted in the history of development - where Microsoft's naming police have chosen a name that they felt was "catchier", "more marketable", or simply "not offensive to <some-group>", as a replacement for an internal name. Changing the internal name in APIs that have already gone through beta testing is not generally possible, so the developer name stays as the old name, and the administrative interface is changed to present the new, marketing- and legal-friendly name or image.

Are you a dual? What are some of your challenges in communicating across the boundaries between two worlds?

Published Wednesday, August 29, 2007 9:08 PM by Alun Jones

Comments

# re: Are you a 'dual'?

I've been a dyed-in-the-wool infrastructure geek for 11 years, and I'd tried in vain to bridge the gap to Developer-land for most of those years.  

This is partly because I'd constantly run into troubleshooting issues that took me to the API layer and below, but I wasn't able to "go the last mile".  

It's also partly because, at least while working at Microsoft, I got the distinct impression that "if you don't do code, you ain't worth squat".  Infrastructure geeks, no matter how knowledgeable, were always second-class citizens at MS.  

I've often dipped my toes in the water of providing guidance to the developers on whom the infrastructure folks depend for (a) leveraging the security infrastructure that the systems folks worked so hard to put in place, and (b) not creating wide-open holes into the infrastructure through holes in their code.  I've found it difficult to explain to many developers why they should bother integrating with AD, using Windows-integrated authentication (or even LDAP, for g##'s sake), why their app might fail on a locked-down server.  I've also had just as hard a time teasing out of these developers things like what privileges & permissions are required for their app to run, in which DLLs certain functions are stored, and all of that other "plumbing"-related minutia.  

I finally made the leap, and am developing code in C#, VB.NET, XSLT and Javascript, and I feel like I'm almost "qualified" to create good code.   [Maybe one of the barriers to "becoming" a developer was the very realization that I didn't want to repeat the mistakes and problems that all the dev's with whom I've worked had created, and on whose mess I've often had to bolt security after the fact.]  

I've found Keith Brown's books to be the most lucid explanation of security concepts that works for both Infrastructure and Developer crowds, but maybe because of that, his books don't sell that well. :(  Still, I can't recommend them too strongly.

Tuesday, September 04, 2007 4:38 PM by Mike Smith-Lonergan

Leave a Comment

(required) 
(required) 
(optional)
(required)