The old memories of Microsoft usually conjures up jokes about Clippy. Or IE. Or Steve Ballmer running around screaming on stage like a madman…

If you’re like me you really can’t get enough of Steve Ballmer video, can you?

Thankfully Microsoft left a lot of those mistakes in the past, including Steve Ballmer and his wild stage antics. Which is more recently evident by Microsoft’s 2018 Q2 financial results with revenue of $26.8 billion and net income of $7.4 billion. Microsoft has turned its cloud computing division into a $20-billion-a-year business, trailing only Amazon. The Office suite has morphed into a subscription service for corporate customers and is a powerful driver of earnings. LinkedIn saw revenue grow 37%, and is approaching $6 billion a year. And, yes, Windows still generates billions, but the percentage of Microsoft’s revenue generated by Windows has dropped from 28% to around 16% since 2010. Both its Office business and its cloud business are bigger.

Those financials are no small feat and represent a larger turnaround at the company, which the media has largely mis-branded the reason for the turnaround by highlighting everything from the new CEO Satya Nadella to Microsoft’s massive move to the cloud to the exit of Steve Ballmer.

But there was one small problem: they were all wrong.

I would agree that moving their entire set of products to the cloud and standing up their own cloud services, Azure, certainly helped pull them back from the brink of obscurity, but this was merely an inconsequential accomplishment that would have been a footnote in technology history were it not for the larger movement that started 10 years ago.

The Beginning of the End

By the early 2000’s, Microsoft’s typical software production cycles would be an astronomical two or three years, where developers would spend 6 months or more writing specs and developing a software plan. They thought they knew what to build. And more importantly, why they were building it. Based on those assumptions, they drafted a timeline that was largely set in stone.

But nothing ever never shipped on time, regardless of what they knew or how accurate their plan or timeline.

The trouble usually began once they celebrated the coveted “code complete” state and started the test-and-stabilization phase. This is where they delivered the beta version of the code and would find a massive amount of bugs. And more bugs. And more bugs. Which was often punctuated by feedback that a handful of the features they had built were not quite right.

But at this point bugs were the priority and the larger issues would invariably become change requests to be dealt with in the next release, still several years away. Aaron Bjork, a group program manager in Microsoft’s Developer Division, poignantly stated that “It was a train wreck… a death march. Long hours. Weekends. Crazy. Employee morale was in the toilet. Nobody enjoyed that.”

What Microsoft didn’t realize in their celebrations at the end of the coding phase is that they didn’t have a completed product, they had a tangled web of unresolved quality problems. They had no idea while celebrating their “major technological achievement” that it was actually a massive amount of technical debt that would likely take 10 years to fix! In retrospect, says Aaron, “it was ridiculous, but that’s how it was.” 

Continue to Part 2: Don’t Go Chasing Waterfalls >