아는 것과 실행하는 것

"아는데 지금은 바빠서 못한다."라고 하는 말을 종종 듣는다.

"개발을 체계적으로 해야 하는데 지금은 그럴 여유가 없다."

"소프트웨어 개발을 할 때 문서를 제대로 써야 하는 것을 알고 쓸 줄도 아는데 시간이 없어서 그렇게 할 수 없다."

"Peer review를 해야 하는데 그럴 시간이 없다."

"시간이 걸리더라도 신입 개발자들에게 시켜야 하는 일이지만 너무 급해서 내가 직접 한다."

가만히 얘기를 들어보면 시간만 있으면 뭐든지 다 할 수 있을 것 같이 얘기를 한다. 그리고 또한 다 할 줄 안다고 한다.

이런 얘기를 하는 사람들의 대부분은 해본적도 없고 할 줄도 모른다는 것이다. 또한 시간이 아무리 많이 있어도 그렇게 하고 싶은 생각은 없을 것이다.

이런 것이 필요하다는 것을 알고 있다면 이미 시행하고 있을 것이다. 시간이 없어서 소프트웨어 공학을 적용하지 못한다는 것은 핑계이거나 소프트웨어 공학이 무엇인지 전혀 모르고 있는 것이다.

문제는 이런 사람들이 분위기를 흐린다는 것이다. 소프트웨어 공학이 마치 필요는 하지만 지금은 아닌 것 같은 착각을 하게 된다. 소프트웨어 공학은 1명이 개발하더라도 필요하고 10,000명이 개발하더라도 필요한 것이다. 목적은 단 한가지, "일정과 비용"을 줄이기 위한 것이다. 

시간이 없어서 그렇게 못하고 있다면 소프트웨어 공학이 뭔지 잘 모르고 시행하는 방법을 모르고 있었던 것 뿐이다.

맨날 건강을 위해서 운동을 해야 하는데 지금은 바빠서 운동을 못하고 있다고 얘기하는 것과 똑같다. 이런 사람은 시간이 남아 돌아도 운동을 하지 않는다. 운동이 재미 있어야 하는 것이다. 

소프트웨어 공학을 적용하여 개발을 하면 더 재미 있어진다. 경영자 입장에서는 비용이 줄어든다. 그렇지 않다고 생각하고 있는 사람이 있다면, 또는 알고는 있는데 지금은 바빠서 못한다고 생각하는 사람이 있다면, 소프트웨어 공학이 무엇인지 잘못 알고 있는 것이 아닌가 다시 한번 생각해보는 것이 좋다.

작은 회사에서 희망을 보다.

흔히 우리나라 소프트웨어 업계는 희망이 없고 SW개발자는 4D (Dirty, Difficult, Dangerous, Dreamless) 업무를 하고 수행하고 있다고 생각한다.

제대로 된 방향으로 이끌 맨토가 부족해서 선순환 하지 못하는 업계에서 Global 경쟁력을 갖춘 소프트웨어 회사는 많지 않다. 하지만 아직은 부족하지만 Global 시장에서 성공할 가능성이 있는 작은 회사들이 눈에 띄는 것은 희망적이다. 

큰 회사보다 작은 회사에서 더 희망을 볼 수 있는 것은 의외일 수 있다.

SW 회사들 중에 큰 회사는 개발자가 수백명이고, 매출액이 수백억, 순이익이 100억 이상인 회사들이 꽤 있다.

이렇게 외형적으로 좋아 보이는 회사들이 미래가 어두운 경우가 많은 것은 믿어지지 않을 수 있다. 

(물론 흔하지는 않지만 정말 좋은 회사도 종종 있다.)

이런 회사가 미래가 어두운 이유는 여러가지가 있겠지만 주된 이유는 회사의 성장 과정에서 볼 수 있다. 많은 경우 개발 역량을 키우고 뛰어난 제품을 개발하기보다는 영업력으로 성장을 해오면서 개발프로세스는 엉망이고 여전히 단기적인 이익을 쫒으며 눈앞의 목표에만 목을 맨다. 

경영자가 변화를 하려고 해도 방해하는 세력이 많고 반대하는 세력의 그럴듯한 이유를 거부할 수 있는 힘이 경영자에게는 없다. 또한 개발자는 변화를 싫어해서 이에 동조한다.

물론 경영자가 문제 상황의 핵심을 제대로 파악하고 있지 못한 경우도 많다. 

