Software Engineering

소프트웨어 엔지니어링의 이해

• 컴퓨터하드웨어와 소프트웨어를 개발하는 매우 큰프로젝트가 있다면, 소프트웨어 엔지니어링에 의존해야 한다.
• 오늘날의 소프트웨어 고객은 과거의 국방성뿐만이 아니다. 사용,공개소프트웨어, 어플리케이션패키지,게임소프트의 출현은 고전적인 소프트웨어 엔지니어링 접근방식으로부터 멀어지게 한다.
• 일단 우리가 소프트웨어 개발 방법을 재평가하기 시작하면, 소프트웨어 개발이 기계적활동이 아님이 명백해진다
  • 그것을 공학으로 간주하는 것은 실수이다
  • 그대신에, 우리는 더 좋은 비유를 필요로한다: 소프트웨어장인정신.

소프트웨어 엔지니어링에 관한 문제

• 체계적이고 훈련되고 측정가능한 접근방식의 공학적인 방법에 가깝다.
• 프로젝트의 결함 잠재성을 말하기보단 개발자의 결함잠재성에 관해서 말해야 한다.
• 언어를 가지고 무엇인가를 정확하고 분명하게 표현한다는 것은 실제적으로 불가능하다.( 대화의 중요성! )
  • 무엇이 소프트웨어 엔지니어링에 대한 대안인가?
  • 일단 소프트웨어 개발의 진정한 본질을 이해해야 한다.

소프트웨어 개발의 이해

• 프로젝트가 늦어진다고 더 많은 사람을 투입하는것은 소프트웨어 개발의 본질을 진정으로 이해하지 못하고 있는 것이다.
• 소프트웨어 개발하는 과정은, 분명하게 이해하고 그 이해를 소프트웨어에 구체화하는 과정이다.
  • 예외적으로 특출한 디자인 담당자는 그들의 뛰어난 애플리케이션 도메인 지식으로 해서 특별히 앞서 있었다.
• 노동의 분할은 소프트웨어 개발에 효과가 있는가?
  • 소프트웨어 개발은, 개발자가 요건, 디자인과 소스코드에 대해 깊이 이해하고 있을때, 가장 잘 진행된다.
• 한가지 사이즈가 모두에게 맞는 것은 아니다.
  • 게임과 운영체제의 개발프로세스는 다르다.
  • Tom DeMacro

 
하나의 방법이 심지어 두개의 서로 다른 프로젝트를 커버하려는 생각은 매우 의심스럽다. 프로젝트간의 차이는 유사성보다 훨씬 더 중요하다.
  

• 소프트웨어 엔지니어링은 매우 제한된 적용 가능성 때문에 실패한 것이다.

소프트웨어 엔지니어링보다 더 좋은 비유를 발견하는것

• eXtrem programmong: 프로젝트 사람들을 팀으로 함께 일하도록 만든다는것이다.
• 소프트웨어 개발은 예술과 과학과 공학의 창조적 혼합으로 본다.
• 소프트웨어 장인정신이라는 비유는 개발자가 그들장인적 기술의 모든측면을 이해하게끔 해준디. 측정가능하고 기계적인 측면뿐만아니라 예술적이고 미적인 측면까지.

소프트웨어 장인정신(Software Craftsmanship)

• 소프트웨어 엔지니어링에서 가장 큰 결점은 소프트웨어 개발 프로세슽의 중앙에 사람을 놓지 않는다는 것이다.
• 요건과 디자인사이의 갭은 숙려된 개발자만이 효과적으로 이어줄 수 있다.
• 지식을 갖는다는 것은 그 지식을 적용하는 능력과는 다른것이다. 그 적용기술과 실제적인 능력이 있는 곳에 바로 장인정신이 있다.

사람을 소프트웨어 개발에 다시 참여시키는 것

• 장인정신은 소프트웨어 개발을 더 잘 하려는 것이다.
  • 그 자신의 독창적인 능력과 재능에 프로세스를 맞출 것을 권장한다. 중요한것은 결과로서의 산출물이지, 그것이 이루어졌던 프로세스가 아니라는 것이다.-> 엔니어링 세계에서는 계승자를 훈련시킨다는 생각이 표준프로세스로부터 불필요한 이탈을 가져오는것으로 생각한다.
