삼성 타이젠이 실패한 이유

삼성 타이젠 개발팀에 있었던 대참사

 

옛날옛날 아주 먼 옛날, 타이젠의 모든 소스코드는 Git으로 유지되고 있었어요.

gbs(Git Build System)라는 멋진 도구로 빌드가 가능했었고, 개발팀은 코드 검토를 위해 git repo와 Gerrit을 사용했답니다.

그러던 어느날, 암흑의 경영진이 타이젠 개발팀을 습격하기 시작했어요.

 

경영진은 리눅스 기반 OS(타이젠)를 개발하는 작업이 윈도우에서 이뤄져야 한다고 결정했어요.

모든 빌드는 로컬에서 하는 대신, 빌드 서버로 전송해서 그 결과를 다운로드하는 방식이 표준이 되어야 한다고 생각했어요.

세계의 다른 팀들과 달리, 한국팀은 점차 윈도우와 비주얼 스튜디오를 사용하기 시작했어요.

그래도 그때까지는 괜찮았답니다. 그때까지는요...

 

어느 날, 경영진은 오로지 타이젠만을 위한 괴상한 이슈 추적 시스템을 개발하기로 결심했어요.

Git과 Gerrit만으로는 모든 것이 충분하지 않다고 느껴졌었거든요.

 

그렇게 새로 만든 시스템은 100% 무질서로 이루어진 괴상한 아름다움을 가지고 있었어요.

하나의 이슈는 수 많은 양식의 탭으로 만들어졌어요.

3분의 1은 영어, 3분의 1은 한국어, 3분의 1은 뭐라 알아먹기 힘든 콩글리쉬로 작성되었어요.

3개의 엑셀 시트를 사용해서 그려진 쓸데없는 다이어그램이 포함되었고,

내용이 너무 많아서 HD 모니터로 한번에 보기 어려울 정도였어요.

 

이윽고, 경영진은 자신들이 새로 만들어낸 워크플로가 형편없다는 사실을 알게 되었어요.

뿐만 아니라, 윈도우에서 git을 사용하는 일은 리눅스에서 git을 사용하는 일보다 훨씬 복잡하고, 어려운 일이었죠.

 

그래서 그들은....

윈도우에서 사용할 수 있으며 이슈 추적 기능을 가지고 있는, 먼지 쌓인 채 잊혀지고 있던 오래된 버전 관리 프로그램을 발굴해냈답니다.

그 프로그램의 이름은 Perforce였어요.

그래서 경영진은 Git 대신 Perforce를 사용하기로 했어요.

빌드 시스템도 Perforce 기반으로 바뀌었어요. 사용자들에게 Perforce로 빌드된 어플리케이션이 배포되기 시작했어요.

 

Perforce 버전 앱의 갖가지 이슈가 Git 팀에게 쏟아졌고, 그 결과 개발실에선 WHAT THE F*** 이 난무했답니다.

아예 가지고 있지도 않은 코드의 버그를 고치는 일보다 더 재밌는 일이 세상에 존재할까요?

 

경영진은 회의를 열었습니다.

 

회의 주제 중 하나는 코드리뷰 방법이었습니다.

국제 팀은 오래전부터 Gerrit을 사용해 코드리뷰를 거쳐왔지만,

한국팀은 코드리뷰의 개념을 이해하지 못했어요. 모든 것을 main repo에 직접 넘겼답니다.

일부 패치의 품질은 너무 나빠서, 어떤 비한국 팀에게는 코드리뷰가 작업 최우선 과제가 될 정도였어요.

 

한국 경영진은, 마침내, 코드리뷰를 도입하기로 결심했습니다.

MS Word로 변경사항에 대한 문서를 작성해, 각 버그에 대한 코드 검토 요청을 파일 첨부해 보내기로 했어요.

 

그 문서는 3페이지에 달하는 양식으로 쓸모없는 정보를 담고 있어서 아무도 읽고 싶어하지 않았어요.

3페이지의 마지막에는 변경된 각 파일에 대한 변경사항을 복사 붙여넣기할 수 있는 공간이 있었어요.