매출액 1,000억을 목전에 두고 성장의 한계에 다다랐고, 쇄락의 미래밖에 보이지 않는다. 1,000억의 한계는 어떤 SW분야든 우리나라 경제 규모에서 내수 시장만 공략해서 넘기 힘든 벽으로 생각된다. 즉, Global 경쟁력 없이는 이쯤에서 꺽이는 것이 당연하다.

신규투자는 순이익 감소 때문에 경영자가 쉽게 결정하지 못하는 경우도 많다.

이미 경쟁력을 잃은 개발 조직은 더 좋은 제품을 만들어 내지 못하고 계속 비용만 증가시키곤 한다.

이런 회사는 살아남기 위해서는 뼈를 깍는 변화의 고통을 이겨내야 한다.

하지만 작은 회사 중에서 희망적인 경우는 어떨까?

비록 매출액은 10억 안팎에서 20~30억, 순이익도 몇억 정도. 

작은 회사지만 즐겁게 일하고 독자적고 독보적인 기술력을 가지고 있는 경우가 많다.

이런 경우도 뛰어난 기술력에 비해서 소프트웨어 공학 경험은 부족해서 문제는 있지만 조직이 워낙 작아서 아직 문제가 심각해지지 않은 상태이다.

결정적으로 중요한 것은 경영자가 개발자 출신인 경우가 많고 변화에 관심이 많고 방해 세력도 거의 없다는 것이다. 개발자들도 아직 기득권 세력으로 자리를 잡지 않아서 오픈마인드인 경우가 많다.

이런 회사라면 경영자가 주도하는 변화에 무리없이 직원들이 따라오게 된다.

물론 대기업이라면 경우가 다르기 때문에 예외로 한다. 왜냐하면 대기업은 소프트웨어 개발 능력외에도 다른 경쟁력을 가지고 있기 때문이다. 

또한, 중견 SW회사는 희망이 없다는 것은 아니다. 규모가 큰만큼 변화에 훨씬 많은 노력을 들여야 가능하다는 것이다.

몇년 안에 이런 작은 SW 회사들 중에는 세계적으로 이름을 날릴 회사가 여러개 나올 것이라고 생각한다. 내가 이런 작은 회사에 관심이 많은 이유이다.

소스코드 Conflict

소스코드 Conflict는 두 명의 개발자가 같은 소스코드를 동시에 다르게 수정한 경우를 말한다.

소스코드관리시스템에서는 이런 소스코드 Conflict가 일어났을 경우 대부분 효과적으로 Merge를 해준다.

하지만 개발자들이 같은 줄을 서로 다르게 수정했을 경우에는 자동으로 Merge가 안된다. 이런 경우에는 사용자가 직접 Merge를 해야 하고 이때 이용하는 것이 Merge Tool이다.

많은 회사들이 Merge에 대한 두려움 때문에 소스코드 Conflict가 나지 않도록 각 소스코드 파일의 담당자를 정해서 담당자만 해당 소스코드를 수정할 수 있도록 하고 있다. 이런 방법은 소스코드관리시스템를 잘못 사용하고 있는 예가 되겠다. 이런 방식의 개발은 개발 시간이 더 오래 걸리고 서로 공유가 안되는 등의 여러가지 문제를 일으킨다.

Merge Tool은 크게 2-way와 3-way방식으로 구분이 되며 3-way Merge는 블로그에 많은 글들이 있으니 참조할 수 있다.

2008/11/21 - [기반시스템/소스코드관리] - Diff and Merge in SCM(Software Configuration Management)
2009/02/25 - [기반시스템/소스코드관리] - Merge Tool(머지툴) 비교 - (3way merge 기능) - 수정

3-way Merge 툴을 이용하면 쉽게 Merge를 할 수 있지만 애초에 Conflict가 발생하지 않게 소스코드를 작성하는 것이 더 좋다.

같은 내용을 코딩하더라도 코딩하는 방법에 따라서 Conflict가 일어나게 또는 일어나지 않게 소스코드를 작성할 수 있다.

근본적으로는 설계를 잘 해서 컴포넌트가 잘 나뉘어지고 인터페이스가 초기에 확정이 되어서 잘 유지되면 Conflict를 줄일 수 있다.

