Skip navigation

Bridging the Developer/Admin Gap

Bridging the Developer/Admin Gap

Way back in late 2002, I toured the country with Mark Minasi as part of a Microsoft-sponsored security road show. It was a blast for a number of reasons, but one of the more interesting things we did, but couldn't discuss at the time, involved a side-trip to the Microsoft campus. There, we got a very early preview of Monad, which went on to become Windows PowerShell. We were told that Monad was a way for Microsoft to bridge the gap between the command prompt/Windows Scripting Host environments then offered in Windows with the BASH-type shells common in Linux/UNIX. "UNIX has been kicking our butts within the scripting world," we were told.

OK, I thought, but so what? The reason Windows had become so popular in the server realm as well as on the desktop was the GUI: In fact, early versions of Windows NT Server were specifically designed to let Windows end users become Windows IT pros and admins, thanks to the familiar GUI. Where UNIX and Linux were inherently command line systems with a GUI on top, Windows was designed the other way around. So while there were (and still are) some things you can do from the command line in UNIX that aren't possible with a GUI, the reverse has historically been true for Windows.

Monad--excuse me, PowerShell--seeks to change that. And in the years since its first release, many newer Microsoft technologies have been developed like UNIX tools, where the underlying capabilities are in fact PowerShell-based, and the GUI is simply a front-end to PowerShell. This type of design makes the most sense in products where automation is not just desirable but necessary, a key example being Exchange Server.

But the problem with PowerShell is that it's so powerful as to be indecipherable to admins. In fact, it's arguably a full-blown development environment. It consists of a command line shell, a .NET-based, object-oriented scripting language, and a runtime engine that can optionally be embedded in other applications. For the typical overworked admin or IT pro, PowerShell might be a godsend if they could actually use it. But I was of the mind in 2002--as I am today--that most admins and IT pros have a completely different set of skills and are overworked as it is. To really take advantage of PowerShell, you need to be a developer or learn those skills too. And finding people who have credible administrative and developer skills is quite a trick. If you are such a person, maybe it's time to ask for a raise.

Technically, of course, PowerShell is excellent, but that's like saying a Porsche 911 GT3 is a great commuter car. It could be ... assuming you knew what you were doing.

Microsoft can't stop making solutions like this because, at its heart, Microsoft is a developer-run company. And this isn't just because it got its start making and selling developer tools. Microsoft has always seen the world through developer-colored glasses, and is always willing to tackle even the simplest of problems with complete, extensible, and finely documented platforms. It's just in their DNA.

And now they're at it again. Last week, at the annual VSLive show, Microsoft announced a new version of its Visual Studio development tools aimed at--you guessed it--admins and IT pros. Dubbed Visual Studio LightSwitch, this product aims to provide the simplest way yet to build business applications for both the cloud (using an Azure backend) and the Windows desktop.

LightSwitch isn't available yet--the first beta is expected late this month--so I can only go off what Microsoft has publicly demonstrated so far. What I've seen reminds me of the video game "construction set"-type products that were popular a while back. You basically piece together forms from templates and bind them to back-end data The question is going to be how powerful this is on its own, and when actually code will be required. If it's too code-heavy, you're in PowerShell territory: Useful, yes, but too much for the average admin.

I'll reserve judgment on LightSwitch until I've seen it in action, but the only surprising thing about it, really, is that we were surprised by it. This is exactly the type of tool Microsoft loves to make, and while I give them credit for trying to expand the capabilities available to admins, I'm not sold on whether such a tool can ever really work well in the real world.

An edited version of this article appeared in the August 10, 2010 issue of Windows IT Pro UPDATE. --Paul

Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.