Securing Developer Workstations

Before I let this threat RIP, I would like to share an observation.

Much of what I posted focused on counter arguments (and solutions) to tightly locking down developer workstations.  To a great extent, I fell into the “solutionizing” trap. Perhaps this is what AncyC was trying to tell me

I should have spent equal or greater effort on the case for WHY I believe change is needed, e.g.  (hastily compiled – not well thought out at this point):

1) Change happens, especially in technology fields like software development. Sometimes that change is thrust upon us by customers or business partners. Developers must be able to research new tools, technologies, and techniques - even ones that may go nowhere and that would never pass a formal review/approval. Much is learned during the journey, even when/if it does not lead you to the desired destination.

2) “If the only tool you have is a hammer, it is tempting to treat everything as if it were a nail.” Often the difference between timely success and complete failure is applying just the right tool. Developers must be able to bring various, sometimes new and different, tools to bear.

3) There is no substitute for tried and true tools. In an environment requiring timely resolution of issues across widely varying technologies, it is counterproductive to strictly limit every developer to the tools preferred/selected by… who ever made the selection.

** Note: Our development team provides significant production support across many varied technologies involving clients and business partners whose technology selections we have little ability to influence.

Thanks again everyone. The discussions here helped my immeasurably.

Before allowing this thread to die I thought I’d provide an update. All developers were granted local administrator privileges.

This is more than I sought; the “Least-Privileged Account” idea seems more prudent. Aside from advising management, I played little role in the resolution. It turns out that corporate policy is for developers to have local administrator privileges. It was our site’s Infrastructure team that was not following standards.

It seems worth noting that, thanks to you contributing 9ers, I caught my “solutionizing” mistake. I refocused my efforts and argument on the Why instead of the How:

1) Change happens, especially in technology fields like software development. Developers must be able to research new tools, technologies, and techniques - even ones that may go nowhere and that would never pass a formal review/approval. Much is often learned during the journey, even when/if it does not lead you to the desired destination.

2) “If the only tool you have is a hammer, it is tempting to treat everything as if it were a nail.” Often the only difference between timely success and complete failure is applying just the right tool. Developers must be able to bring various, sometimes new and different, tools to bear.

3) Software craftsmen must have many tools in their toolbox, including their tried and true, trustworthy tools.

**Note: For better or for worse, our shop is hyper customer pleasing. We are forced to rapidly adapt to our clients needs – and technologies. It’s how our business is presently structured. We could argue the merits of this approach but it doesn’t change today’s reality.

Thanks again everyone for your help!