• 장인정신은 개발자가 훌흉한 소프트웨어를 만들도록 권장한다
  • ThePragmaticProgrammer는 소프트웨어를 개발하는 사람, 그리고 그들의 태터와 기술에 초점을 둔다. ThePragmticProgrammer는 그것으 잘표현한다:프로그래밍은 장인적 기술이다
• 장인적 손재주의 요청**
  • 최고의 프로세스이더라도, 관련된 사람들이 그 프로세스를 실행시키는 데 필요한 기술을 갖고 있지 못한면, 실패한다. 반대로 정말로 훌륭한 개발자는 어떤 프로세스라도 잘 기능하게 할것이다.
  • 중요한것은 소프트웨어개발을 위해 일하는 사람들은 그들이 가진 장인적 기술의 숙련된 실습자라는것과, 그들의 기술을 연마하고 개선하기 위해 끊임없이 일하고 있다는 것이다.

장인정신은 자격증을 받는것과는 반대의 개념이다

• 소프트웨어 장인정신은 일을 잘 끝내는 것에 있다.
• 소프트웨어 장인은 그들이 만들어내 어플리케이션과 시스템에 근거하여 평판을 쌓는다. 이는 공인된(licensed) 소프트웨어 엔지니어의 개념과 정확이 정반대에 있다.
• 장인정신은 인간적인 것이다
  • 사람들은 개인적인 추천에 의거하여 장인을 선택한다. 자격이 나 증명서를 요구하는 것이 아니라, 오히려 각각의 사람을 고유의 능력과 힘을 가진 하나의 개인으로 대우한다.
• 동료들간의 인정과 추천이 더 좋은 소프트웨어를 위한 길이다.
  • 한 개발자가 다른 개발자를 추천할때, 그 사람은 그 자신의 평판을 걸고 그러는 것이다.
• 자격증은 환상이다.
  • 자격증개념은 모든 소프트웨어 전문가가 알 필요가 있는 핵심적인 ‘지식의 실체’가 존재한다고 주장한다.
  • 필요한 전제 조건이 적당하지 않기때문에, 자격증은 또한 애플리케이션 개발에 잘 어울리지 않는다.

프로젝트가 빌딩검사인에 의해 종료될 수 있는 도시 공학에서화는 달리, 몇몇 잘못된 일 때문에 소프트웨어 프로젝트를 종료시킨다는 것은 불가능하다. 
안전 필수의 시스템 프로젝트에서, 품질 관리자는 개발을 중단 시킬 수 있다. 그러나 애플리케이션 개발에 있어서, 그에 상응하는 어떤 사람도 몇명 
잘못된 일 때문에 프로젝트를 중단시킬 권한을 갖고 있지는 못하다.
 

• 어떤 면에서는 소프트웨어 개발은 Chanllenger호 참사의 조사에서 밝혀진 문제들과 유사하다.

"성공적인 기술을 위해서, 실제가 공공관계보다 더 우선해야 한다. 왜냐하면 진실이 외면되어서는 안 되기 때문이다"

• 자격증은 잘못된 문제를 풀기 위한 시도이다
  • 자격증이 공하글 위해서는 제 기능을 할 수도 있다. 왜냐하면 한 공이된 엔지니어는 훌륭한 관례를 사용하면 무엇인가를 만들었음을 증명할 수 있기 때문이다. 그러나 소프트웨어를 위해서는 그렇지 않다.
  • 증명서는 건물이나 다른 기계적인 구조물에 적용될 수 잇는데, 그것은 그러한 구조물들이 잘 알려진 속성을 가진 표준물질과 디자인을 갖고 있기 때문이다. 그것들은 또한 소프트웨어보다 훨씬 덜 복잡하다.
  • 그래서 장인정신은 자격증보다 더 좋은 선택이다. 그것을 통해 우리는 많은 결함을 만들 필요도, 그결함을 다시 없애기 위해 또 돈을 투자할 필요도 없다.
• 장인정신은 개인에게 초점을 둔다.
  • 소프트웨어 개발자가 좋은 개발자가 될 수 잇는지에 초점을 맞추어야 한다.
• 소프트웨어 개발의 문제는 사람이 적다는 것에 있는 것이 아니라 만다는 것에 있다.
  • 특정 기술력을 가진 좋은 개발자는 부족하다
  • 학위를 위해 공부하는 것 대신에 훌륭한 개발자의 도제가 된다며느 아마 결과는 훨씬 더 좋을 것이다.
  • 특정 자격증이나 학위를 주는곳으 많아 졌으나 진정 변한건 아무것도 없었다.

