March 2009

Volume 24 Number 03

Editor's Note - Growing Pains

By Howard Dierking | March 2009


I had planned to use this month's editor's note to talk about the work that has been done transforming the Web into a rich application development platform. Naturally, I would have mentioned the great articles we have in this issue, which cover topics from development with Internet Explorer 8 to Silverlight 2 and SharePoint best practices. I would have pontificated on the relative merits and potential ramifications of Web-based applications. I might have even thrown in a light-hearted story about the good-ol' days of writing Web applications in Perl.

Right now, however, we are living through some tumultuous times, and to not pause and recognize this—and more importantly, to evaluate how we can be a better resource during these times—is to pretend that everything is "business as usual" and does you a disservice. So I'll introduce this issue with a few thoughts on our profession with respect to the current economic climate.

I've heard many times about the stock market that it is a good time to buy when everyone else is selling. Extending this analogy to the present day, I believe that many will react to economic conditions by building a case to justify their role as critical, and how any change could have cataclysmic ramifications to the business. This seems at best isolating, and in the worst case it means that evaluations are always conducted from the perspective of how much pain would result in not having that role as opposed to how much good that role can provide—and more importantly, what that role can evolve into.

Instead, I propose that we even more ambitiously recast ourselves as a strategic partner to the business—not because we want to be seen as a critical path, but because we generally want to have a stake in the success of the business. I imagine that you've heard words similar to this more times than you can count—and they were probably followed with creative new strategies for "better" requirements capture. Instead of yet another methodology, I propose that we more simply seek to become the business (see my December 2008 Editor's Note "I Am the Business").

So what does this mean practically? I think that part of the problem with many development organizations today is that the development shop operates under the assumption that its deliverables exist to support business stakeholders. While the stakeholders are crucial in validating your understanding of the business, I believe that this assumption is fundamentally flawed, and is a core predicate for the kinds of behaviors that lead to tension between IT and the business. Instead, I submit that development teams create software to support the business. When this becomes the priority, it means that you should be able to explain how each requirement in your project supports a discrete set of measureable goals that the business is driving toward. When you understand the drivers that make the business succeed (not just the tactics), you will be able to successfully support the business as well as drive the evolution of a development organization that helps to lead the business.

So what can MSDN Magazine do to help here? First, we will increasingly raise the bar on producing content that goes deeply into not only questions of how a technology works, but also into why and in what contexts it is most useful—and this will apply whether we're talking about the Web or Microsoft Azure. Even in this economy, there are great opportunities out there—the question is simply whether we will move far enough out of our comfort zones to claim them.

Visit us at Questions, comments, or suggestions for MSDN Magazine? Send them to the editor:

Thanks to the following Microsoft technical experts for their help with this issue: Adrian Bateman, Sam Bent, Laurent Bugnion, Matt Ellis, Mike Fourie, Steve Fox, Don Funk, Alex Gorev, Aaron Hallberg, Luke Hoban , Robert Horvick, John Hrvatin, Bret Humphrey, Katy King, Brian Kretzler, Bertrand LeRoy, Dan Moseley, Stephen Powell, and Delian Tchoparinov.