Lessons from 6 software rewrite stories를 간단히 요약하였습니다.

Netscape 사례

가장 고전적인 사례.

조엘 스폴스키가 옳았다. 적절하지 못한 rewrite는 비즈니스를 사라지게 만들었다. 함부로 다시 만들지 말아라.

(넷스케이프가 제품을 밑바닥부터 다시 만드는 사이 IE에게 완전히 밀려 시장에서 사라지게 됨)

Basecamp 사례

재작성 혹은 레거시의 유지, 두가지 선택만 있는게 아니다. 기존 버전은 그대로 유지하고 새버전을 밑바닥부터 만든다.

가장 큰 문제는 레거시 코드가 아니라 버릴 수 없는 기존의 사용자들이다.

기존 사용자의 요구에 맞춰 기능을 추가해가는 사이에 미래의 새로운 유저에 대한 니즈는 충족시키지 못하게 된다. 그렇게 제품은 점차 도태된다.

Part of the problem is that you hear all the time from your present customers, but you don’t hear from your future customers.

Basecamp는 기존과 동일한 제품을 다시 만드는 것이 아니라 오늘날에 맞는 기능들로 제품을 다시만들어 새로운 유저들을 수용한다.

동시에 기존제품도 유지하여 기존사용자를 버리지 않는다. 

Visual Studio & VS Code 사례

기존 제품은 그대로 두고 새로운 시장을 위한 새 제품을 출시.

VSCode로 활발한 오픈소스 커뮤니티를 만들어내는데 성공

Key: VSCode = hipster cred

Gmail & Inbox 사례

하나의 백엔드 서비스에 두 종류의 프론트엔드.

인박스는 더 간결한 UI와 새로운 기능들을 가지고 있었지만 Gmail의 몇몇 기능들이 누락되어 있어 사용자는 이따금 Gmail에 접속해야만 했다.

인박스는 결국 서비스 종료했지만, Gmail은 인박스를 통해 많은 신규 기능들을 실험해본 후에 Gmail에 추가할 수 있었다. 그리고 이런 실험적 기능들은 인박스에서만 이뤄졌으므로 기존 Gmail사용자들의 UX에 전혀 악영향을 미치지 않고 신규기능을 테스트 할 수 있었다.

물론 인박스의 종료와 함께 유저들이 Gmail로 다시 돌아가야만 하는 불편이 있었다.

FogBugz & Trello 사례

시간이 지날수록 낡아가는 코드베이스와 추락해가는 마켓쉐어.

기존제품에 경쟁사의 기능을 추가하는 대신, 신규 제품을 시작. Trello.

덕분에 개발자들이 최신 기술 스택위에서 재미있게 개발할 수 있었다.

조엘은 다음과 같이 회고한다.

We use cutting edge technology. Often, this means we get cut fingers. Our developers bleed all over MongoDB, WebSockets, CoffeeScript and Node. But at least they’re having fun. And in today’s tight job market, great programmers have a lot of sway on what they’re going to be working on. If you can give them an exciting product … they’ll have fun and they’ll love their jobs.

Great working conditions -> Great programmers -> Great software -> Profit! 공식의 실천.

본문에는 훨씬 더 많은 사례가 나옴.

FreshBooks & BillSpring 사례

비 개발자 출신의 대표가 10년간 개발해온 FreshBooks. 비즈니스적으로 성공했지만 기술부채가 심각해서 새로운 기능을 추가하기 어려웠다. 그렇다고 처음부터 새로 작성하는 리스크를 감수하고 싶지는 않았다.

이 상황을 타개하기 위해 FreshBooks의 대표는 놀랍게도 새로운 법인을 고객들 몰래 만들어 새로운 자사의 경쟁제품을 만들어낸다. BillSpring.

새회사는 Lean UX: Designing Great Products with Agile Teams 책을 가이드삼아 애자일 문화를 적극 수용한다. 대표는 직원들에게 자신은 벤처 투자자이고 직원들은 스타트업에 있다고 가정하라고 말한다.

You’ve got four and a half months. If you’re in the market by then, we’ll give you more money. Otherwise, we’re out.

BillSpring이 성공하고 유저들이 FreshBooks를 이탈하여 BillSpring로 이동하기 시작하자,  BillSpring이 FreshBooks의 새 버전임을 고객들에게 밝히고 BillSpring의 제품명을FreshBooks로 변경한다. FreshBooks Classic 유저들에게는 마이그레이션을 유도한다. 하지만 강제하진 않는다.

새로운 FreshBooks은 크게 성공하고 새로운 기능들을 유연하게 추가해 갈 수있게 되었다고 회고한다. 하지만 무엇보다도 직원들이 애자일에 기반한 새로운 기업 문화를 만들어 낼 수있었던 것에 큰 의미를 두고 있다.

저자의 결론

My takeaway from these stories is this: Once you’ve learned enough that there’s a certain distance between the current version of your product and the best version of that product you can imagine, then the right approach is not to replace your software with a new version, but to build something new next to it—without throwing away what you have.