변수 선언이나 여러 구문에서 한 라인에 너무 많은 코드를 적지 않아야 한다. 줄을 효과적으로 잘 나누는 것이 좋다. 또한 코드를 추가할 때 기존의 Line에 끼어 넣기 보다는 새로운 라인을 추가하는 것이 좋다.

소스코드를 수정하고 있을 때 다른 사람도 같이 고치고 있다는 생각을 항상 하고 있는 것이 좋다.

그리고 소스코드를 괜히 줄을 맞추지 말고, 이유 없이 라인을 이동하지 않아야 한다.

현재 혼자서 개발하고 있는 것이 아닌데 Conflict에 대해서 전혀 걱정을 하고 있지 않다면 오히려 문제가 될 수 있는 상황이다. (사실은 혼자 개발을 해서 Conflict가 일어나고 여러명이 동시에 병행 개발할 때와 똑같다. 왜 그런지 이해하시는 분은 댓글을 달아주면 어떨까요? ^^ )

Conflict는 항상 일어날 수 있다고 생각하고 가능하면 줄이는 노력을 해야 하고 Conflict가 발생했을 때 Merge를 능숙하게 할 수 있어야 한다.

경영진이 너무 촉박한 일정을 제시합니다.

나는 프로젝트 일정에 대해서 항상 "일정은 개발자가 산정해야 한다"고 얘기를 해왔다.

그런데 많은 개발자들과 얘기를 해보면 자신들은 도저히 그렇게 할 수 있는 상황이 아니라고 한다. 일정은 위에서 확정이 되어서 내려오기 때문에 개발자가 정할 수 없다고 한다. 또한 항상 촉박한 일정을 지시하기 때문에 스펙이나 설계는 작성할 수도 없고 코딩부터 한다고 한다. 자신들도 체계적으로 개발을 하고 싶지만 도저히 그럴 시간이 없다고 한다.

경영진이 일정을 제시하는 것과 개발자가 일정을 산정하는 것은 완전히 상반된 얘기가 아니다.

경영진은 어떤 프로젝트를 진행하기 위해서는 일정이 필요하다. 경영진이 일정을 정했다고 해서 불가능한 일정이 가능해지는 것은 아니다. 프로젝트는 들어가야 할 시간은 다 들어간다. 자칫 서두르다가 더 느려질 수 있다.

경영진이 지시한 일정은 경영자의 입장에서 필요한 일정을 제시한 것이다. 이 일정은 변경해도 되는 경우도 있고 절대 변경하면 안되는 경우도 있다.

어떠한 경우라도 이 일정을 지키는 가장 좋은 방법은 개발자가 일정을 산정하는 것이다.

일정을 산정하기 위해서는 스펙을 제대로 쓰고 1,2일 단위로 상세 일정을 개발자가 산정해야 한다. 이쯤되면 전체 일정에서 20~30%의 시간이 지난 시점이 된다.

이때 상당히 정확한 일정이 나오면 경영진이 지시한 일정을 지키기 위한 방법을 강구할 수 있다. 이 일정이 경영진이 제시한 일정과 차이가 없다면 다행이지만 촉박한 일정이라면 스펙을 조정하거나, 개발자를 더 투입할 수 도 있다. 아직 설계, 구현이 본격적으로 시작되지 않았기 때문에 스펙 조정이 가능하고 개발자를 추가 투입해도 상당히 효과가 있다. 

스펙도 조정이 안되고 개발자 추가투입도 어렵고 무조건 밤을 새가면서 일하는 수밖에 없다면 그것도 하루이틀이지 어차피 불가능한 일을 하고 있는 것입니다. 불가능하다는 것을 일찍 알아내는 것도 중요합니다. 불가능한 일을 밀어 붙인다고 가능한 일로 바뀌지는 않습니다. 기적은 일어나지 않습니다.

스펙이 끝날 때까지 손놓고 있는 것이 아니고 스펙을 쓰는 도중에도 일정이 촉박할 것으로 예상이 되면 리스크관리를 통해서 미리 대비를 할 수 있다. 

경영진이 촉박한 일정을 지시했다고 해서 이것을 돌판에 새긴 절대불변의 지시사항으로 생각하고 코딩부터 시작하면 나중에 할 말은 다음과 같은 것들 밖에 없다.

• 매일 밤새면서 일했는데 못 지켰습니다. 원래 불가능한 일정이었어요.
• 코딩은 끝났는데, 테스트는 못했습니다.

