Field NotesTalk to Your Developers
Jonathan is a developer. He builds software. He builds great software. Well, it’s great when run on his machine. But when he loads it onto another machine, something happens. Suddenly, someone’s saying the software is not so great. The administrators want it to do things and wonder why it doesn’t. Then they want to fix it and make it work. Then they complain that they cannot fix it because they cannot understand why it doesn’t work. That, they tell Jonathan, is his fault.
Now don’t get me wrong, Jonathan likes to be helpful. So helpful that he doesn’t mind taking the time to explain what the XML-encoded stack trace means or how to spot that the tracking GUID is missing and how to fix it. But for some reason administrators look at him as if he were speaking another language.
Strange, but developers see software differently from administrators. Developers work with code, traces, XML configuration files, GUIDs and assemblies. Administrators work with scripts and Microsoft® Management Console (MMC) snap-ins (at least they’d like to).
In fact, let’s take a step back. It seems to me some days that the whole software development process is broken. We spend lots and lots of resources figuring out what the end user wants. We build prototypes, conduct usability studies, interviews, and whatever else, yet when it comes to providing a simple, consistent management experience, we fall short. We fall very short.
I used to think that Xcopy, Regedit and Notepad were the best ways to install software. Now I know it’s a Microsoft Installer (MSI) that can be customized, installed, and uninstalled. I know that expecting an administrator to configure a Web service using Notepad to edit XML is probably not the brightest idea, and an MMC snap-in (or a Windows PowerShell™ script) is by far a better choice. I know that a stack trace is not helpful to a user or administrator in conveying the root cause and possible solutions to a problem, and that a well-written event to the application logs is better. I know that in order to build software that can be managed and operated by administrators, I need to treat them as users.
With an administrator as a user, I can define use cases, build prototypes, conduct usability studies, and so forth. This will enable me to provide the best possible experience for administrators. In other words, it will help them install, configure, monitor, troubleshoot, and fix my software without having to call me. If I use the management capabilities built into the operating system that they are familiar with, I can significantly lower the cost of running my application (fewer problem escalations), improve customer satisfaction (the application is down less often and they can fix problems quickly), and increase the chances they will buy more of my software and not yours (resulting in a sweet boat in the Caribbean).
OK, the boat is a dream. But getting developers to build more manageable applications isn’t merely a dream, it’s an achievable goal. And you can help too. Next time something goes wrong, don’t just forward the e-mail message and call them names under your breath. Instead, suggest that they write an event to the application log or provide a performance counter or some other indication of the problem. Even better, suggest a possible cause and resolution. Ask them to build you a Windows PowerShell script or MMC console to configure the application. The thing is, developers don’t always know you exist, let alone what your needs are. Tell them.David Aiken is an Architect Evangelist working for Windows Server Evangelism at Microsoft. His role is to promote and evangelize the Dynamic’s System Initiative (DSI) with an emphasis on Designing Applications for Operations.
© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited