http://korean.joelonsoftware.com 에서 한국어로도 연재가 되고 있는 조엔 스폴스키의 블로그 글들을 모아 번역해 놓은 책.
오늘 아침에 편의점에서 책을 받아서 벌써 다 읽어버렸다. 다 읽었다기 보다는 필요한 부분과 예전에 블로그에서 읽었던 부분은 Skip...
사람들의 평이 대단해서 얼마나 대단한가 하고 읽어봤는데 정말 대단한 책이다.
특히 개발시에 계획, 설계, 일정관리의 중요성을 강조하고 쉽게 예를 들어준 부분은 나에게 지금 당장 필요한 부분이고,
쏘면서 움직여라는 나태해지려는 나에게 일침을 쏳아주었고,
전략 메모에서는 회사에 대해서 다시 한번 곰곰하게 생각하게 해준다.
저자의 말따라서 고민하지 말고 시작하라! 쏘며서 움직여라! 를 실천하기 위해서..
지금 당장 기능명세서와 일정관리 등을 재정비해야겠다.
암튼 프로그램 개발자, 관리자, 경영자 등의 필독책...
책에 없는 글들은 위에 링크로 가면 마저 읽을수 있음.
<도서 정보>
제 목 : 조엘 온 소프트웨어 - 유쾌한 오프라인 블로그
저 자 : 조엘 스폴스키
출판사 : 에이콘출판
출판일 : 2005년 4월
구매처 : Yes24
구매일 : 2005/5/4
일 독 : 2005/5/6
재 독 :
정 리 : 2005/8/17
<이것만은 꼭>
버그 수정을 최우선으로 하라!
- 버그를 수정하는 시기를 뒤로 미룰면 미룰수록, 수정과정에 더 많은 시간과 돈이 들어간다.
- 언제든지 출시 준비 상태로 유지되므로 무척 발 빠르게 대응할 수 있다.
일정을 지속적으로 업데이트하라!
- 일정계획을 짜야 필요없는것들을 뺄수 있다.
- 일정을 짜는 과정에서 가장 중요한 부분은 과업목록을 작성하는 작업이다.
- 과업을 세부적으로 나누어라. 얼마가 걸릴지 모르는것은 세부적으로 나누라는 신호이다.
(기능)명세서를 작성하라!
- 설계단계에서 문제를 발견하면 텍스트 몇줄만 수정하면 되지만, 코딩 완료후 문제를 수정하면 시간및 비용이 급격히 상승한다.
- 명세서가 없으면 설계는 형편없으며, 일정은 통제를 벗어나기 마련이다.
- 의사소통의 시간이 절약된다.
- 세부명세서가 없이는 일정을 계획하기가 불가능하다.
- 개괄, 저자, 시나리오, 회피목표, 흐름도, 화면단위명세, 세부사항, 미해결문제
- 최대한 단순하게 작성하라
고민하지 말고 바로 시작하라! 쏘면서 움직여라!
- 장기적인 안목을 키워야 하며, 매일 조금씩 앞으로 나아가라! 이렇게 하다보면 조만간 당신이 이길 것이다.
자동으로 충돌보고서를 수집하라.
- 오류 발생시 질문을 하나 던지고, 답변을 받아라.
기존 경쟁업체가 있다는 사실 때문에 지레 겁먹을 필요는 없습니다. 모든 업종에는 경쟁업체가 있습니다. 벼룩시장이 있지 않습니까! 그러니 기운을 내십시요. 기존 제품보다 우수한 면이 있다면, 충분히 고객을 끌어올 수 있습니다. 그러나 전략적으로 사고해야 합니다. 전략적 사고란 눈에 보이는 이상으로 한 걸음 더 나아가야 한다는 뜻입니다.
사용자가 제품을 바꾸게 하는 유일한 전략은 걸림돌 제거입니다.
- Solomon에 대해 알아야 한다. Solomon이 나은 점을 알아야 한다.
- Solomon을 구매해야 한다.
- 기존 자료를 Solomon으로 변환해야 한다.
- 새 사용자 인터페이스를 배워야 한다.
차분히 계산해 보면 기존 시장에 진입하기 위해서는 걸림돌제거가 가장 중요하다는 사실을 알 수 있습니다. 엑셀은 걸림돌 목록을 검토한 후 전 항목에 대한 해결책을 강구했습니다.
잠재고객은 아직 정식 고객이 아닙니다. 고객이 되기도 전에 빠져 나가지 못하게 문을 닫아거는 시도를 한다면, 오히려 고객이 들어오지 못하게 문을 닫아거는 셈이 됩니다. 마음에 들지 않을 경우 서비스를 중단하기 쉽다고 정직하게 약속하는 순간, 진입을 가로막던 걸림돌 하나가 사라집니다.
<미디어 리뷰>
http://www.acornpub.co.kr/new2/book/info/bookdetail.asp?bkcode=1297
조엘 스폴스키 (Joel Spolsky) - 미국 거주 이스라엘인으로, 빵 공장에서 파스칼로 제어 프로그램을 작성한 이후, 펜실베니아 대학교, 벨 연구소 인턴, 마이크로소프트 인턴, 예일 대학교, 마이크로소프트 프로그램 관리자, 비아컴 연구원, 주노 온라인서비스 기술관리자 등으로 일했다. 최근 포그크릭 소프트웨어(http://www.fogcreek.com)를 설립했다.
2005년 15회 JOLT상 수상작!
아마존 선정 컴퓨터 인터넷 부문 10대 도서.
Java.net 선정 개발자 · 관리자 필독서.
조엘 온 소프트웨어는 조엘 스폴스키가 운영하는 유명한 소프트웨어 개발 블로그인 조엘 온 소프트웨어(http://www.joelonsoftware.com)에 수록한 주옥같은 글 중에서 특히 독자들이 관심을 보일 만한 베스트를 뽑아 엮은 책이다. 조엘은 딱딱한 소프트웨어 공학 서적에서 찾아보기 어려운 소프트웨어 개발자의 애환과 톡톡 튀는 생각을 수필에 가까운 부담 없는 필체로 기술하고 있다. 따라서 최전선에서 소프트웨어를 직접 만드는 개발자를 비롯해 후방에서 병참을 지원하는 관리자에 이르기까지 소프트웨어와 관련이 있는 누구나 부담없이 읽을 수 있는 내용으로 가득차 있다.
이 책에서는 사람을 고용하고 동기를 부여하는 방법, 작업 일정을 예측하고 관리하는 방법, 소프트웨어 기능을 설계하고 실제로 유용하게 사용하도록 명세하는 방법, 소프트웨어 개발 과정에서 생기는 함정을 피하는 방법, 팀을 구성하고 동기 부여하는 방법, 재사용과 NIH(Not-Invented-Here) 신드롬, 소프트웨어 일정이 지연되는 것처럼 보이는 이유, 여러 가지 사례를 통한 소프트웨어 회사의 명암에 대해 논하고 있다. 때로는 유머러스하게 때로는 날카롭게 문제점을 지적함으로써 당신이 아키텍트이거나 개발자거나 관리자거나 상관없이 소프트웨어 개발과 관련해서 여러 가지 각도에서 기존에 간과하고 있던 부문까지 생각이 미칠 수 있도록 도와준다.
조엘 스폴스키는 다양한 경험을 토대로 재미있으면서도 핵심을 찌르는 글을 쓰기로 유명하다. 조엘은 '최신 개발 방법론이나 최신 개발 도구에 발목이 잡힌 나머지 나무는 보되 숲은 보지 못하는 개발자에게 다양한 방법으로 경종을 울려준다. 조엘 온 소프트웨어를 펼치는 순간 소프트웨어 세계에서 벌어지는, 지극히 당연한 듯이 보이면서도 지금까지 구체적으로 생각해보지 못했던 여러 가지 뒷이야기를 만날 수 있을 것이다.
<책속으로>
-차례-
미디어가 앞다퉈 보도한 조엘 온 소프트웨어
한국어판 출간에 즈음해 (조엘 스폴스키)
지은이 조엘 스폴스키 소개
옮긴이의 말, 하나 : 박재호
옮긴이의 말, 둘 : 이해영
들어가며
1부 비트와 바이트: 프로그래밍 실전
1장. 언어 선택
2장. 기본으로 돌아가기
3장. 조엘 테스트: 더 나은 코드를 위한 12단계
4장. 모든 개발자가 꼭 알아둬야 할 유니코드와 문자 집합에 대한 고찰
5장. 손쉬운 기능명세 작성법 1강. 명세서 작업이 귀찮습니까?
6장. 손쉬운 기능명세 작성법 2강. 명세가 뭡니까?
7장. 손쉬운 기능명세 작성법 3강. 하지만 어떻게?
8장. 손쉬운 기능명세 작성법 4강. 팁
9장. 손쉬운 소프트웨어 일정관리법
10장. 일일빌드는 당신의 친구입니다.
11장. 고리타분한 버그 수정
12장. 다섯 가지 세상
13장. 종이 프로토타이핑
14장. 화성인 아키텍트를 조심하세요.
15장. 쏘면서 움직여라.
16장. 장인정신
17장. 컴퓨터 과학 분야에서 떠도는 세가지 미신
18장. 더불어 살기
19장. 자동으로 충돌 보고서를 수집하세요.
2부 개발자 다루기
20장. 인터뷰를 위한 게릴라 가이드
21장. 성과급은 오히려 해가 된다.
22장. 테스터를 두지 않는 (잘못된) 이유 다섯 가지
23장. 개발자는 멀티태스킹 기계가 아닙니다.
24장. 당신이 결코 하지 말아야 하는 일, 제1부
25장. 드러난 빙산의 비밀
26장. 허술한 추상화의 법칙
27장. 프로그래밍 세계에서 파머스톤 경
28장. 측정
3부 조엘 따라하기 : 두서 없는 생각, 하지만 놓쳐서는 안될 이야기
29장. 릭 채프먼이 아둔함을 찾습니다.
30장. 이 나라에서는 개가 무슨 일을 하죠?
31장. 말단이면서도 해내기
32장. 이야기 둘
33장. 빅 맥 對 제이미는 요리사
34장. 세상에 쉬운 일은 없습니다.
35장. NIH 신드롬을 옹호하며
36장. 전략 메모 I: 벤 앤 제리 對 아마존
37장. 전략 메모 II: 닭이 먼저냐, 달걀이 먼저냐
38장. 전략 메모 III: 돌아가게 해주세요!
39장. 전략 메모 IV: 블로트웨어와 80/20 미신
40장. 전략 메모 V: 오픈소스 경제학
41장. 머피의 법칙이 난무했던 한 주
42장. 마이크로소프트 사가 API 전쟁에 진 이유
4부 .NET에 대한 쓴소리
43장. 마이크로소프트가 난관에 부딪히다.
44장. 우리의 .NET 전략
45장. 저기, 링커 좀 주시면 안될까요?
5부 하나 더
조엘에게 물어보기, 가장 재미있었던 질문
찾아보기
책 표지에 대해
< 한국어판에만 있는 유쾌한 보너스 >
조엘이 권장하는 '대학생이 갖춰야 할 지식' 목록
Windows 한글 표기가 윈도즈가 아니라 윈도우인 까닭
유닉스 매뉴얼 페이지가 읽기 어려운 이유
마이크로소프트 사와 일일 빌드
조엘 온 소프트웨어 베타리더 활약상
베타리더 한마디
인터럽트와 프로그래머
MSDN이 자세한 이유
사무실 환경과 생산성
마이크로소프트 사의 소프트웨어 개발 방법
번역 중 겪은 에피소드
아마존을 들끓게 한 독자서평
더 나은 코드를 위한 12 단계
1. 소스코드 관리시스템을 사용하고 있습니까?
2. 한방에 빌드를 만들어 낼 수 있습니까?
3. 일일 빌드를 하고 있습니까?
4 .버그 추적 시스템을 운영하고 있습니까?
5. 코드를 새로 작성하기 전에 버그를 수정합니까?
마이크로소프트사는 프로젝트 관리자가 일정을 재촉한 나머지 프로그래머가 형편없는 코드라도 구현해서 서둘러 끝내려고 했음을 알게됐습니다. 정식 일정에 버그 수정 단계를 넣지 않았기 때문에 발생한 문제였습니다.
무결점 방법론(zero defect methodology), 어느 특정 시점에 모든 코드를 새로 작성하기에 앞서 버그 제거작업을 가장 높은 우선순위에 둔다(27)
골치 아픈 버그 추적에 사흘이 걸릴지 2분이 걸릴지는 두고 봐야 알겠지요?
이런 사실이 의미하는 바는 수정해야할 버그가 많을 때는 일정도 불안정하다는 것입니다. 알려진 모든 버그를 이미 수정했다면, 남은 일은 새로운 코드 작성 뿐이며, 차라리 이러한 방법이 정확한 소요일정을 예측하기에는 더 쉬울 것입니다.(29)
6. 일정을 update하고 있습니까?
7. 명세서를 작성하고 있습니까?
어떤 방법을 선택하든지 '명세없이는 코드도 없다'는 단순한 규칙을 일관되게 주장해야 합니다.(31)
설계단계에서 문제를 발견하면 텍스트 몇 줄만 수정하는 방법으로도 쉽게 해결할 수 있습니다. 하지만 코딩 완료 후에 문제를 수정하면 서로의 감정도 상하고(개발자는 코드 폐기를 싫어합니다) 시간 낭비는 물론이거니와 비용도 급격히 상승되어, 그 결과 실제로 문제를 수정하는 작업 자체에 저항이 따릅니다.(30)
8. 조용한 작업 환경에서 일하고 있습니까?
지식 노동자에게 조용한 작업 공간을 주고 사생활을 보장함으로써 얻는 생산성 향상은 많은 문헌에 타나있습니다. 고전이 된 소프트웨어 관리 서적인 피플웨어는 이런 생산성 문제를 광범위하게 다룹니다.
지식 노동자는 '무아지경'이라는 '흐름flow'에 빠져들어야 생산성을 최대로 발휘할 수 있다는 사실을 우리 모두 잘 알고 있습니다.(32)
문제점은 '무아지경'상태가 깨지기가 너무나도 쉽다는 사실입니다...동료 질문에 대답하는 시간은 1분에 불과하지만, 흐트러진 마음을 가다듬고 다시 생산성을 얻으려면 30분이나 더 걸리게 되어 전반적인 생산성에 심각한 문제를 초래합니다.(32)
9. 경제적인 범위 내에서 최고 성능의 도구를 사용하고 있습니까?
제가 직전에 일했던 회사의 시스템 관리자는 제게 서버쪽 개인 하드 디스크 사용량이 220MB를 넘었다고 스팸성 편지를 계속 보냈습니다. 이런 편지를 받아보신 적이 있습니까? 저는 220MB 공간을 제공하는 데 드는 비용은 화장실 휴지값보다도 적다고, 요즘 하드디스크가 얼마나 싼지를 지적했습니다. 10분 동안 디렉토리를 정리하기 위해 어처구니 없을 만큼 막대한 생산성이 낭비되는 상황을 그냥 눈감아버려야 할까요?(35)
10. 테스터를 별도로 두고 있습니까?
팀에 적어도 프로그래머 2~3명 마다 전문 테스터가 1명씩 붙어있지 않다면, 결함 투성이 제품을 출시하거나 시간당 3만원짜리 테스터가 수행할 작업을 시간당 10만원짜리 프로그래머가 수행하도록 돈을 낭비하고 있는 겁니다.(35)
11. 프로그래머 채용 인터뷰 때 코딩 테스트를 합니까?
12. 무작위 사용 편의성 테스트를 수행하고 있습니까?
명세서 작업이 귀찮습니까?
왜 명세서 작업을 하지 않을까요? 명세서 작업 단계를 건너뛰면 시간을 절약할 수 있다고 말합니다.
...모두 허튼소리입니다.(59)
"소스코드가 디자인입니다!" 라고 하지요. 절대 그렇지 않습니다. 소프트웨어 개발을 이런식으로 진행하면, 실제 작업 진행은 고사하고 소프트웨어 허상을 좇아 리팩토링만 계속하는 악순환에 빠지게 됩니다.(327)
인간 언어로 제품을 설계할 때, 여러 가지 성능 가능성을 따지고 수정하고 설계를 향상시키려고 시도하는 과정은 단 몇분이면 충분하다. 워드프로세서를 사용해서 문단을 지워버리는 것쯤이야 어느 누구도 기분 나빠하지 않습니다. 하지만 프로그래밍 언어로 제품을 설계할 때, 설계를 여러 차례 수정하는 작업은 몇 주를 까먹습니다. 그보다 더 중요한 점은, 어떤 코드를 작성하기 위해 몇주를 날린 프로그래머는 품질이야 어찌 되든 코드에 상당히 집착한다는 사실입니다..결과적으로 마지막 제품은 초기에 잘못된 설계와 이상적인 설계사이에 타협점을 찾으려는 경향이 있습니다.(63)
둘째 이유는 의사소통 시간의 절약입니다. 명세서 작업을 할 때, 프로그램을 어떻게 동작하게 할지만 알려주면 되고, 함께 일할 팀원은 이 명세서만 읽으면 됩니다.(63)
명세서를 확보해야만 하는 너무나도 중요한 셋째 이유는, 세부 명세서 없이는 일정을 계획하기가 불가능하다는 사실입니다.(65)
명세서 작업은, 명세서가 없다면 묻혀버릴 모든 짜증나는 결정사항을 못박아 버리는 멋진 방법입니다.(66)
명세가 뭡니까?
기능명세(functional specification)는 완전히 사용자 관점에서 제품이 어떻게 동작할지를 기술합니다. 어떻게 구현했는지는 신경도 쓰지 않습니다. 기능에 대해 이야기 하고, 화면, 메뉴, 대화 상자와 같은 사용자 인터페이스 부분을 명세합니다.
기술명세(technical specification)는 프로그램의 내부 구현을 기술합니다. 자료구조와, 관계형 데이터베이스모델과 프로그래밍 언어, 도구, 알고리즘 선택과 같은 항목을 다룹니다.(69)
명세는 지속적으로 개정해야 합니다 : 일부 프로그래밍 팀은 '폭포수' 사고 방식으로 무장하고 있습니다. 대부분 사람들은 모든 프로그램을 한번에 설계하고 명세를 적어 출력해서 옆 방에 있는 프로그래머에게 집어 던진다음에 집으로 갑니다. 제가 할 말은 '하하하하하'뿐이랍니다.
이런 접근 방식 대문에 명세에 대한 평판이 나빠집니다. 많은 사람들이 저에게 "명세는 쓸모없는 거야. 왜냐하면 아무도 명세에 따라 행동하지 않으며, 명세는 언제 읽어봐도 낡고 쓸모없으며, 결코 제품을 반영하지 않기 때문이지" 라고 말합니다.(81)
누가 명세를 작성합니까?
마이크로소프트사의 프로그램 관리자는 요구사항을 수집하고, 코드의 예상 동작을 이해해서 명세서를 작성합니다. 프로그램관리자마다 대략 프로그래머 5명을 붙입니다. 각 프로그래머는 프로그램 관리자가 명세형식으로 구현한 프로그램을 코드로 구현하는 책임을 맡고 있습니다.(85)
프로그램 관리자는 마음 속에 회사의 '큰 그림'을 염두에 두고 있어야 하며, 프로그래머는 정확하게 올바른 코드 조각에 집중해야 합니다.(85)
명쾌한 언어 구사 능력, 시장을 고려한 외교적 수완, 사용자 공감, 훌륭한 사용자 인터페이스 설계 등 좋은 프로그램 관리자의 필수 요소는, 아무리 훌륭한 프로그래머라도 갖추기 어려운 덕목입니다.(86)
프로그램관리자와 프로그래머는 보고를 하는 상하관계가 아님 : 상급자에게 보고를 해야하는 하급자의 입장에서는 이견을 제시하기란 쉽지 않았을 것입니다. 또 보고를 받기 때문에 상급자라고 생각했다면, 어떤 경우에는 사견이나 짧은 생각으로 제 방식대로 일을 처리하라고 명령했을지도 모릅니다.(33)
명세 작성 팁
명세는 사람 두뇌가 이를 '컴파일'할 수 있게 작성되어야 한다는 거지요.
사람은 우선 동기 부여가 되지 않으면 타인이 말하려는 내용을 이해하려하지 않습니다.
사름을 위한다면, 일다 큰 그림을 제공하고, 세부 내역을 차근차근 채워 넣어야 합니다.
사람 두뇌가 동작하는 방법은 임의 접근 방식이 아닙니다. 사람의 신경 회로는 두뇌 속에서 강화되려는 경향이 있으며 더 일반적이기 때문에 관심있는 사항을 더 쉽게 기억할 수 있습니다.(95)
가능한 가능 쉬운 언어를 사용해야 합니다.
호흡이 긴 문장은 쪼개서 짧은 문장으로 나눠봅시다.
그림은 천마디 말보다 낫습니다.
명세는 사람이 읽어야 하는 문서입니다. 이런 식으로 따지면, 명세는 뉴요커나 대학 신문에 게재되는 수필과 다를 바 없습니다.
손쉬운 소프트웨어 일정 관리법
과업을 세부적으로 나누십시오.
과업은 날짜단위가 아니라 시간단위로 측정할 수 있어야만 합니다.
경험적인 규칙에 따르면, 각 과업은 적게는 2시간에서 많게는 16시간 이내에 처리할 수 있어야 합니다.(106)
일정에 디버깅 시간을 넣으십시오.
프로그래머는 결코 수정할 버그가 남은 상태에서 새로운 코드를 작성해서는 안됩니다ㅏ.
1) 코드를 작성한 당일에 버그를 수정하는 작업이 훨씬 쉽습니다.
2) 버그를 찾아 해결하는 시간은 예측이 불가능 합니다. 두드러진 버그가 수백에서 수처개가 존재하는 경우, 언제 이런 모든 버그를 수정할 지 예측하기란 불가능합니다.(109)
수많은 풋내기 소프트웨어 관리자들이 멋지고 빠듯한 일정(하지만 매우 비현실적인)을 잡아서 더 발리 일을 처리하도록 프로그래머에게 동기를 부여할 수 있다고 자만합니다. 저는 이런 동기 부여 방식은 멍청한 짓이라고 생각합니다.(111)
당신이 짚어가야 할 모든 단계를 생각하지 않은 상태에서 코드만을 작성한다면, 항상 n시간 만큼만 걸릴 것입니다. 하지만 현실에서는 실제로 3n시간을 더 잡아먹습니다.
진짜 일정을 짜려면, 모든 과업을 추가해야 하기에 원래 생각보다 훨씬 더 많은 시간이 걸린다는 사실을 깨달아야 합니다. 이게 바로 현실입니다.(112)
현실적으로 프로그래머를 투입해서 그 효과를 보는 일은 적어도 6개월 정도 걸립니다.
개발자가 얼마나 피곤한지는 생각하지도 않고 모든 사람이 엄청나게 힘들게 일하도록 간청하는 방법으로 코드 생산성을 20% 정도 높일 수 있을지도 있겠지요. 쾅 디버깅 시간은 2배로 늘어납니다. 어리석은 결정은 결국 소탐 대실로 끝이 납니다.(112)
일정을 유지하는 노력 과정에서 얻는 또다른 부수효과는 기능 제거 작업을 수행하도록 압박하는데 있습니다.
일정을 짜놓지 않았다면 프로그래머는 쉽소/재미있는 기능부터 먼저 구현할 것입니다. 그리고 나면 시간이 부족해지니까, 유용하고/중요한 기능을 구현하기 위한 일정을 늦출 수 밖에 없습니다.(113)
버그 수정
버그 수정은, 수정한 버그 가치가 수정 비용을 넘어설 때만 그 의미가 있습니다.(127)
1%의 결함을 고치기 위해 500% 노력이 들어가는 또 다른 사례이며, 이 세상에 존재하는 물건이 99% 완성도는 보이지만 100%로 완벽하지는 못한 이유를 설명해줍니다.(169)
일단 기업에서 요구하는 문제를 해결하고 난 다음에는, 특정 프로젝트에 더 이상 돈을 퍼붓지 않습니다. 코드가 일주일에 한번 정도 충돌을 일으키면 물론 짜증은 나겠지만, 개발자가 이런 문제를 해결하기 위해 수천 달러를 소비할만한 비즈니스적인 정당성이 없기 때문입니다.(199)
사내용 소프트 웨어
1) 작동환경에 대해 수많은 가정을 깔고 들어갈 수 있습니다.
2) 사용편의성은 우선 순위가 낮습니다. 그 이유는 제한된 사람들이 소프트웨어를 사용하면서, 사실 다른 대안도 없어서 모두가 이 소프트웨어를 사용할 수 밖에 없게 돼있기 때문입니다.
3) 상당기간 동안 사내용 소프트웨어는 상품소프트웨어 세계에서라면 벌써 고쳤을 버그가 훨씬 더 많이 있을수 있습니다.
4) 개발 속력은 더욱 중요합니다. 개발력을 회사 하나에만 쏟아붇기에 정당화 할 수 있는 개발자원은 상당히 열악합니다.
사내용과 상품 소프트웨어 사이에 벌어지는 가장 큰 차이점은 사내용 소프트웨어에서는 어떤 지점이 지나면 내구성이나 사용편의성을 높이는데 자금을 투입하는 행위가 급속도로 수익률을 떨어뜨리는 반면에, 상품 소프트웨어에서는 마지막 1%까지 안정성이나 사용편의성이 핵심적인 경쟁 우위 요인이 될수 있다는 사실입니다.(141)
화성인 아키텍트를 조심하세요
화성인 아키텍트는 새로운 아키텍처를 고안하고 이런 아키텍쳐가 문제를 해결한다고 주장하는 공통점이 있습니다.(152)
화성인 아키텍트가 당신을 괴롭히고 있다는 사실을 알려주는 확실한 정보를 드릴까요? 어마어마한 허풍, 영웅담, 유토피아적인 호언장담, 자화자찬, 완벽한 현실무시 입니다.(154)
제발 제가 옛날에 할 수 없었던 일을 가능하게 해주는 신기술을 알려주세요.(155)
쏘면서 움직여라
보병 전투에서 전략은 단 한가지다. 쏘면서 움직여라. 개인 화기를 쏘면서 적진을 향해 달려드는 겁니다. 날아드는 총알 때문에 적이 머리를 들지 못하므로, 당신을 향해 발포할 수 없습니다..움직이면서 영역을 점차 넓혀가며 적에게 가까이 다가갈 수 있습니다. 그러면 당신 총알이 좀더 쉽게 목표를 맞출수 있는겁니다.
마이크로소프트사에서 나온 자료접근 전략을 살펴봅시다. ODBC부터, RDO, DAO, ADO, OLEDB, 최근에 나온 ADO.NET까지 모두 새롭습니다. 이런 모든 전략이 기술적으로 꼭 필요합니까?
하지만 모두 알고 보면 엄호 사격에 불과합니다. 경쟁사는 새 기술을 따라잡고 자사 제품에 이식하기 위해 시간을 쏟아부을 수 밖에 없습니다. 따라서 새 기능을 추가할 시간이 있을리 만무하지요.(160)
인터뷰를 위한 게릴라 가이드
기준에 미달하는 지원자를 채용하는 실수보다는 훌륭한 지원자를 놓치는 실수를 저지르는 편이 차라리 낫기 때문입니다. 형편없는 개발자는 시간과 비용을 축내고, 다른 개발자가 뒷처리를 하느라 시간도 허비하게 됩니다. 우수한 개발자 사기를 떨어뜨리는 것도 문제입니다.(211)
좋은 지원자를 어떻게 판단할까요?
1. 똑똑하다.
2. 업무를 성실하게 완수한다.(212)
인터뷰에서 똑똑이를 구분하는 방법이요? 같은 설명을 여러번 반복할 필요가 없으면 좋은 신호입니다. 대화가 자연스럽게 흘러갑니다. 간간히 지원자가 하는 말에서 통찰력, 지능, 예리함이 엿보입니다.(213)
열정이 보입니까? 똑똑한 사람은 자신이 수행한 프로젝트에 대해 열정적입니다. 이야기를 하면서 매우 흥분하죠. 말이 빨라지고 손짓이 따릅니다. 부정적인 열정도 좋은 표시입니다. 부정적이라도 의욕을 보이는 사람을 찾기는 쉽지 않습니다.(217)
테스터를 두지 않는 (잘못된) 이유 다섯가지
저는 그가 단순히 소프트웨어 사용자가 아니라 소프트웨어 제조자로 수년 간 경험을 쌓고도, 버그 없고 사용하기 편한 소프트웨어를 만들기가 얼마나 어려운지를 눈곱만치도 이해하지 못한다는 사실에 충격을 받았습니다.(230)
오늘날 경영진은 고품질 제품이 비즈니스에 유익하다는 사실을 물론 머리로는 간신히 이해합니다. 하지만 여전히 이런저런 이유로 테스터를 고용하지 않습니다. 하나 같이 잘못된 이유입니다.(231)
1. 버그는 프로그래머가 게을러서 생기니까요.
2. 우리 소프트웨어는 웹에 올려놓아서 버그는 금방 고칠수 있으니까요.
3. 고객이 소프트웨어를 테스트 해줄테니까요.
처음 몇 년 동안은 넷스케이프 사용자 거의 대부분이 출시 전 버전이나 베타 버전을 쓰고있었습니다. 그 결과로 많은 사람이 넷스케이프 소프트웨어는 버그가 많다고 생각하게 되었습니다. 너무나도 많은 사람이 버그 천지인 버전을 쓰고 있어서, 최종 버전이 깔끔한 편이라 해도 이 소프트웨어가 버그투성이라는 인식을 지울수는 없었습니다.(233)
4. 우수한 테스터는 테스터로 일하려고 하지 않거든요
5. 테스터를 고용할 돈이 없으니까요.
개발자는 멀티태스킹 기계가 아닙니다.
멀티태스킹의 불이익
1. 계산당 평균처리시간은 멀티태스킹 보다는 직렬처리 방식을 동원했을때 더 낮아진다.
2. Task전환이 오래 걸릴수록, 멀티태스킹을 위해 지불해야 하는 대가도 커진다.(242)
프로그래머를 관리할 때 과업 전환 시간이 정말로 오래 걸린다는 사실에 기반합니다. 프로그램은 머리 속에 엄청나게 복잡한 내용을 한꺼번에 유지해야하는 일이기 때문에 이런 일이 벌어 질 수 밖에 없습니다.(242)
모든 실제 사례에서 얻은 교훈은, 개발자가 결코 한번에 두 가지 이상 진행하게 방치해서는 안된다는 사실입니다.
훌륭한 관리자는 장애물을 제거해서 사람들이 한 가지 일에만 집중해 끝낼수 있게 해주는 책임이 자신에게 있다는 사실을 알아야 합니다.
코드를 밀고 처음부터 다시 작성해서는 안된다.
새로운 코드가 예정 코드보다 좋다는 생각은 매우 불합리 합니다. 예전 코드는 한번 사용해봤던 것입니다. 테스트도 마쳤습니다. 버그도 많이 찾아내 수정도 했습니다.(247)
코드를 버리고 새로 시작하면, 시장 지배력도 잃어버리게 됩니다. 경쟁사에 2~3년이라는 선물을 안겨주는 셈입니다.(248)
프로그래머가 작성한 코드를 완전히 엉망진창이라고 말할 때(늘 그렇게 이야기하지만 말입니다) 이와 관련해서 잘못된 이유가 세가지 있습니다.
1. 우선 아키텍쳐 문제입니다. 코드가 올바르게 나눠지지 않았을 경우입니다.
이런문제는 주의 깊게 코드를 옮기고, 리팩토링하고, 인터페이스를 변경하는 방식으로 한번에 하나씩 해결할 수 있습니다.
2. 둘째 이유로 프로그래머는 코드가 비효율적이기 때문에 엉망진창이라고 생각합니다. 최적화 작업을 하거나 그부분만 다시 작성하면 됩니다. 전체 코드를 다시 짤 필요까지는 없습니다.
3. 셋째 이유로 코드는 지긋지긋할 정도로 보기 흉할지도 모릅니다.
고객 상대 하기
고객은 자신이 원하는 내용이 뭔지를 모릅니다. 고객이 자신이 원하는 내용이 뭔지를 알아내길 기대하지 마십시오(255)
당신은 건축가가 '대신' 일을 훌륭하게 처리하기를 원하며, 당신 머리를 쓰는 대신 목적을 쉽게 달성하려고 건축가를 고용합니다.(256)
멋진 사용자 인터페이스는 실제 프로그래밍 작업의 10%를 차지할 뿐이고, 나머지 90%의 작업은 보이지 않는 물밑에 가라 앉아 있습니다.(257)
프로그래머가 아닌 사람에게 사용자 인터페이스의 90% 분량이 잘못 만들어진 화면을 보여주면, 사람들은 전체 프로그램의 90%가 잘못 됐다고 생각합니다.(257)
프로그래머가 아닌 사람에게 아름다운 사용자 인터페이스로 100% 무장한 화면을 보여주면, 프로그램이 거의 다 끝났다고 생각할 것입니다.
하지만 '물밑작업'을 하느라 한 해를 더 보내면, 고객은 무슨 일이 일어 나는지를 이해 못하고 프로그래머가 아무 일도 안하고 빈둥거린다고 생각할 것입니다.(258)
전시할 때는 화면이 유일한 고려사항 입니다. 100% 아름답게 만들기 바랍니다.(260)
정치적인 이유로 여러 비기술 관리자나 고객에게 해당 프로젝트를 '승인' 받아야 할 경우, 그래픽 디자인 버전을 몇개 더 만들어 제공하십시오. 몇가지 요소 위치를 변경하고, 외형과 느낌과 폰트를 좀 바꾸고, 로고도 매만져서 더 크거나 더 작게도 만들어 봅니다. 별로 치명적인 영향이 없는 닭부리에 립스틱 칠하는 작업은 관리자나 고객이 직접하게 해서 고객 참여가 소중하다는 느낌이 들게 하십시오(259)
끝내지 않은 부분은 끝내지 않은 듯이 보이는 GUI를 만드세요. 예를 들어 실제로 기능을 넣을 때까지, 툴바 아이콘은 아무렇게나 만든 이미지를 사용합니다.(261)
더 중요한 사항이 있습니다. 일정에 대한 사람들의 인식을 제대로 통제하도록 하십시오. 엑셀형식으로 세부일정을 만드세요. 매주 32%에서 35% 완성도로 전진했으며, 12월 25일 출시일에 맞춰 제 궤도에서 순항중임을 알리는 자축성 메일을 보내십시오.(261)
하키스틱처럼 생긴 학습 곡선
특정 프로그래밍 세계에서 정말로 능숙한 개발자가 되기 위해서는 몇 년이 걸립니다. 물론 영리한 10대 프로그래머 대부분은 일주일만에 델파이를 배우고, 바로 다음주에 파이썬을 떼고, 그 다음 주에는 펄을 마치고나서 자신이 능숙한 프로그래머가 됐다고 생각합니다. 그럼에도 불구하고 자신이 얼마나 많은 사항을 놓치고 있는지 눈치채지 못합니다.(273)
허술한 추상화는 우리가 하키 스틱처럼 생긴 학습 곡선에 따라 살아간다는 사실을 의미합니다. 일주일만 배우면 활용하는데 필요한 90%를 배울 수 있습니다. 하지만 나머지 10%는 몇 년이 걸려야 겨우 따라잡을 수 있을지도 모릅니다.(275)
측정 역기능(Measurement dysfunction)
관리자는 측정시스템을 구현하기를 좋아하며, 이런 측정시스템에 기반해서 효율에 대해 보상하려고 합니다. 하지만 100% 통제가 이뤄지지 않으면, 직원은 작업에 대한 실제 가치나 품질과는 전혀 무관하게 '측정 대상 행위'에만 몰두해 보상을 챙깁니다.(284)
전략 메모Ⅰ : 벤 앤 제리 對 아마존
회사를 시작하십니까? 그 전에 아주 중요한 결정을 하나 내리셔야 합니다.
수익을 창출하면서 유기적으로 천천히 성장해 갈지, 아니면 대규모 자금을 투자해 빅뱅식 급속 성장을 이룰지에 대한 결정입니다.(339)
경쟁업체가 없다. 네트워크효과와 감금효과가 중요하다.
아마존처럼 경쟁업체가 없다면, 땅따먹기 방식으로 성공할 가능성이 있습니다. 즉 고객을 최대한 많이 그리고 빨리 확보해 버리면, 시장 진입장벽이 높아지므로 후발 경쟁업체가 뛰어들기 어렵습니다.
그러나 기존에 경쟁업체가 많은 시장에서는 땅 따먹기 방식이 통하지 않습니다. 경쟁업체 고객을 유치하여 고객 기반을 확보해야 하기 때문입니다.(340)
벤 앤 제리식 회사는 신용카드 한장으로 시작할 수 있습니다. 초창기에는 최대한 빨리 수익을 내는 모델로 회사를 꾸려가야 합니다.(343)
일부 직원은 스톡옵션을 많이 주면서 기업 공개 가능성이 높은 회사를 선호하고, 이런 회사에 3~4년 정도는 흔쾌히 투자할 용의가 있습니다. 업무 환경을 끔찍하게 싫어한다고 할지라도, 무지개 끝에 묻혀 있는 금단지를 기대하며 꾹 참습니다.(346)
천천히 유기적으로 성장하는 회사에서는 금단지가 훨씬 멀리 잇습니다. 이 경우, 과정 자체가 보상이 되도록 업무 환경을 개선할 수 밖에 없습니다.주당 80시간을 요구할 수는 없습니다. 접는 책상과 딱딱한 나무의자로 발 디딜 틈이 없는 소란한 사무실도 안됩니다. 휴가를 적절히 지급해야 합니다. 동료와는 업무상 관계가 아니라 친구가 되어야 합니다. 사내 사회적 관계와 커뮤니티에도 신경을 써야 합니다. 관리자가 직원을 다그쳐서도 안되며, 딜버트식 쫌생이 관리는 금물입니다. 이런 환경을 제공할 수 없다면, 기업 공개로 백만 장자가 되려다가 꿈을 짓밟힌 인재를 끌어들일수 있을 겁니다.(346)
전략 메모 Ⅱ : 하위 호환성
사용자가 윈도우 95로 기꺼이 업그레이드하게 된 배경에는 하위 호환성을 보장하겠다는 이런 철저함이 도사리고 있습니다.(358)
전략 메모 Ⅲ : 나 다시 돌아갈래!
잠재 고객에게 강요하지 않아야 성숙한 전략이 될 수 있습니다. 아직 고객도 아닌 사람을 감금하려는 시도는 금물입니다.(366)
고객이 되기도 전에 빠져 나가지 못하게 문을 닫아거는 시도를 한다면, 오히려 고객이 들어오지 못하게 문을 닫아거는 셈이 됩니다.(367)
전략 메모 Ⅴ : 오픈 소스 경제학
보완재 가격이 하락하면 제품 수요가 증가합니다.(378)
IBM이 오픈소스 소프트웨어 개발에 수백만 달러를 투자하다.
: IBM이 IT 컨설팅 회사로 변모를 시도하기 때문입니다. IT 컨설팅은 기업용 소프트웨어의보완재입니다. 다라서 IBM은 기업용 소프트웨어를 일반 재화로 만들 필요가 있으며, 최선의 방법으로 오픈소스를 지원하는 것입니다.(380)
사실은 소프트웨어 입장에서 하드웨어를 일반 재화로 만들기가 쉽다는 것입니다. 크기가 얼마 안되는 window nt의 HAL 처럼 하드웨어 추상 계층을 하나 만들기만 하면 되죠. 그러나 하드웨어 입장에서 소프트웨어를 일반 재화로 만들기란 결코 쉽지 않습니다.(386)
http://blog.naver.com/dreamakr?Redirect=Log&logNo=80013644553