이런 핑계를 대도 사실 코딩도 안 끝난 경우도 많다. 코딩은 가능하면 늦게 시작해야 기능을 빼거나 변경하기 쉽고 더 일찍 끝낼 수 있다.

경영진은 개발자들이 합리적인 방법을 제시하고 일정을 지켜주기를 원한다. 그래야 비즈니스를 할 수 있기 때문이다.

시간이 부족해서 스펙을 적을 수 없는 것이 아니고 시간을 절약하기 위해서 스펙을 적어야 일정을 지킬 수 있는 방법이 나온다.

경영진이 6개월의 시간을 제시했다면 앞만보고 마구 달리는 것보다는 가장 빠른 시간에 6개월안에 프로젝트를 끝내는 방법을 마련해야 한다. 경영진은 이런 합리적인 방법을 제시하는 개발팀을 후원할 것이다. 가장 빠른 기간에 프로젝트를 일정에 맞게 끝낼 수 있게 방법을 마련하는 방법이 바로 적절한 스펙을 작성하는 것이다.

어제 일도 기억하지 못하는데...

개발자들은 동서고금을 막론하고 대부분이 문서화를 싫어하는 경향이 있다. 문서화는 시간이 많이 걸린다고 생각하고 기껏 정리를 해 놔도 남들이 잘 이해하지 못하기 때문이다.

이 생각에 동의한다면 문서화 자체를 완전히 잘못 생각하고 있는 것이다. 문서화를 지금 개발하고 있는 것을 기록해서 나중에 다른 사람들이 활용할 수 있게 한다는 추가적인 작업으로 생각하고 있을 가능성이 높다.

문서화에 대한 생각을 완전히 바꿔보자.

대부분의 개발자들은 기억력이 매우 좋다고 생각하지만 의외로 그렇지 않다. 특정 부분에 있어서 뛰어난 기억력을 발휘하는 경우는 있다.

갑자기 머리에서 번뜩인 아이디어를 10초안에 정리하지 않으면 영원히 사라져 버리는 경우는 흔하다. 하물며 수많은 내가 하고 있는 해야 하는 일들은 시간이 흐르면 내 머리 속에서도 사라져 버린다. 이런 것들을 사라지기 전에 기록한다고 생각하자. 그러려면 특정 형식에 얽매이지 않고 어디서나 기록을 할 수 있 툴들이 필요하다.

간단한 메모장에서 부터 스마트폰과 연동하는 노트 앱이나 클라우드에 저장하는 메모 앱들도 있다. 마인드맵을 이용하는 방법도 있다. 용도에 따라서 다양한 방법들은 각자 구미에 맞는 것들을 선택하면 된다.

이렇게 항상 메모하는 습관을 가지고 있으면 의외로 엄청난 변화를 경험하게 된다. 머리 속에만 있던 생각이 글자로 적히게 되면 점점 발전되어서 머리속 가지고 있을 때보다 가치있게 된다. 또한 다른 사람들과 공유가 가능하고 다른 사람들의 생각과 합쳐서 더 좋은 아이디어로 발전하기도 한다.

이런 메모 습관은 글을 작성하는 것에 대한 거부감을 줄여나가고 개발문서 작성할 때도 도움을 주게 된다. 

나는 오랫동안 메모를 해 왔다. 

아주 오래 전에는 작은 수첩에 메모를 하는 것이 가장 효율적이었다. 그 때는 이를 다시 정리하는 시간이 필요해서 꽤 불편했었다. 하지만 이제는 너무나 좋은 툴들이 너무나 많아서 좋은 것을 선택하는 것이 오히려 어려울 정도다.

과거 OneNote를 사용한 적도 있지만 이제는 Evernote를 이용하고 있다. Evernote는 그동안 메모를 하면서 생각하고 있던 요구사항을 거의 모두 만족한다. 물론 이것 외에도 좋은 툴들이 많으니 입맛에 맞는 것을 선택하면 된다.

우선 아이폰을 이용해서 "텍스트", "음성", "카메라" 메모를 모두 쉽게 남길 수 있다. 이렇게 남긴 메모는 아이폰, 맥, PC에서 모두 접근 할 수 있고 편집할 수 있다. 게다가 무료이다. (유료서비스도 있음)

신기한 기능 중에 하나는 "카메라"로 촬영한 이미지 안의 "텍스트"도 검색이 되는 것이다.

