My youngest child left for college more than a year ago, leaving my wife and me with an empty nest. We knew someday we’d need to move for health, family, or financial reasons, but our old house is wonderful. It’s comfortable and familiar, full of fond memories and accumulated belongings, and near to friends and favorite places. However, it has more space and yard than we need, it’s close to schools but not close to restaurants, and our friends are starting to leave the neighborhood.
Sometimes you know you need to change things, but moving from your comfort zone is hard, especially when you’ve been living there for years. As a company, we’ve been inhabiting some of the same homes for decades: Office, Windows, Visual Studio, SQL, and Exchange. We’ve been comfortable in these homes, but times change, and we’ve got to move forward. Office is moving online to Office 365. Visual Studio, SQL, and Exchange are moving to Visual Studio Team Services, SQL Azure, and Exchange Online. My wife and I moved too.
Moving to a new home turned out to be far more difficult than I imagined. I anticipated the emotional pain of leaving, the financial burden of buying a different house, and the physical labor of shifting our belongings. What surprised me were all the habits I had to break, the substantial fixes we needed to make to our old home, and the endless little details that required attention during the transition. The move was exhausting, but well worth it due to the biggest surprise of all—the unexpected shift in our mindset that came with our shift in location.
There’s been an awakening
In retrospect, I now see we were in decline. Our children had left. Our neighbors were leaving. We were following the same habits and reliving the same experiences we had for nearly two decades.
Now that we’ve moved, painful as it was, we are reinvigorated. We’re meeting new people, experiencing new food and new places, and breaking out of our old routines. Our children are even excited to visit and join us in our new lives and fresh outlook.
If you talk to the engineering teams for Office, Visual Studio, SQL, and Exchange, they’ll tell a surprisingly similar story. The switch to services has been remarkably difficult, yet their whole world is new again, and their customers are excited to visit their new homes and join them with a fresh outlook on life. The shift has been so powerful and so profitable.
I want to stay
If changing locations brings about such a reinvigorating shift in mindset, why do some people and groups stay in their old homes with their old habits, slowly being abandoned by their children (apps and devices) and friends (partners and customers)?
First of all, it’s easier to stay put and just remodel or repaint the house. Doing this adds the veneer of revitalization, without all the pain of an actual move. You get to keep your old habits and keep reliving your fond old experiences (while you keep denying your decline).
Second, moving is scary and risky. What if your new home is faulty? What if your old stuff doesn’t fit? What if your family and friends don’t like it? Moving is a lot of pain and expense to go through only to have a bad outcome, especially when it’s so much easier to stay put.
What are the expenses of moving from packaged products with long cycle times to cloud services with short cycles times? Actually, they are very similar to those of moving to a new house.
- There’s the emotional pain of leaving the old ways of doing things behind. Remember stabilizing products for months? Haphazardly coding features and fixing them later? Starting twenty different features and not finishing any for a year? This stuff works differently when you release monthly.
- There’s the financial burden of scaling build, test, release, measurement, and reporting systems to handle daily releases. You need daily flighting of builds to provide the preview feedback necessary to ensure high quality for a broad audience monthly. Daily releases require at least two official build and test passes each day (one to validate and fix, followed by one to validate and release). Our old systems weren’t built to such scale.
- There’s the physical labor of shifting your code to its new home in the cloud. You’ve got to reorganize (refactor) your legacy code into components, speeding up builds, tests, and releases. You’ve got to toss out code that’s no longer needed (or donate it to friends), rework some code to run as services or apps, and harness new and existing instrumentation to measure and report how much customers are enjoying the new place. That’s a great deal of heavy lifting.
- There are the old habits you have to break that support working on tons of features at the same time, instead of working on one or two, testing and releasing them, and then working on the next. You’ve got to work closer to the release branch (or in the release branch), since weekly code movement doesn’t fit a daily release schedule. You’ve got to use feature flags to hide and disable new code in the daily releases, rather than rely on faraway branches. Picking up new habits is jarring, but they soon become second nature.
- There are the fixes you need to make to your old legacy code to allow it to survive in a service model. After all, you’re moving, but you’re not burning down the old place. People (customers) still want to live there. You’ve got to update it, fix all the rot, clean up the technical debt, and enable automated daily deployment and servicing. This work turns out to be surprisingly difficult and expensive.
- Finally, there are the endless little details that complicate the move. The indecipherable manifests that need to be broken down. The tight coupling of some screwy little components that need to be broken apart. The ancient script written by the long-retired engineer that does what exactly? The versioning, testing, and reporting systems that all assumed no more than one build a day. There’s always something, and pealing back the onion only reveals more layers.
I’ve written about the shift to services a great deal over the years, starting with At your service, then It starts with shipping, and peaking with There’s no place like production.
Still want more? I cover further details in Quality is in the eye of the customer, Production is a mixed blessing, Data-driven decisions, Bogeyman buddy—DevOps, Escalation acceleration, and Diamond dependencies.
Come with us
It’s extremely difficult and costly to move, and staying put is so comfortable and feels so safe. You’d think anyone would be crazy to relocate. Yet major businesses at Microsoft that have been residing at the same residence for decades have recently uprooted themselves and moved, just as my wife and I did in December.
Was it worth all that pain and expense? Oh my goodness yes! My wife and I have a new lease on life, and Office, Visual Studio, SQL, and Exchange do too. Instead of a steady decline, just waiting for the next generation to take over, we’ve reinvigorated ourselves, and our businesses are gaining record growth.
Please don’t be lulled into thinking you can just repaint and remodel, maybe buy a sports car, and become cool again. Moving forward requires real change and real effort. It’s scary and risky. There are tons of details that take far longer to resolve than you imagine. But in the end, your choice is starkly clear: stay and decline, or move and grow. Choose wisely.
I talk about how to navigate change in The value of navigation, and how to evolve culture in Culture clash.
Be First to Comment