개인적 평판이나 개인적 추천이 소프트웨어 장인정신이 제공하는 대안이다.

• 많은 소프트웨어 개발자들이 오픈 소스 시스템과 어플리케이션에의 공헌에 의거하여 공적 평판을 쌓아왔다.

소프트웨어 장인정신의 함축된 의미

• 우리는 대장장이와 같을 필요가 있다. 공학이 우리에게 주는 여분의 툴을 사용하고, 과학으로 얻어진 지식을 이용하여 그렇게 될필요가 있다.
  • 무엇보다도 소프트웨어 개발에 다시 자부심을 가질 필요가 있다

장인정신이 시스템의 사용자에게 미치는 영향

• 그들의 일이 인정받도 있음을 알게 됨으로써, 그들의 질문이나 제기되는 문제들을 처리할 에너지를 얻게된다.
• 소프트웨어 장인정신이 가능한것은 소프트웨어가 복사하기 쉽기 때문이다.
  • 소프트웨어 장인정신이 타당한 선택일 수 있는 이유는 ,소프트웨어가 대량생산에 많은 투자를 할 필요가 없기때문이다.
  • ‘Borland Software Craftsmanship’연구가 보여준것처럼, 작은 팀이 훌륭한 소프트웨어를 생산할 수 있다.
  • ‘그정도면 괜찮은’ 소프트웨어는 기능,디리버리 스케쥴, 그리고 품질을 틀이드오프하는 소프트웨어 엔지니어링 개념으로부터 나온 애플리케이션이다.
• 장인은 그들의 사용자와 남다른 관계를 가진다

 폭넓은 사용자 층을 만족시킬 제품을 만들기 위해서는, 가능한 한 대부분의 사람들에게 사용될
 폭넓은 기능을 만들 로직에 따르게 된다. 그러나 그러한 로직은 잘못된 것이다. 여러분이 오히려
 한사람만을 위해 디자인한다면, 더 크게 성공할 것이다.
 

• 이는 그정도면 괜찮은 소프트웨어 접근 방식에 대한 대안으로 상욜할수 있다. 즉, 소수 사용자와의 친밀한 작업 관계를 발전시키고, 그 사용자들을 위한 최고의 애플리케이션을 만들어라. 그 사용자들을 최고로 만족시켜라. 그러면 그 애플리케이션은 대량생산 시장에 릴리스될 준비가 된것이다.
• 훌륭한 소프트웨어는 서명될 가치가 있다.
  • 소프트웨어 장인정신은 책임과 자부심을 소프트웨어 개발 프로세스에 다시 돌려놓는것이다
  • 우리는 다시 “작업에 서명하는 것”을 시작해야 한다. 우리는 작업에 서명하는 것은 개발자와 사용자 간의 연결을 만드는 것이다.
  • 서명은 우리가 그일을 만들었음을 말하는 것이고, 사용 중 생기는 문제에 대해 책임이 있다는 것을 선언하는 것이다.
  • 작업에 서명한다는 것은 상황을 변화시킨다.

우리는 우리가 위협받고 있다고는 생각하지 않았다. 그것은 우리가 급여 시스템에 대해 책음을 떠맡게 되는 자연스러운 과정이었다.

• 장인은 그들의 일에 책임진다

책임진다는 생각을 불편해 한다. 책임지는것은 쉬운일이 아니다. 그것은 개발자와 사용자간에 신뢰를 쌓아가는 한 과정이다. 평판이 쌓아감에 따라 존경을  얻게된다. 실수가 있게 되면 그결과에 대해 책임을 진다는 것. 사실 모든 사람이 그런 유형의 책임에 대해 준비가 되어 있지는 않다. 그겨우의 사람은 에러의 결과가 덜 심각한 분야에서 일해야 할 것이다.

고객과 장인과의 관계

• 현실적인 딜리버리 날짜를 설정하는 것
  • 장인의 개인적 평판!
• 그 정도면 괜찮은 소프트웨어의 오류
  • 가장 낮은 입찰에 근거해 개발자를 선택하지 말라
  • 나쁜 의뢰인은 좋은 개발자를 불러오는데 있어서 어려움을 가질 것이다. 개발자는 프로젝트를 수학하기전에 고객의 평판을 신중하게 알아본다. 그들의 평판은 성공적인 프로젝트를 통해 쌓여지기 때문이다.