설계 회의를 하다가 화이트보드에 그려 놓은 그림을 사진을 찍어 놓으면 내용을 검색할 수 있는 것이다.

여기에는 거의 모든 내용을 항상 기록한다. 길을 가다가 생각난 모든 것을 기록한다. 스펙을 작성할 때도 이렇게 모인 자료들이 많이 활용된다.

문서화를 남을 위한다고 생각하지 말고 자신이 일을 할 때 자신을 위해서 항상 기록한다고 생각하면 문서화 실력도 조금씩 더 향상될 것이다. 다시 한번 생각하자. 남을 위한 것이 아님을.

A/B는 뭘까?

A/B는 무슨 뜻일까?

A and B일까?

A or B일까?

A와 B가 같다는 뜻일까?

B가 A를 대체할 수 있다는 뜻일까?

스펙(SRS)를 적다보면 의외로 정확하게 적는 습관이 없다는 것을 알게 되다. 하지만 이러한 모호함은 소프트웨어를 개발하는데 큰 방해가 되고 비싼 댓가를 치를 수도 있다.

적는 사람은 당연하다고 적은 것들이 이것을 읽는 사람은 헷갈릴 수 있습니다. 따라서 괜히 몇바이트 절약하기 위해서 애매한 축약을 할 필요가 없다.

OS가 맞을까? O/S가 맞을까?

SW가 맞을까? S/W가 맞을까?

NW가 맞을까? N/W가 맞을까?

"전후"를 써야하나? "전/후"를 써야 하나?

rw와 r/w의 차이를 구분할 수 있나?

MS와 M/S의 차이는? 이것은 Market share일까? Microsoft일까?

이것을 가지고 고민할 필요는 없다. 일단 애매할 수 있다면 풀어쓰는 것이 좋다. 

정답이 있다고 하더라도 누군가가 헷갈려하는 사람이 있다면 그 자체가 문제이다.

그럼 MM과 M/M 중 어떤 것이 맞을까? (Man-Month의 단위로 인력 투입량을 뜻함)

이는 Man x Month를 뜻하는 것으로 MM이 맞다. 하지만 M/M을 쓰는 사람들이 의외로 많다. Man x Month와 Man/Month는 완전히 다른 단위이므로 앞으로 틀린 단위는 사용하지 않는 것이 좋겠다.

스펙문서(SRS)뿐만 아니라 소프트웨어 개발자라면 문서를 작성할 때 항상 정확하고 읽는 사람들이 헷갈리지 않다록 작성하는 습관을 들여야 한다.

내가 소스코드를 몰래 고치는 이유

여러 소프트웨어 회사를 분석해보면 소스코드를 공유하는 정도에서 정말 많은 차이가 난다.

여기서 소프트웨어 회사란 소프트웨어를 개발하고 있는 회사로서 흔히 얘기하는 팩키지 소프트웨어 회사가 아니다.

SI회사, 가전회사, 산업로봇회사, 반도체장비회사, 인터넷회사, 게임회사, 금융회사 등의 다양한 회사를 모두 말한다.

이들 회사 중에서는 개발자가 소스코드를 몰래 고치고 공유도 하지 않는 회사들이 의외로 많다.

개발자가 소스코드를 몰래 고치는 이유에는 이건 것들이 있다.

내 소스코드는 나만 알아야 회사에서 나의 파워가 유지된다.

일부 일리가 있는 이론이다. 내가 없으면 내가 작성한 소스코드를 이해하지도 고치지도 못하면 나는 절대로 짤릴 수가 없다. 문제가 있을 때마다 나에게 달려와서 이것 좀 고쳐달라고 하면 내가 좀 대단한 사람이 된 것 같은 생각도 든다. (이전에 블로그에 포스트한 글 참고)

2009/04/28 - [사람과 기술] - 과거의 개발자 vs. 미래의 개발자

실제로 실력이 있는 개발자들이 이런 행동을 하기도 한다. 하지만 이런 행동은 본인의 성장에 방해가 된다. 더 어렵고 가치있는 해야 할 사람이 과거의 소스코드에 발목잡혀서 휴가도 마음대로 못가게 된다. 개발자의 파워 및 가치는 과거에 있는 것이 아니고 미래에 회사에 필요한 가치에 있다는 것을 알아야 한다. 그것이 회사와 개발자의 상생의 기초이다.

내가 작성한 소스코드의 품질이 형편없어서 보여주기 창피하다.

