Share via

Back from the FrontLine

  • Article

I returned to work this week from 4 weeks on the road (one week was vacation) and man I am glad to be back in sunny Redmond! I did this road-trip as part of a training class of sorts. The idea, as Josh says, is to get folks that are designing and building software at Microsoft out into the field to see how it is really used. Now, of course, this is far from a scientific data gathering exercise (Microsoft has access to plenty of “market research”), this experience was about getting visceral, tangible pulse of our customers and the Microsoft employees that server them most directly.

So was it worth the 3 weeks of time away during at critical period where we are locking down Whidbey Beta2 and the WinFX CTP? Yes! I learned a ton… and have several ideas for how to improve the product going forward. I am sure things will sink in deeper as I continue to share my impressions with my co-works here in Redmond, but here is a summary view of what I have learned. Notice there is no earth shattering revelation here.. at some level or another none of this is new, but I definitely have a deeper more tangible appreciation for these points.

  1. Developers *LOVE* managed code.   I made a point to enquire about this history behind why a given project was written in managed code. Frequently the transition was lead by the line developers because they felt more productive in managed code and therefore happier. I also asked about transitioning back to unmanaged code… many developers were adamant that they’d never go back. A manager even confessed that he was careful who he let work on managed code because he knew they would not want to go back and work on their unmanaged clients!
  2. Heterogeneous environment dominate.   Working inside Microsoft for the last 7+ years can spoil you into believing that companies have an endless supply Windows clients, Office, Exchange, Sql, IIS, .NET Framework, Windows Server, and SharePoint. All of the companies I went to had heterogeneous environments and many of the PSS cases I dealt did as well. As evidence of this, at one company providing the .NET version of their SDK was 3rd in priority compared to our competition. If we are going to make customers successful on our platform we should embrace that. Web Services seems to be working and the 3rd party and open source tools for .NET are very popular, but I think we can do even better.
  3. Customer solutions encompass a wide range of technologies. I am a huge believer in dogfood – I personally develop with our product almost everyday, I constantly exhort follow PMs to build “real-world” apps to help us validate the platform. But I gotta say, I now have a new definition of “real-world”. Nearly every project I was able to hear about leverages a WIDE range of MS and 3rd party technology. As a testament to that, the follow-ups I am doing now on significant questions\issues touches no less than 5 divisions within Microsoft! I think the take away here will be around “integrated innovation”… Microsoft has to make sure our products work very well together and with 3rd parties, because that IS how they will be used.
  4. The Community Rocks! I went to 5 user group meetings and 4 different “geek” dinners during the trip. I am blown away by the passion, activity and depth of the .NET Community. I believe this community is the single biggest developer asset Microsoft has. Not only do they do a great job of helping each other with technical issues they are also super valuable winning new projects to the .NET side. If you are not involved with a local user’s group, check it out!
  5. The End-To-End development cycle is what maters.   Generally I spend a lot of my day thinking about how to make developers more productive while writing code and frankly by all accounts we have delivered very well on that. Don’t get me wrong, there are still some areas to improve and some mistakes we made, but overall customers are happy. Where customers have more issues is around the build and test process, app deployment, management, and versioning. As an example, I was really surprised that nearly every team I talked to is using two build systems, one in VS on the devs desktop and NAnt for their nightly build. As you can imagine it is a maintenance issue to have two build systems. What is worse is that each team had to discover by trail and error that getting VS to work on a “build machine” was not wise. In addition customers still struggle with managing different deployments for dev, test and release servers. VSTS, MSBuild, VS Web Developer go a long way, but there is more we can do here
  6. We are not that unique. I have been designing class libraries for the .NET Framework for a LONG time and I had assumed that this was a fairly niche skill that is really only interesting for large platform vendors. But nearly every group I visited with is, in one way or another, building a library for some “3rd party” to consume. In some cases those 3rd parries are external developers and in others they are regional MIS departments customizing internal solutions. In addition many of the developers I talked to were very interested in Microsoft’s internal development processes. After I explained parts of them briefly it was clear there was lots of synergy with what they are doing. We need to do a better job publishing our practices so the rest of the community can benefit (and we can benefit for the communities comments).
  7. Microsoft has an excellent asset in our field. I got to spend a fair amount of time with our Product Support Services, Microsoft Consulting Services and Developer Evangelists and I was very impressed with both the breadth of their knowledge on MS products and more importantly their depth of understanding our customers. Clearly we could be using the institutional knowledgeable built up in the field better in the design of our products. If you are in the field and have ideas for how you’d like to engage better let me know!

Comments