• 개발자의 생산성의 차이
  • 소프트웨어 장인정신은 작은 팀에서 1년 미만의 애플리케이션 딜리버리를 위해 일하는 재능있는 장인을 활용한다.
  • 좋은 개발자로 구성된 작은 팀을 고용하라
  • 훌륭한 개발자는 정말 어떤 가치가 잇는가?

장인을 관리하는것

• 소프트웨어 장인은 고용된 일꾼이 아니다
  • 개발자는 그들이 일하는 동안 생각하는 것으로 해서 지불받는다.
  • 장인은 무엇을 하고 언제 그것을 해야 하는지에 관한 상세한 지시문을 필요로 하지 않는다. 그 대신에 그들은 그들의 일을 조직의 나머지 다른 사람들의 일과 조화시키고, 필요한 리소스를 스케쥴하고, 기능 개선이나 변경이 필요한 애플리케이션을 식별하기 위해, 관리자를 필요로한다.
  • 장인은 명령이나 통제 관리자가 아니라, 개발자와 사용자와 고객 사이의 관계를 도와주는 데에 기술이 있는 관리자를 필요로 한다

• 좋은 개발자는 그들의 관리자보다 더 가치 있다.
• 소프트웨어 장인은 그들의 관리자와 특별한 관계를 가진다
  • 관리자는 개발자를 지식 노동자로 보아야 한다 일을하는 방법에 관한 지식은 관리자가 아니라 개발자의 머리속에 있다. 모든것을 통제하고자하는 현장관리자들의 날들은 얼마 남지 않았다.
• 훌륭한 개발자를 관리하는 것은 즐거움이면 특권이다
  • 우선 먼저 그들은, 비록 프로젝트가 중요하지만, 정말로 중요한 것이 팀과 그들이 관리하는 어플리케이션의 장기적인 건전성 이라는 것을안다
  • 건전한 팀이 훌륭한 소프트웨어를 생산한다는 것이다!
• 문제의 본질을 확실히 이해하라, 간단하고 쉬운 솔류션을 찾기위해 충분히 그리고 열심히 생각하라, 그리고 솔류션을 찾으면 작은규모로 먼저 테스트하라.
• 소프트웨어 장인을 관리하는 것은 다른 것과는 다르다
  • 장인은 무엇인가를 만들고 나서, 그것에 대해 책임을 부인하지 않는다. 관리자는 유지보수 문제를 다룰 필요가 없는데, 그것은 일단 장인은 무엇인가를 만들고 나면 그것을 돌보고, 실력 있는 계승자에게 그것을 넘겨줄 때까지 개선시키기 때문이다.
  • 이러한 프로세스가 효과가 있는것은, 만든 사람의 평판이 그 만들어진 것과 밀접하게 연결되어 있기 때문이다. ( GNU리눅스 / 오픈소스 )

소프트웨어 장인이 되는 것

• 소프트웨어 장인정신은 편협한 전문화를 거절한다.
  • 소프트웨어 장인정신은 소프트웨어 엔지니어링이 개발자에 강요시켰던 편협한 역할의 전문화를 거절하고, 그대신 처음부터 끝까지 일의전체를 해낼수 있는 진정한 장인을 높히 평가한다
• 장인정신은 헌신을 요구한다
  • 소프트웨어 장인정신은 지식의 실체라기 보다는 사고방식이면 태도이다.
  • 기술의 완성은 지식의 제한된 실체에 의해 정의되는 것이 아니다. 그것은 오리혀 고품질의 안정된 어플리케이션을 딜리버리하는 것에 따른, 한사람의 평판을 인식하는것에 의해 정이된다.
  • 장인기술의 진정한 완성과 연관된 특징중의 하는 겸손이다. 마스터장인은 항상 배우고자 하고, 그들 자신의 실수를 인정할 줄 안다. 이 두가지 특징이 소프트웨어 개발에 있어서 필수적이다. 모든것은 너무 빨리 변하고 실수하는것은 그만큼 쉽기에 더욱 그렇다.

장인기술을 마스터 하는것

• 그 사람은 소프트웨어 개발의 장인기술을 위한 열정을 주변의 동료에게 감염시키는가?
• 기술의 완성에는 시간이 걸린다
  • 마스터 소프트웨어 장인이 되는것은 일련의 성공적이고 안정되고 품질 좋은 애플리케이션, 즉 사용자와 고객과 다른 개발자들에 의해 잘 알려진 애플리케이션을 만드는것에 의해 성취된다.
