In 2021 and 2022, product manager Steven Sinofsky wrote a…

…first-person account of what I saw at the PC revolution from the perspective of joining Microsoft as a newly hired software design engineer fresh from graduate school working on developer tools, through my time as a program manager and ultimately leading Office, and then moving to Windows, and everything in between.

Sinofsky called the series Hardcore Software: Inside the Rise and Fall of the PC Revolution. It covers 1989–2012 and somewhere inside over 100 chapters, there is a fascinating six parter about the “ribbon” redesign of Office 2007.

• What is Software Bloat, Really?
• A Tour of “Ye Olde Museum Of Office Past”
• Competing Designs, Better Design
• Progress From Vision to Beta
• First Feedback and a Surprise
• Defying Conventional Wisdom to Finish Office

The first part covers the challenge of the team in 2007, taking stock of Office after almost 25 years of its evolution. (Number of toolbars in 1983: one. Number of toolbars in 2003: 31.) The second part shows great screenshots of all the Office versions from 1.0 until then, and the remaining four cover the Ribbon redesign process.

Regardless of how you feel about Microsoft Office today, and whether you consider the Ribbon interface a success, it’s a perfect weekend read as it covers universal challenges of software complexity and change management.

It’s such a potent series I’m sure we’ll come back to it. It covers a lot, including – in the first part – wrestling with a definition of bloat or complexity, which in the context of Office was less about the number of functions available, and more about mastery:

[…] In practice, bloat comes from the fact […] that Office does so many things that customers just assume the product can do whatever they need it to do. Despite that fact, customers have no idea how to make the product do what they need. This feeling of helplessness that leads to frustration. […]

Bloat is owning a product that you cannot master.

This below is a great observation about the perils of an idea of a “simple mode,” which Sinofsky argues is always a leaky abstraction:

We tried reducing bloat by hiding features […], but that only added to the mystery of the product. Mac, Windows, and Office all went through periods of “simple means fewer” and tried mechanisms such as short menus, simple mode, or adaptive toolbars. But that frustrated or confused people. No one really wanted to use a simple mode and there was always one command missing that was needed, so simple mode became a complicated way to do that one thing that made someone’s work unique.

It was great to see this argument for a broad definition of a bug, as it slides exactly into my post from a while back:

Ages ago in ancient Microsoft history there was a debate on the original apps team about what it means for something to be a bug. Is it a crash? Is it data loss? Is it a typo in an error message and so on? Out of that was created a notion of bug severity, a measure for how serious a bug might be from losing all data all the way to simple cosmetic issues. However, when it came to talking about bugs with product support or ultimately customers the definition of a bug was very simple “a bug is any time the software does not do what a customer expects”. This definition created a discipline of documenting everything reported about the product and always making sure every issue was looked at, even if a code change did not result. The key lesson was how helpful an expansive definition was.

There are also observations and research about how users “debug” the product to make it achieve something they know is possible, but they don’t know how:

We called the futzing document debugging, and it created a frustration that the product was powerful yet overwhelming. People believed a specific result was achievable but getting from point A to B seemed impossible or unlearnable.

And some about the challenges of figuring out what features people use:

[…] Most people didn’t know or care what buttons they clicked on or menus they chose so long as it was working for them—and that meant when asked, “Did you use X?” most people couldn’t recall. To a skeptical press or IT manager (and they all were) that meant unused features.

I should stop quoting and let you read in peace. But, check this out. Lisa wasn’t the only one having linguistic fun:

Early keyboard shortcuts were simple, like using Ins(ert) key to copy text from the scrap (clipboard).

Scrap!?