Thursday, May 15, 2003

DevelopMentor Internal "Run as Non-Admin" Debate

I've used my brand-spanking new content creation system to post an article here. Here's what it's about:

One of the great things about working at DevelopMentor is access to the internal mailing lists. Being able to send a message off to that particular group of smart people has helped me more than once.

As you might expect, instructors at DM are not just bright people, but highly opinionated. So in addition to just answering each other's questions on the internal lists, we also frequently (continuously might be more accurate, actually) debate the merits of issues both technological and social.

One recent debate revolved around whether or not developers should run as administrator. This is something that Keith Brown has been advocating. Since there's been a lot of public discussion around this issue lately on mailing lists and weblogs, I thought it would be interesting to post the discussion here, publicly, to both show people both sides of the argument and to give them a glimpse into the inside of DM.


  1. I'm awfully disappointed by some of the reasoning I saw in this article. I saw a lot of FUD and "if it ain't broke, don't fix it" reasoning. I saw people complaining about a productivity hit you incur - I've been developing as a non-Admin for weeks now with no appreciable productivity loss.

    Yes, running as a non-admin user will not catch every single bug. But one must remember that the cost of fixing a bug escalates after it leaves the developer's machine, so why not go ahead and use this as a tool to catch permission-related bugs *before* they become bugs? You'll be amazed at how many things the framework automagically stuffs into restricted sections of the registry on your behalf. If you didn't develop/debug as a non-admin, you could easily tear your hair out trying to repro a problem a user is seeing when it's related to oh, say, and event log source being registered when the EventLog class can't find it.

    Yes, security is not a feature most people think to request. So, gee, if they don't ask for it, let's just ignore it. That sounds like the reasoning Microsoft was using until recently, and look at how much money is being spent to catch up. Sure, DM is a consulting firm, so one could make the short-sighted statement that "if it's not in the statement of work, it doesn't get worked on." That's the kind of attitude that gives consultants a bad name. Sure, if you pay attention to security, the client may not notice. But if you don't, they probably will.

  2. To me the debate over running as non-admin reminds me very much of John Cage and 4'33". The first time it was done it was a mind-bending statement that opened your mind to a new way of thinking about music and sound. Yet it wasn't something that could be emulated or continued any further. In a sense, running as non-admin is something all developers should try for at least some time just to open your mind to that other world. But continuing productivity shouldn't be sacrificed to make this point. If you need to thoroughly test your application in a non-admin world then make sure you have VMWare ro Virtual PC running an OS without those privileges and run unit tests against that environment regularly to ensure you are abiding by the necessary regulations and your application performs adequately. But to state that developers need to always run as non-admin is to state the John Cage started a movement that should be done at every performance. The point was made with one simple performance... now move-on with your newfound knowledge.

  3. Agree - and I don't think anyone was saying, "Everyone *should* always run as admin." A few of us said, "Everyone *can* always run as admin" since in our experience most things work reasonably well and the workarounds are easy. My point was exactly yours: everyone should try it at least for a little while, then decide what's best for them.

  4. Good to see that this discussion is at least taking place. I've documented some things that I went through to develop and debug ASP.NET apps using VS.NET 2003 at