• 장인기술의 완성은 그 장인기술을 전수할 책임을내포한다.
  • 장인은 도제와 중간 장인을 선택한다

도제 개발자

• 대학학위는 학생들의 학구적 삶을 우해 있지, 실제프로젝트를 위해 잇는 것은 아니다.
• 도제 생활은 장인기술을 배우는 교육이나 훈련보다 더 효과적이다.
• 도제 생활은 가르치는 것이라기 보다는 배우는 것에 관한 것이다.
• 도제는 값싼 노동이 아니다
  • 도제를 중간장인의 수준까지 끌어올리면…
  • 중간장인은 도제로부터 배운다.

중간 장인 개발자

• 중간장인은 소프트웨어 장인정신에있어서 하나의 핵심 역할을 한다
  • 장인을 대신하여 도제에게 많은 훈련과 지도를 제공

소프트웨어 엔지니어링의 재평가

소프트웨어 엔지니어링 프로젝트

• 소프트웨어 엔지니어링은 큰 시스템 프로젝트를 위해 디자인된다.
• 전문화는 소프트웨어 엔지니어에게 당연한 것이다.
• 소프트웨어 엔지니어링 프로젝트는 연전히 Waterfall프로세스를 상용한다.
• 소프트웨어 엔지니어링 프로젝트에 있어서 소프트웨어 개발은, 그것이 더 빨리 개발되더라고 하드웨어가 계속해서 빠르게 바뀌고 있으면 아무런 도움도 되지 않는다. 이중대한 차이가 소프트웨어 장인전신과의 차이를 설명한다. 장인정신은 알려진 사용자에게 알려진 하드웨어 위에서 어플리케이션을 디릴버리하는 것에 초점이 마주어져 있다. 반면에 소프트웨어 엔지니어링은 하드웨어/소프트웨어 조합을 고객에 딜리버리하기 위한 훨씬 더 큰 프로젝트의 작은 일부를 나타낸다.
• Agile Methodology는 쳬계적인 소프트웨어 엔지니러이 프로세스에 대한 대안이다..
  • AgileAlliance는 소프트웨어 엔지니어링 접근방식의 알려진 지혜, 즉 소프트웨어 개발을 위한 유일한 방법은 프로세스와 문서화를 통해서라고 알려진 점에 반대하고자 형성되었다.

소프트웨어 엔지니어링 비유의 위험

• 낮은 예산으로 소프트웨어 엔지니어링을 실행할 수 없다.
• 견적을 믿어라 – 소프트웨어 엔지니어링 프로젝트는 많은 시간이 걸린다
  • 기계적인 세계에서는 일이 제치되면 열심히일하게할수 있고, 이전력은 성공한다

압력을 적용하는 최고의 방법은 작업자들에게 한계 목표를 주는 것이다. 그러나 이런 생각은 소프트웨어 개발과 관련해서는 완전히 어리석은 짓이다.

• 오랜기간동안의 재상용은 위험하다
• 실제로 소프트웨어 개발의 가장 좋은 방법은 점진적이고 진화적인 방법이다.

소프트웨어 엔지니어링으로부터 배우는 것

• 크기와 복잡성
  • 소프트웨어 엔지니어링 프로젝트에서 프로그래머 팀들의 팀장식 접근방식. ( 소프트웨어 장인정신과 유사 )
• 요건은 바뀌기 마련이다.

• 문서는 항상 시대에 뒤떨어지고 틀리다
• 점진적 개발을 통해 위험을 관리하라
• 정확한 예측은 매우 값비싼 일이다.
  • 소프트웨어 엔지니어링으로 부터의마지막 교훈은 팀이요건정의와 그에 따른 최종적인 디자인을 위해 많은 일을 해야 한다는 것이다.
  • 고객과 관리자는 프로젝트 변수를 바꾸는 것 없이도 더 낮은 견적을 협상하는 것이 가능할 것이라고 믿는 것 같다.
  • 단지 프로젝트를 얻기 위해서 견적을 깎음으로써 평판을 날려버리는 것은 절대로 가치 있는 일이 아니다.

월요일 아침에 해야 하는 것

겸험 – 프로젝트 성공의 최상의 지표

