Scott Boehmer

Tag: My Career

  • My Career: Microsoft Edge

    The internet famously caught Microsoft unprepared. Netscape was the first widely used browser, but when Bill Gates redirected the company to focus on the internet, the ability to set the default browser for Windows allowed Internet Explorer to gain dominance. That lasted into the early 2000’s when first Firefox and then Chrome took advantage of Microsoft’s lack of investment in IE to take over the market. As its market share cratered, Microsoft started actually investing in IE again, but by that point its brand was tarnished with a reputation for missing features and poor performance.

    The later part of my work on Windows Phone had been leading a team of engineers that worked on the interface for Internet Explorer for Windows Phone 8.1, but that was fairly separated from the team working on Internet Explorer for desktop Windows. When the Windows and Windows Phone organizations merged together to work on Windows 10, the browser teams merged too. My team and I became one of the teams in the browser app group so that we could use our experience to continue delivering a mobile-friendly browser experience for the converged Windows 10.

    A combination of factors meant that the team could make a big bet. Internet Explorer’s brand image was considered to be badly tarnished, and everyone wanted Windows 10 to be a clear signal of a reset from Windows 8. Then we also were aiming to deliver an OS with apps that could be unified across computer and mobile form factors. With those combined, the decision was made to build a new browser with a new brand. Eventually, the branding folks would name it Microsoft Edge, but internally we were calling it Spartan.

    Spartan involved an entirely new application built as a universal Windows application using C++/CX and XAML. Then the rendering engine was forked from mshtml in order to allow for breaking Internet Explorer compatibility to pursue web standards and Chrome compatibility.

    In that effort, my team was in charge of the mobile interface, downloads experience, and gesture navigation. As the member of the broader Spartan team with the most background in XAML, I also got to play a large role in deciding on the overall app’s architecture to allow for sharing interface components across different presentation modes.

    It was a huge project to get Edge ready for release with Windows 10, so there were definitely some rough edges in that first version, but overall, I was pretty proud of what we delivered.

    At the time, Microsoft had an ambitious vision for the future with Windows as a seamless experience across desktops, laptops, phones, gaming consoles, virtual reality headsets, and mixed reality headsets. Execution towards that goal was uneven though. Within the Windows team, there was a culture that only “Big Windows” (desktop OS) mattered, so it wasn’t uncommon that phone builds would get broken by teams that just didn’t bother thinking about Windows Phone. Other initiatives, like the Creators Update and Paint 3D ended up being trimmed to the point of being disappointments. There were some great ideas in the mix though. One of my favorites was Continuum where a Windows Phone could be connected to a monitor, keyboard, and mouse and then present a desktop-like experience.

    Under Satya Nadella’s leadership, Microsoft’s ambitious vision for Windows started to wither. With Windows Phone considered a low priority and then cancelled, the entire idea of a unified OS across different types of consumer devices no longer made sense. It felt like Windows was done trying to build something interesting and instead was resigned to a gradual path towards irrelevance, at least on the consumer side of things. With that feeling of a lack of purpose for the team, I started looking for a way out of the Windows organization.

  • My Career: Windows Phone

    Microsoft got into the mobile market early with Pocket PC devices. Launched in 2000, these were devices aimed at professionals who wanted mobile access to their work-related calendars and email. With dominance in enterprise software, Microsoft was well positioned to sell . Apple’s release of the iPhone in 2007 completely changed that market though.

    In order to compete with the iPhone, Microsoft decided to entirely rework Windows Mobile into Windows Phone. It would have a new touch-focused interface and an application model much closer to that offered by the iPhone.

    The Silverlight code base ended up being chosen as the basis for applications on Windows Phone. Some of the Silverlight team supported that effort for the Windows Phone 7 release. Then with Silverlight’s wind down as browser plugins became obsolete, I moved over to working on the Windows Phone development platform for Windows Phone 8 in late 2011.

    For Windows Phone 8, the big challenge was a move from being based on Windows CE to Windows NT. This brought in a lot of OS capabilities, but it also had the potential to break a lot of things. My work for the release ended up being documenting the places where app developers had taken dependencies on the ordering of events on Windows Phone 7 and then adding code to the platform so that those events would be guaranteed to have the same ordering when the apps ran on Windows Phone 8. It wasn’t particularly exciting work, but it was critical to maintaining compatibility with the existing Windows Phone app catalog.

    After Windows Phone 8 shipped, I changed roles for the Windows Phone 8.1 release. I moved from being a individual contributor to being a team lead, and I left the app platform team for the team responsible for the phone browser’s user interface. My team’s goal was to make Internet Explorer on Windows Phone feel modern. We implemented support for having more than 6 open tabs, for gesture navigation, roaming favorites and history across Windows devices, and autocomplete for the address bar. I had been an acting lead for a while during Windows Phone 8, but this was my first time officially being a manager. I thought my team was great, and we accomplished a lot for the release.

    Across this time, Windows Phone was a fun project to work on and a product that I was proud of. It had a lot of innovative features like live tiles, jump lists, kids corner, and more. Unfortunately, it was also struggling in the market. By the time Microsoft shifted from an enterprise focus to a consumer focus for smartphones, iPhone and Android were both already in the market. This meant that for app developers, it would be a third mobile OS to support. Then missteps in the move from earlier phone projects, Windows Mobile and Kin, as well as not allowing devices to update from Windows Phone 7 to Windows Phone 8 caused frustrations amongst mobile operators, fans, app developers, and device manufacturers.

    There had also been a problem with the organization of Microsoft’s operating system teams. When the Windows 8 project started, one of its goals was to support tablets and compete with the iPad. Unfortunately, upper management on the Windows side decided that aligning with the Windows Phone application model would only hold Windows back, so they built an entirely different application model than what the Windows Phone team had been using since the release of Windows Phone 7. This meant that applications written for Windows Phone wouldn’t run on Windows tablets and vice-versa. This set the company on a path where the development platforms and app stores for both Windows and Windows Phone were weaker offerings than they otherwise could have been.

    After the relative failure of Windows 8 and 8.1 to draw fans or app developers and the continuing struggles of Windows Phone to build market share, Microsoft decided to merge the Windows and Windows Phone projects into a single team for Windows 10. The idea was that a unified platform would improve the odds of success for both, but a lot of ground had already been lost over the years of them pursuing their own directions. The idea of a unified Windows platform offered some hope internally, and at the time, I was happy to see the teams merging together.

    When the reorganization happened in 2014, I, along with most of my reports from the phone browser team, moved to a new team that was tasked with building a browser app for Windows and Windows Phone. My next career post will cover my time on that team.

  • My Career: Silverlight

    When I graduated from the University of Michigan, I decided to start my software engineering career at Microsoft. I accepted a position on a new small team working on what was at the time referred to as either Jolt or WPF/E (Windows Presentation Framework Everywhere). The product was a cross-platform browser plug-in to support rich applications and media streaming. Upon release, it would be called Silverlight.

    The first version of Silverlight was very bare bones. It supported embedding a user interface defined in XAML (Extensible Application Markup Language) into a webpage and interacting with those UI elements through the page’s JavaScript. The main goal of that v1 release was media players. At the time, Flash was the dominant way to embed media on a webpage because without plug-ins, browsers did not have a way to support video playback.

    From Microsoft’s point-of-view, the point of Silverlight was that competition with Flash. Microsoft wanted to sell their servers for media delivery, but the dominance of Flash for media playback was allowing for Flash Media Server to be the go-to server option for media. In order to support Windows Server sales, Microsoft needed an alternative to Flash so that companies could deliver rich media experiences without establishing a relationship with another server company.

    As a side note, when you’re working at a big company, it’s always worthwhile to know why the company is investing in what you’re working on. It won’t always be talked about openly, but figuring it out will help you to understand what outcomes will actually be valued by upper management.

    My main contribution to the initial version of Silverlight was its support for Firefox and Safari. I worked on pieces of both the browser interaction through the NPAPI (Netscape Plug-in Application Programming Interface) and our internal platform abstraction layer for system calls on Mac OS. I hadn’t programmed either browser plug-ins or anything for Mac before this point, so my time involved a lot of learning new things as we pushed towards our first release.

    The second version of Silverlight, released about a year later, made things much more interesting. The plug-in now included a version of the .NET Framework allowing for programming of Silverlight-powered interfaces with C# rather than JavaScript, and it supported more media features – adaptive streaming and, unfortunately, DRM (Digital Rights Management). That second release is where Silverlight started to pick up bigger customers including NBC and Netflix.

    As Silverlight grew, I worked on other pieces of it and picked up more responsibilities. I implemented its networking APIs to give application developers the ability to make HTTP requests using either the browser networking stack, which allowed for cookies and auth to be used from the browser session, or directly through the operating system, which allowed more control but was independent of the browser’s state. I also worked on its support of out-of-browser applications, including support for multiple window Silverlight apps.

    It was a lot of fun to get in on a project from nearly its start and see it grow over the years as we shipped 5 major versions. The team working on Silverlight was also great. Unfortunately, it wouldn’t last. While Silverlight was successful in enabling customers to deliver great media experiences using only Microsoft products, shifts in the way people use the internet over those years meant that it had no future.

    Two big changes were happening. First, Google launched their Chrome browser and began to push for HTML5. Their search engine business meant that they wanted to both push application development to focus on websites and for those applications to use standard HTML and JavaScript that their search engine could understand. The other big shift was the iPhone. Suddenly people had a capable browser in their pocket that they were using for more and more of their web browsing. Supporting Windows and Mac was no longer a compelling cross-platform story, and Apple had no interest in supporting Silverlight in their phone browser.

    Between HTML5 allowing for rich media without any plug-ins and more browsing happening on devices without plug-in support, there was no longer a market for Silverlight. As work on Silverlight 5 wrapped up, Microsoft split the team. A small team would continue to service Silverlight until its inevitable end-of-life, and then the vast majority of the team was moved to either Windows Phone or Windows 8 to work on the application platforms for those two products.

    Another lesson from Silverlight is that sometimes even if your product is successful, the market can shift and change its fate. Silverlight didn’t end because we failed to deliver a good product or because we were out-competed by another plug-in. Instead, changes in the broader market brought about the rapid disappearance of browser plug-ins as a whole.

    I was on the portion of the team that moved over to Windows Phone, but that is a story for another post.