Editor’s Note: I Am The Business

Posted by james on October 12, 2011 Leave a comment (0) Go to comments

Here is the same content in en-us.

I’m writing this month’s editor’s note while at an open spaces conference in Austin, Texas. You may remember the same conference last year that kicked off a firestorm in the blogosphere. Many of the participants from that conference, which was called ALT .NET, have returned to Austin this year to talk about continuous improvement in software development.Unlike last year, where the focus was on sharing techniques related to design and code, this year’s meeting is focused on the methods and philosophies behind measuring and managing development projects. There is quite a bit of interest in incorporating ideas and methods from other disciplines, such as manufacturing and engineering, and there is a growing interest in trying to understand development efforts from a business perspective. I’ve heard terms like ROI used here so often, I had to walk outside and double-check the sign to make sure I was at the right conference.While all of this discussion is beneficial for us as a community, what has been most meaningful for me is the realization of just how dramatically my own perspectives have changed. A year ago, I remember lamenting the fact that my day-to-day job seemed to be moving farther away from the technology—away from everything with which I had experience and confidence, and away from the people with whom I shared so many common stories and frustrations.However, as I sat in the back of the room last night listening to the discussion about techniques, successes, and frustrations related to the friction between developers and the business, I realized something for the first time: I am the business. And I’m OK with that.You may be surprised that it took me a year to come to such a simple conclusion, but it’s hard to let go of such a large component of one’s identity. In my job with MSDN Magazine, I have two main priorities: strategy and management (both budget and people). Part of our strategy includes software development projects, to be used internally and externally. And those projects are usually funded out of my budget—so from my perspective, characteristics like maintainability are not end goals worthy of funding. This is not to say that maintainability is never worth funding—just that it has to be driven by larger, more measurable business goals. Speaking of maintainability, when thinking of such good practices, my sense is that we tend to elevate them to the level of end goals because we understand the problems they solve, and we are not nearly as comfortable with the overall business context. Therefore, when we don’t understand the nature of the business that our software will support, our natural tendency is to generalize the business and focus on the non-functional “goodness” of the system. This creates an immediate break between the development group and the business that the software is supposed to be helping, and it ultimately leads to the failure of so many projects.The simple fact that developers are meeting to talk about things such as ROI is a great step to start addressing this pattern. I also think there are some creative methods that can be adapted from other industries and applied to software projects. For example, I’m considering having my developers actually do the job of my users in lieu of a formal “requirements interview.” This may help to avoid some assumption-making in the requirements-gathering process.In the end, I think it takes both successful projects and failures to mature as a profession. That said, I’m grateful that there are developers thinking proactively about moving us along with more wins than losses.

Thanks to the following Microsoft technical experts for their help with this issue: Mukundan Agaram, Spotty Bowles, Paul Despe, Elisa Flasko, Buck Hodges, Bryce Jonasson, Irena Kennedy, Ravi Krishnamurthy, Sesha Mani, Beth Massi, Dwayne Need, Michael Puleio, Karl Reinsch, Gerhard Schneider, Cliff Simpkins, and Don Smith.