• 평판에 의거하여 장인을 선택하라
• 만일 추천된 사람의 이름을 받으면, 여러분이 알고 잇는 장인으로 하여금 세 사람 모두를 위해 회의를 소집하도록 하라.
• 소프트웨어 장인이 개발 팀의 나머지를 고르게 하라
• 소프트웨어 장인정신은 점진적 개발 프로세스를 의미한다
• 사용자가 개발자에게 피드백을 주지 않고 이틀 이상 계속 일하게 하는 것은 큰 실수이다. 이와 유사하게 개발자가 사용자에게 이틀 이상 무엇인가를 보여주는 것을 연기하는 것도 큰실수 이다.

• 가능한 한 빨리 팀 선택에 있어서의 실수를 고쳐라
• 가능하다면 출혈이 너무 심한 기술은 피하라
  • 팀에게 새로운 모든 기술이 출혈이 심한 기술이다.
• 겸험의 가치를 평가하는 것 – 그들을 가치있게 평가한다는 것을 보여주어야 한다.
  • 그 개인에게 충분한 급여를 지급하라.
  • 일단 개발자가 그 최고치에 도달하면, 앞으로 나아갈수 잇는 유일한 방법은 다른 조직으로 배를 옮겨 타는 것이다. 조직의 정책은 숙련되고 경험있는 개발자들의 보유를 매우어렵게 만든다. 생상적인 개발자들을 효과적으로 봉상하지 못하기 때문이다.
• 평균개발자에게 초과 지불하는 것을 멈추어라. 단지 2년의 경험을 가진 개발자가 연간 40,000달러-60,000달러의 가치가 있다고는 할 수 없다.
• 팀원으로 하여금, 그들이 특정 프로젝트를 완료하기 위해 고용된 것이 아니라, 비지니스 요건을 충족하는 어플리케이션의 생성, 지워 및 기능개선을 위해 고용되었음을 암시하게 하라.

테스트와 유지보수를 위한 디자인

• 프로젝트가 아니라 애플리케이션을 생각하라.
• 유지보수가 가능한 애플리케이션은 자동회된 테스트를 필요로 한다.
• 변경가능한 애플리케이션을 만들기 위해 경험잇는 개발자가 필요하다.
• 소프트웨어 장인은 독점적이지 않은, 오픈 소스 툴들을 선호한다.
• 유지보수가 가능한 소프트웨어는 문제를 진단하기가 쉽다.
• 아웃소싱은 소프트웨어 개발의 진정한 의미를 문시하는 소프트웨어 엔지니어링 전략이다.
• 아웃소싱을 꼭 하고자한다면 소프트웨어 장인정신의 방식으로 접근하라
  • 그 시스템의 계획된 수명을 위한 일에 반드시 참여한다는 약속을 받아내야한다

끊임없는 배움

• 끓임없는 배움의 여행을 시작하는것은 복잡한 일이 아니다. 쉽고 효과적인 출발점은 각 개발팀에게 좋은 기술서적들을 가진 작은 도서관을 제공하는 것이다.
• 배울 수 있는 환경을 만드는것.
  • 그것은 조직의 사람들에게 소프트웨어 개발의 장인기술을 마스터할 수잇게 하겠다는 강한 약속을 보여주는 것이다.
• 소트프웨어 개발의 장인기술을 마스터하는것
  • 개발자들을 관련된 회의나 교육과정에 보내야한다. 이 정책은 끊임없는 배움을 실현하겠다는 여러분의 약속을 보여주는 것이다.
  • 조직자체의 시간을 그들에게 투자하는 것은 모두에게 명백한 메시지를 보내는 것이다.

Epilogue

• 장인정신은 엔지니어링으로 부터 갈라져 나왔고, 개인의 책임과 분산화를 강조한다
• 소프트웨어 엔지니어링은 연간 100여명 이상의 개발자를 필요로 하는 프로젝트를 대상으로 하는 것이라고 생각하게 되었다.
• 소프트웨어 장인정신은 좋은 개발자들의 작은 팀으로 소프트웨어를 개발할 경우에 가능한 것들에 관해 대화를 시작하는 나의 방식이다.
• 장인정신은 다양성과 개인의 책임을 통해 일의환경을 만들어 나간다

• 결국 소프트웨어 개발은 예술과 과학, 그리고 공학을 정교하게 섞는 기술, 즉 장인기술이다. 그것은 단지 하루의 일이 아니다; 그것은 열정이 될수 있다.
• 소프트웨어 개발은 재미있는 것이다. 그렇지 않다면, 그 프로세스는 잘못된 것이다.

External links

• http://www.mcbreen.ab.ca/