어떤 천재 개발자도 공유하지 않고 혼자 개발을 해서는 좋은 코드를 작성하기 어렵다. 꾸준히 공유를 하면서 다른 사람들과 의견 교환을 통해서 점점 나아진다. 혼자 개발한 코드는 이상한 코드로 가득차 있기 마련이다. 

세 사람이 걸어가면 그 중에는 꼭 스승이 있듯이 신입사원과 코드 리뷰를 해도 배울 것이 나오게 된다.

소스코드를 보여주는 것을 창피해 할 것이 아니라 자꾸 보여주고 교류를 해야 나아진다.

엄청 어려운 것을 개발하고 있는 것처럼 행동했는데 소스코드를 보면 별 것 아니라는 것이 들통날 것 같다.

종종 접하는 문제다. 심지어는 오픈소스코드를 가져다가 동료들에게는 자기가 개발한 것 같이 자랑하는 경우도 있다. 이것은 회사입장에서 더 큰 문제가 될 수도 있다. 오픈소스 라이센스 규정을 어겨서 소송을 당할 수도 있다.

스펙을 적절하게 작성하고 설계를 하는 과정들에서 서로 리뷰를 적절하게 한다면 서로 어떤 컴포넌트를 어떤 Technology를 이용해서 개발하는지 다들 알게 된다. 어떤 것은 어렵고 어떤 모듈은 신입사원이 구현해도 될 만큼 쉬운 것인지 모두 알게 된다. 

SRS를 제대로 작성하게 된다면 모든 프로젝트 관련자가 프로젝트가 어떻게 구성되어 있고 어떻게 진행되고 있는지 훤히 할게 된다.

너무 바빠서 공유할 시간도 없다.

이미 불끄기 모드로 들어간 회사는 단기적인 해결책이 없다. 이런 회사에서는 서로 자기일 하기 바빠서 점점 서로 더 단절되게 된다. 또 다시 악순환이 진행된다.

2011/01/03 - [개발문화] - 매일 불난 호떡집 같은 회사 (중요한 일 vs. 시급한 일)

시간이 좀 걸리겠지만 악순환의 고리를 끊어야 한다.

공유를 해봤자 관심도 없다. 다들 바쁜데...

공유문화가 정착되지 않은 회사이다. 이런 회사에서 코드리뷰는 별 의미도 없다. 

시도를 해봤자 시간 낭비일 것이다. 내용을 모르는데 코드리뷰를 해도 기껏해야 Syntax 검사밖에 못할 것이다.

SRS리뷰를 먼저 시작하는 것이 좋다. SRS가 리뷰를 해야 할 것도 더 많고 SRS가 제대로 작성되어야 다음 단계인 설계, 구현이 제대로 진행되며 리뷰를 해도 내용을 알고 리뷰를 할 수 있게 된다.

이렇게 되면 "바쁜데..."라는 핑계가 조금씩 줄어들만큼 시간을 절약할 수 있게 된다.

결론

개발자가 작성하는 모든 소스코드는 기록이 남아야 하고 남게 된다. 물론 분석, 설계도 마찬가지이다.

Baseline에 포함되는 소스코드와 문서들은 소스코드 관리시스템에 들어갈 때 설명을 적절하고 충실하게 달아야 한다. 이때 이 소스코드를 누가 리뷰했는지 기록을 남기기를 권장한다. 리뷰를 했다는 의미는 소스코드 작성자와 같이 이 소스코드에 대해서 공동책임을 진다는 의미이기도 하다. 이것이 부담스러워서 리뷰를 하지 않는다면 아무도 리뷰를 하지 않을 것이다. 서로 리뷰를 해주는 것은 모두에게 도움이 되는 것이다. 이것은 규칙으로 강요를 해서는 효과가 없고 분위기가 조성되어서 오랫동안 시행을 하여 문화로 자리를 잡아야 한다.

소스코드관리시스템에 소스코드를 올릴때는 버그ID(이슈ID)가 꼭 있어야 한다. 개발자가 원한다고 아무때나 마음대로 소스코드를 고치면 안된다. 개발자가 스스로 발견한 버그를 고칠 때도 버그관리시스템에 등록을 하고 고쳐야 한다.

이렇게 개발자가 생성한 모든 소스코드는 투명하게 모두가 볼 수 있게 한다면 이 혜택은 회사 뿐만 아니라 모든 개발자 그리고 본인에게도 돌아한다.