|
|
此文章由 flyspirit 原创或转贴，不代表本站立场和观点，版权归 oursteps.com.au 和作者 flyspirit 所有！转贴必须注明作者、出处和本声明，并保持内容完整
Jibe!
Working At Microsoft–20% Time and Prototypes
with 4 comments
I quite often see assumptions on the inter-tubes that writing software at Microsoft is a mind-numbingly boring, tedious, manual, excruciating, soul-crushing bureaucratic exercise. This couldn’t be further from the truth – especially in Windows. Google is famous for their 20% time policy. Microsoft doesn’t have a similar policy, but how we do things may be even better.
You can find the full series list here.
--------------------------------------------------------------------------------
Much has been made about Google’s 20% time for developers. If I understanding things correctly, people get about 1 day per week to work on things they feel are important. This is pretty cool.
Of course, Microsoft does not have the same policy. Much has been made about this as well.
What I don’t think has been well explained is that Microsoft’s approach – while maybe not as sexy, and certainly not highly publicized – may actually be better.
Most product teams in Microsoft (especially the Windows, Windows Live, Office and Developer Division) work to schedules. Meeting delivery dates is very important. This means that when we are in an active product development cycle we focus on getting our work done – hitting our dates. As you can imagine, cutting out 20% of every developers time in a product cycle would be pretty detrimental to the schedule – it would push things out considerably.
But, when we are not focused on finishing a coding, integration or stabilization milestone, we very often have time to work on 20% kind of things – often way more than 20%. We call this prototyping.
It is quite common for prototype code to productized and used in products. in fact, we usually use our production coding systems for prototype work. My team writes all our prototype code pretty close to production quality. We don’t hack it. Ad-hoc hacking just isn’t any faster than writing code well.
Prototypes are often rolled out to all the systems in Windows for testing. We’ll instrument these prototypes and collect data on them. Our regular systems catch problems like crashes and hangs
I’ve done quite a bit of prototyping. So have many others I know. This is true for minor things and some big things. For example Superfetch was heavily prototyped. So where some key cold boot optimizations, and a lot of our work on the xperf family of performance tools (and this). We’ve also prototyped internal things like telemetry processing tools, lab automation systems, and general helpful developer tools.
This is also time where we work with Microsoft Research to productize their work. We have quite an active program to do this – MSR and product teams work very well together. My team has an MSR project already queued up.
We could not have included many features in Windows without considerable prototyping time. Prototypes are most often the idea of a single person, or a small group of people. Program mangers often come up with great prototyping ideas. Prototyping ideas almost never come from management saying “Hey guys, go prototype this thing” (but that does happen sometimes).
In addition to prototyping features, there is a rich culture across Microsoft of building helpful software and making it available to other people in Microsoft. We have quite a nice in-house system for sharing tools and code. Our external CodePlex.com site is based on the internal system. This all started out as ad-hoc stuff.
If people don’t want to spend time prototyping or writing tools, they can simply use that time to teach themselves new things. For example, my WPF posts were done based on such time. I also taught myself MVVM. This was really handy because all our current projects use WPF and MVVM extensively. This time helped me prepare for our current projects well. Note, this wasn’t time I spent at home. This was all done at work.
In summary, there are times in our product cycles when people have quite a bit of discretionary time. Way more than 20%, often close to 100% for weeks. This is deliberate. We use this time for prototyping, thinking, experimenting and learning. Many excellent product features come directly out of this fruitful time and efforts. Most of this work is done at the grass roots level and determined by individual contributors or small teams of people with like interests and passions. This is not a new thing. The Windows organization has worked like this for a long time. |
评分
-
查看全部评分
|
画饼 (2007-12-5) patrickzhu 
发表于 2011-2-28 23:50
