About The Blog
Contributors from the Microsoft patterns & practics team find a place to spread the gospel.
NOTE: This site includes comments from Microsoft employees, but does NOT represent the opinions of Microsoft. It is merely a bunch of guys who love technology and want to chat about it in an open forum.
Wednesday, December 17, 2003
THE WEEK BEFORE CHRISTMAS
'Twas the week before Christmas, when all through Bldg 5
The PAG team was cranking and the halls were alive;
The big grids were hung by the stairwell with care,
In anticipation of new patterns that would soon be there.
And our devs were coding something far better than javabeans,
For it was visions of app blocks that were dancing on their screens;
I was in my office, thinking of unique new plans
To spread the p&p gospel to our hungry .NET fans.
When out near the atrium there arose such a clatter,
I sprang from the office to see what was the matter.
What I saw before me hardly qualified as breaking news
The usual suspects were embroiled in a heated game of foos.
I worked my way into the game and proceeded to kick some major butt
My lethal defense & quick reflexes knocked my out of my 5pm rut.
Sure, there was work to do and I couldn't let down the team
But it can get demanding here and it helps to vent a little steam.
You see, in PAG, it's a thankless job taken on by a motley crew.
It's a team effort to change the world and we all deserve our due.
So after a year of hard work, may my teammates get all they seek,
"MERRY CHRISTMAS TO ALL, AND TO ALL A GOOD WEEK!"
Wednesday, December 10, 2003
A couple weeks back, I blogged about the conversation that friend and I were having regarding CAS and whether it was a viable alternative for software developers nothing to create secure applications. I think one of the best parts of being an employee of Microsoft is having these engaging conversations. The differences of opinion make for great debates and interesting topics to write about in my blog. Another interesting topic recently arose with a different friend regarding the state of software development. This friend seems to believe that software development will move completely to India in the next three to four years. Eventually the U.S. will find no reason to cultivate the software coding talents and instead focus more on higher level tasks such as architecture and design. As a member of the Platform Architecture Guidance team that revels in seeing increased focus architectural knowledge, that should make me a happy camper. However as a nerd and a fan of good coding, this concerns me. Coding is an art and to see it commoditized breaks my heart and to see it completely leave the US would be a shame. Fortunately I don’t hold the same opinion. This whole situation reminds me of about fifteen years ago when Japan seemed to dominate the market for cars and electronics and their semiconductors were way ahead of us. I remember how others is ongoing fear that the Japanese people would eventually own the United States thanks to their superior high-tech prowess. I once told someone back in high school that my goal in life was work for company that brought the U.S. back to preeminence in engineering. Looking back to my three years of Intel and now on my third year Microsoft, I think I fulfilled that prophecy. While still talented, Japan is no longer the juggernaut that once. Now, a software development crisis has occurred where India (and to a lesser extent Russia and other countries) seems to have taken quite a bit of work away from the United States. Companies are finding it much more cost effective to outsource coding to these nations where the quality is solid and the costs is far far cheaper. So, is software coding terminal? Are the days of pulling up VS, cracking open a Mountain Dew, and going to town over? I really don’t think so I think these trends tend to normalize. I believe that many companies are not inclined to trust the overseas results completely in addition to the U.S. is always gonna be strong about trying to protect jobs internally especially ones that are typically high pay. You may recall several years ago that they had a "made in USA" campaign that was built strictly around trying to leverage American product into buying products made domestically. You could make an argument ten years ago or fifteen years ago about random stuff and how everything was going to be built in China and Taiwan. Things are still being built there, but at the end of the day the U.S. still manufactures quite a bit of junk. I don’t expect software to be any different. Any company that believes that their IT assets are strategic should not risk them to external vendors. That’s why the financial institutions are where they are--they invest heavily in IT capital including human resources. The best companies are the ones that don’t chance it. Heck, that kept Oracle and Sun in business for several years with high-priced software and hardware packages. Plus, don't expect India to stay in the lower marging software development areas when there are more lucrative areas to attach. Going back to the Japanese analogy, they are no longer all about cars w/ 50 MPG. Instead, they are Lexus and Acura. They moved up the stack and so will India. And yet, Detroit is still making cars. It's all part of the ever-globalizing world of business we live in. We just need to make sure we don't just dump something like software overboard as a result of assuming one country can usurp an entire function. My $.02 and I owe you a penny...
Wednesday, December 03, 2003
I don't normally give that much time to the application blocks in this blog, but I am a fan--less of what they are now and more of what I think they could be in the future. In the days of COM & DCOM, the programming stack consisted of the (a) kernel, (b) the Win 32 API, and (c) the Microsoft Foundation Classes (MFC). My ideal stack of the future would be the (a) kernel, the (b) .NET Fx (CLR + Framework classes), and (c) PAG deliverables.
The Win 32 API allowed access to fundamental functionality of the OS as well as access to entire feature set of Windows. Want to open a window, play a tune, or capture a mouse-click? The Win 32 API was there for you. MFC was the layer on top that made it easier for users to take advantage of those APIs as well as the C/C++ languages in general. It contained classes that were no more/less complex than our blocks, including my favorite, CString, that took the pain and likely errors of character manipulation out of programming. The proud dev probably thought he was above using that, but I loved that it saved me time. Could I have written CString myself? Absolutely. But why? MS did it for me! Just like creating ActiveX controls. You could either use the ATL (yikes) or whip something up in 30 seconds flat with the MFC AppWizard and then start building my business logic on top of it. Now, the latter probably included some functionality I didn’t need, but who cares—I was off and running. Some people like to go to a tailor, go though painstaking measures to get fitted for a custom suit, and spend countless hours and dollars to get the perfect look. Others know they are a 42 Regular, tweak a little bit on the cuffs, and go. How perfect do you want it? I personally don’t have the time or the $$ to get fitted perfectly for suits and I think most devs are short on time and $$ as well. However, the multiple levels of abstractions is great news for consumers…
Now, with the .NET Fx classes, they’ve really abstracted a lot more than the Win 32 API (to be expected given the CLR itself is an abstraction of the OS) and managed to work themselves into the MFC space (see the diagram). However, they still need to be focused on intrinsic functionality and their decisions on abstractions are countered by their need to provide flexibility. Abstraction vs. flexibility—that’s where I see the tradeoff with programming models. That means there’s still some abstraction required (which is where the patterns & blocks fit in). The best thing about the blocks is that we provide both by delivering the abstraction as a white-box assembly that can be tweaked and modified as necessary. By putting in the right mechanisms, we can multiple entry points for customers to employ abstractions as well as raising the level of implementable abstraction. Yet, by providing code, we still provide flexibility. Plus, with the “old school” methods, you have discrete entry points to a certain degree. You either program to the kernel, the Win 32 APIs, or the MFCs. With “new school”, your entry point in the PAG part of the stack is almost “analog” given the guidance and customizability of our deliverables. Take the data access block assembly as is, just gut the code for the pieces you want, or build on top of it and re-compile the assembly. That flexibility is a huge opportunity to win competitively. Finally, shipping out of product cycle gives us a huge advantage over MFC (which was locked into the VC++ cycles) by being more dynamic and responsive. That's where the excitement of this job comes in for me. Just like the .NET guys must've felt with DCOM, I feel like we are taking a great base idea (an extensible framework like MFC) and taking it to the next level for a new generation of software paradigms.