{"id":683313,"date":"2020-08-06T13:29:42","date_gmt":"2020-08-06T20:29:42","guid":{"rendered":"https:\/\/www.microsoft.com\/en-us\/research\/?post_type=msr-blog-post&p=683313"},"modified":"2020-08-06T13:29:42","modified_gmt":"2020-08-06T20:29:42","slug":"what-is-the-new-role-of-research-in-engineering","status":"publish","type":"msr-blog-post","link":"https:\/\/www.microsoft.com\/en-us\/research\/articles\/what-is-the-new-role-of-research-in-engineering\/","title":{"rendered":"What is the new role of research in engineering?"},"content":{"rendered":"
There I was, in the fall of 2015\u2014just one week back at Microsoft after having left the company for a few years. I stared at my computer and struggled to understand how my new team, soon to be named PROSE, actually worked. Naturally, I wanted to fit in and influence the team\u2019s direction in a positive way. As a first step, I had sent out an email with what I thought were simple questions with obvious answers.<\/p>\n
Are we former researchers now building products? Or are we a research team embedded in a product organization? And what do our managers think we are?<\/p>\n
The response was not at all what I expected.<\/p>\n
I thought we were obviously a group of (mostly) former researchers now working as engineers in a big Microsoft product org. Asking those questions was really just a preamble to my plan to make a case for some changes. I thought I had been hired to help figure out how to ease the transition to shipping products.<\/p>\n
My new manager made it crystal clear that the answer was something altogether different. And that meant I had to derail my thinking from some well worn ruts and start forging a new path for myself and the team I had joined.<\/p>\n
It promised to be quite the journey. As fate would have it, I was fortunate to have had an earlier (painful) experience in my Microsoft career that prepared me well \u2026<\/p>\n
\u201cAre you guys completely insane? What were you thinking? Only an idiot would have built it that way!\u201d<\/p>\n
I don\u2019t remember the exact words, but in my minds eye they were delivered by a large and very angry man with the utmost contempt. We sat in a conference room in one of the old buildings on the Microsoft Redmond campus, and the thirty or so other people packed into the room all nodded in agreement, their eyes fixed on me. It felt like an attack, yet these were our best friends. (The next day he posted a public apology to his credit.)<\/p>\n
The meeting, which took place about twelve years ago, sticks with me as the first time I\u2019d ever seen a group of customers get so passionate in voicing their displeasure. I\u2019d worked on some big products at Microsoft since joining in the mid-90\u2019s, and while conversations within a product team sometimes devolved to less productive, higher volume tirades, it never happened with customers. Until now.<\/p>\n
Plus, these customers were special. They were MVPs, or \u201cMost Valuable Partners\u201d\u2014a unique designation of technology experts who evangelize for Microsoft products, and some of our best and smartest engineering advocates. And they were pissed.<\/p>\n
The topic of the day was an update on a promising new technology: The Entity Framework (EF), a set of technologies in ADO.NET that let developers work with data in the form of domain-specific objects like customer addresses, without having to worry so much about the details of how the data is stored. We knew it was the right thing to build because it promised to dramatically improve data access for .NET developers, but we were blind to all that was wrong with it.<\/p>\n
I had the dubious honor of receiving the brunt of this outrage because I had become the primary Microsoft face of EF. I straddled two worlds\u2014one of them external, where I introduced EF to customers, and the other internal, where I led the charge of representing the customer point of view to the engineering team. And an ugly point of view it was. Version 1 of EF was so widely criticized that nearly a thousand developers signed a now-infamous \u201cVote of No Confidence\u201d in the product.<\/p>\n
Looking back now, it\u2019s hard to reconcile the current status of EF with that first, painful version. Today there are two variants of EF, each with over 85 million NuGet downloads. The team has proudly embraced the unicorn as their mascot based on the widely acclaimed \u201cMagic Unicorn Edition\u201d of the software. EF is in a good place, but that\u2019s the result of a lot of hard work to remake something which had a rocky start.<\/p>\n
We can point to a lot of causes for that difficult time, but I\u2019ll tell you about one little known fact which is at least partly at fault: EF was originally built around technology from Microsoft Research (MSR).<\/p>\n
Some folks at MSR had a great idea for addressing one of the hardest parts of Object\/Relational Mapping. As plans came together to build the new product, the product team decided to take MSR\u2019s code and one of their researchers into the team. On the surface there were some technical difficulties, but we thought we understood them. And we all felt that the potential advantage of an innovative new approach sounded great. In fact, our goal was not just to build another Object-Relational Mapping (ORM) library but to begin a new wave of related efforts around something we called the Entity Data Model.<\/p>\n
The problems we encountered probably aren\u2019t too hard to predict, especially with the benefit of hindsight and Microsoft\u2019s broader evolution in the last 10 years. Foremost is the fact that we didn\u2019t listen to our customers up front or frequently enough along the way.<\/p>\n
Don\u2019t get me wrong, product teams have been guilty of this particular mistake many times over the years, and we were actually trying to connect to customers the best way we knew how. But in our case the problem was exacerbated by the nature of our partnership with MSR. We were overly focused on two things: 1) getting all that innovative research goodness into the product, and 2) addressing the code quality and engineering breadth issues that came along with a codebase that started not as something shipped in a product but rather to facilitate research.<\/p>\n
Eventually we got over the initial transition from MSR and started connecting with customers much more effectively, enabling us to create technology that was much better at meeting their needs. Not only did the process amount to a number of changes to the initial codebase over the course of several years, but to truly build the right product, the team eventually completely rewrote everything from scratch in a second codebase which likely doesn\u2019t have any of the original MSR code (or even the core concepts behind it).<\/p>\n
EF is now in a good place, but I would argue that happened in-spite-of<\/em>, not because-of<\/em> the MSR collaboration. Does this mean I believe we should stop investing in MSR or research at Microsoft? No way! In fact, when I returned to Microsoft 5 years ago, I was tremendously excited by the prospect of bringing my perspective and experience building products to the task of helping researchers ship software. While it turns out that I was mistaken about the nature of that task, the results speak for themselves:<\/p>\n \u201cNot certain how you managed to get me excited about TEXT files but you did it!\u201d<\/p>\n That was just one of the many gratifying comments heard from MVPs at a recent (virtual) meeting with a Microsoft product team. \u201cThis feature is freaking awesome!!!\u201d said another. Also: gifs of fireworks behind the Eiffel Tower and Kramer from Seinfeld gesturing to indicate his mind was blown.<\/p>\n These reactions are just the most recent fruit of a collaboration between research and engineering, an experience that was the polar opposite of my EF MVP debacle.<\/p>\n How did we get there? What changed? What did we learn?<\/p>\n The most important thing to understand is that we didn\u2019t turn those researchers I\u2019ve been working with over the last few years into engineers. Instead, we created a team comprised of engineers and researchers working together<\/em>, one that partners with product teams to bring research innovations to the hands of customers. It took persistent effort from each of these groups to make that possible.<\/p>\n The person behind this particular technology is my research colleague, Vu Le, who has been working on it for more than 5 years. Each time a new Microsoft product team chooses to collaborate with us, the technology has needed to morph into a new form and respond to new requirements. When Vu first brought the idea to the Power Query team, it took some convincing to show the value, but they soon came on board. And in doing so, they brought their own new requirements, which forced research to respond. The product team had a solid relationship with their customers and could help refine the ideas into something that really met their needs. Not only that, but the code being produced was the result of a joint effort with the engineers on our team. The engineers and researchers worked together to ensure it was built the right way<\/strong> from the start. It didn\u2019t need to be rewritten, rethought or restarted in order to be incorporated into Power Query\u2019s product.<\/p>\n To be clear, the researcher did not come up with an idea and then hand off to an engineer to implement it\u2014the engineers on the team played a supporting role that enabled the researcher to efficiently write production-quality code. Engineers also played an important role in understanding products and users to help make sure the ideas we chose to invest in were well positioned to have impact. And, when there were elements that didn\u2019t involve research work, the engineers picked up those tasks to allow each team member to focus on their unique area of expertise.<\/p>\n Rarely does a significant accomplishment come easily, and the experience of the PROSE team is no exception. At this point we have been evolving our processes for almost five years, and I expect to continue evolving for the next five years or however long we stay together. Our partnership with the Power Query team is several years old, and while there have been ups and downs, the impact is real.<\/p>\n We have not yet arrived at our destination, but our progress along this path brings us much closer to our goal than we were with EF, and I\u2019m so glad to be part of a blended research and engineering group rather than an engineering team that happens to include some former researchers.<\/p>\n So, is this the<\/strong> model for getting all that research goodness into the hands of our customers?<\/p>\n No.<\/p>\n There\u2019s no doubt that things will continue to evolve and adapt. There are certainly multiple ways for researchers and engineers to successfully collaborate. But, we have<\/strong> learned some important lessons that will help researchers and engineers be more effective together:<\/p>\n – Danny Simmons, August 2020<\/p>\n I would love to hear about your experiences at the boundary between research and engineering. Contact me at dsimmons@microsoft.com.<\/em><\/p>\n","protected":false},"excerpt":{"rendered":" There I was, in the fall of 2015\u2014just one week back at Microsoft after having left the company for a few years. I stared at my computer and struggled to understand how my new team, soon to be named PROSE, actually worked. Naturally, I wanted to fit in and influence the team\u2019s direction in a […]<\/p>\n","protected":false},"author":39165,"featured_media":0,"template":"","meta":{"msr-url-field":"","msr-podcast-episode":"","msrModifiedDate":"","msrModifiedDateEnabled":false,"ep_exclude_from_search":false,"_classifai_error":"","msr-content-parent":663303,"footnotes":""},"research-area":[],"msr-locale":[268875],"msr-post-option":[],"class_list":["post-683313","msr-blog-post","type-msr-blog-post","status-publish","hentry","msr-locale-en_us"],"msr_assoc_parent":{"id":663303,"type":"group"},"_links":{"self":[{"href":"https:\/\/www.microsoft.com\/en-us\/research\/wp-json\/wp\/v2\/msr-blog-post\/683313"}],"collection":[{"href":"https:\/\/www.microsoft.com\/en-us\/research\/wp-json\/wp\/v2\/msr-blog-post"}],"about":[{"href":"https:\/\/www.microsoft.com\/en-us\/research\/wp-json\/wp\/v2\/types\/msr-blog-post"}],"author":[{"embeddable":true,"href":"https:\/\/www.microsoft.com\/en-us\/research\/wp-json\/wp\/v2\/users\/39165"}],"version-history":[{"count":1,"href":"https:\/\/www.microsoft.com\/en-us\/research\/wp-json\/wp\/v2\/msr-blog-post\/683313\/revisions"}],"predecessor-version":[{"id":683316,"href":"https:\/\/www.microsoft.com\/en-us\/research\/wp-json\/wp\/v2\/msr-blog-post\/683313\/revisions\/683316"}],"wp:attachment":[{"href":"https:\/\/www.microsoft.com\/en-us\/research\/wp-json\/wp\/v2\/media?parent=683313"}],"wp:term":[{"taxonomy":"msr-research-area","embeddable":true,"href":"https:\/\/www.microsoft.com\/en-us\/research\/wp-json\/wp\/v2\/research-area?post=683313"},{"taxonomy":"msr-locale","embeddable":true,"href":"https:\/\/www.microsoft.com\/en-us\/research\/wp-json\/wp\/v2\/msr-locale?post=683313"},{"taxonomy":"msr-post-option","embeddable":true,"href":"https:\/\/www.microsoft.com\/en-us\/research\/wp-json\/wp\/v2\/msr-post-option?post=683313"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Case Study #2 – Parsing Text Files by Example in Power Query<\/h2>\n
What does it mean to blend research & engineering?<\/h2>\n
\n