TechEd 2008 Devs and Admins: Better Together or Better Apart?

In casual conversations with developers at last week’s TechEd Developers’ conference they’ve said that they like the separation of TechEd into two specialized weeks—one for developers and one for systems administrators and DBAs. However, their descriptions of their actual work-life show that development and deployment activities need to become far less siloed than they’ve been in the past. Because I'm working on a site we're about to relaunch,, with a mission to bridge the gap between developers and systems administrators, I’m passionate about improving the connections between these functional areas. What surprised me was that even before I could bring the topic up developers were saying things like, “My top issue is solving the communication problems between my development team and my operations team” or “In my development group the motto is ‘Don’t let IT take control of your box.’”

Sitting in the cavernous cafeteria where thousands of developers had just scarfed down scrambled eggs, fruit, and bacon a development manager with a government agency told me that her organization is migrating from Oracle to SQL Server. She’d like to see more interoperability and migration TechEd session topics. Her org uses Visual Studio Team Foundation Server, SQL Server, and SharePoint and her developers write a lot of ASP.NET code. She wears two hats—not only does she write code and manage coders, she also deploys and operates the applications her team creates. So she’s very interested in both developer and IT Pro issues, and reflected that there must be many more folks like her in mid-sized organizations who have to juggle development and systems administration. She wants better tools, better processes, and she’d like to see a clearer career path for folks who want to wear both the developer and the IT Pro hats. She’d also like more hands-on sessions at TechEd for technologists in small and mid-sized organizations with similar needs.

Later, I dodged a few conference center folks on Segways as I trekked over the wide blue carpet to the Wireless Café in search of a plug and a chair (found a plug, no luck with the chair—stood at a table clearly meant for taller types, plugged in the laptop, and began blogging). I started chatting with the developer next to me, sharing the surge-control strip, and we immediately got into a discussion about the need for tools to cut down the time wasted between the development and the hardware (or operations) shops. In his organization, there’s constant tension over who would take ownership of the machines. When the IT group owned the machines, the developers complained that patches and security updates broke their apps. When the devs owned their own machines, the systems ops folks feared for the security of the org and fretted about the sudden appearance of alpha apps that could break existing apps. As the chain gang captain said in Cool Hand Luke, “What we’ve got here is a failure to communicate.”

In other conversations with conference presenters and with a Microsoft RD (regional director—a kind of high-level MVP—an independent senior-level developer or architect focused on solutions) the experts talked about the importance of getting the word out about tools and initiatives from Microsoft (such as the Dynamic Systems Initiative and developing for operations) and from other vendors that can help bridge this gap. In addition to tools, better project management processes are needed, and clearer lines of communication need to be developed. Someone suggested that a new job function needs to be created that handles communications between departments that don’t understand each other’s processes. It was clear to me that the engineers I talked to had identified a problem and wanted to solve it. What about you? Does this situation sound familiar? What’s your worst IT/Dev nightmare? And how did you solve it? There’s a comments section right here. Go ahead and use it.

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.