리뷰어는 그 변경사항 중 몇번째 라인에 어떤 코멘트를 달 것인지 상세하게 Word 양식을 작성하면 되었답니다.

 

패치를 제출하고, 문제 추적기를 클릭한 다음, MS Word 양식을 작성하세요.

문자 그대로 몇 시간이 걸리면서까지 패치 하나를 작성하세요.

Git과 Gerrit을 함께 사용하는 건 한국 개발팀한텐 너무나도 어려운 일이었으니까요.

 

이렇게 제출한 버그가 언제 고쳐지냐구요? Word 양식을 보세요.

여기 어떤 책임자를 거쳐서 어느 정도의 시간이 걸려서 코드가 전달될지를 나열한 필드가 있으니까요.

 

전 안 볼거에요. 당신이나 보세요.

 

글만 읽어도 숨막힘.... 이게 대기업의 업무방식...?

윈도우 비쥬얼 스튜디오 엑셀 워드 보고서 무슨 문제라도? ㅋㅋㅋ

 

 

Time for another story from a certain Korean corporation.

A certain abomination of an OS with a capital T in its name, keeps all its sources in git. The integration is so tight, that components are built by developers using a tool named Git Build System. For a long time development was based on git repos with gerrit in between for code review. But something sinister lurked in the shadows and one day decided to strike.

In all their wisdom, management decided that developing a Linux-based OS should be done on Windows; all builds shouldn’t be done locally but sent to some build server and the results downloaded, and that became the Standard. Teams in Korea began working with Visual Studio, while other teams in the rest of the world managed to keep their old ways and actually stay productive.

At some point, management decided that all issue tracking software in the world is not enough and decided to devote a metric ton of money and countless manhours to build something, which managed to reshape the definition of “broken beyond uselessness”. A form so chaotic, it’s beautiful in a perverse way. A single issue is made of countless tabs of forms, each spanning more than a FullHD monitor can show. All written in 1/3 English, 1/3 Korean and 1/3 unknown hybrid language, with features like -13 456 bug count and issue state diagrams taking three Excel sheets to describe (bonus WTF: drawing state diagrams in Excel). Thus the Standard was amended.

What does all that have to do with git and developer environment? In time Windows guys with Korean management (which has the final say in everything without discussion) discovered that git on Windows is somehow even worse than git in general, and their workflow generally sucks. They also discovered an ancient proprietary VCS called Perforce which worked on Windows and could be integrated with the issue tracker. Therefore the only logical conclusion was to start using Perforce. They only forgot to tell everyone else to stop using git…

Time went by and Bad Things started to appear. Git/gerrit was official in some teams, but Perforce was official in other teams (even working on the same component). Some patches went there, some there. The management finally decided Perforce code should be used as THE source for building OS images. Again, they only forgot to tell everyone else to stop using git…

Both repositories diverged to the point of being almost incompatible. Issues in Perforce code were given to git teams, which resulted in a litany of WTFs. After all, there’s not many things more fun than being tasked with fixing a bug in code that you physically don’t have. ASAP. Meetings took place, arrangements were made to rectify the situation. Months later, the situation is still the same.

One implication was code review process. With gerrit in place, that was a non-issue. But the Korean teams didn’t (and still don’t) understand the notion of code review and pushed everything directly to the repo. The quality of some patches was so bad that enforcing code review became top priority for non-Korean teams. Finally, a solution was developed – MS Word based code review. Each changeset needs to be attached to a bug in the tracker. Each bug can have a Word document attached with a request for code review. That document is a three pages long form with information so useless, nobody even wants to read it. At the end there’s a place for copy-pasting a diff for each file changed, with the explanation why. Reviewers are supposed to fill a Word form with details about which line they comment on and what their issue with it is.

Submitting a patch, clicking through the awful issue tracker and filling the form takes literal hours. All this because using git with gerrit was too tough. Fortunately, the review form has fields listing times taken by various steps in fixing a bug. Maybe someday someone will read how long pushing the code actually takes.

No, they won’t.

 

https://what.thedailywtf.com/topic/15687/code-review-malediction