감상평

마지막 20분을 위한 빌드업이 장난없다. 숨막히게 몰입감이 좋네.

애자일을 새로운 것이 아니라 "원래 우리의 모습"을 되찾기 위한 노력으로 본다는 점이 충격적이었다.

내가 다니는 회사의 가치관과 통하는 부분이 있다. 도덕심... 내 일에 대한 도덕심을 스스로 확립하고 수호한다는 것은 어떤 가치를 지니기에 이토록 강조되는 것인가! 오늘 새벽에 "나는 내 미래의 눈치를 본다"는 내용의 글을 적었는데, 이 또한 같은 맥락으로 봐도 되겠지.

시키는 대로 짜는 코드가 아니라, 도덕과 규율을 자각하며 What to do를 정하는 개발자

너무 멋있지 않냐 진짜.

노트

느낌 가는대로 적은거라 빠진데가 많다.

• 끝도없이 언어가 만들어지고 있는데 그냥 우리 모두가 향후 20년동안 딱 하나의 언어로 코딩하면 안될까?
• 여성 개발자는 처음엔 약 50% 정도였는데 점점 줄어들고 있다
• 미래를 보기 위해, 과거를 보자
• 앨런 튜링은 오늘날 우리가 컴퓨터와 코드라고 부르는 것들의 많은 부분을 창조했다
  • “we shall need a great number of mathematicians of ability, because there will probably be a good deal of work of this kind to be done”
  • “one of our difficulties will be the maintenance of an appropriate discipline, so that we do not lose track of what we are doing”
  • 앨런 튜링 이 사람은 이제 겨우 32진수 코드를 몇줄 짰을 뿐인데 어떻게 이것들을 알고 있었던거지?
  • 우리는 appropriate discipline 를 못찾고 있다.
• 자기 코어 메모리 발명
• 포트란 (1953년)
  • 이때까지도 개발자들은 타이핑하는 대신 펀치로 카드를 뚫었다
• LISP (1958)
  • functional programming
• 트랜지스터 발명
• SIMULA-67 (1966)
  • Object Orientation
• Structured Programming by Dijkstra
  • “GOTO is harmful”
• C (1968)
• 개발자가 앨런 혼자였던 1945년으로부터 25년이 지난 시점에, 개발자는 1e6명이 됐다.
  • CS, EE 전공이 생겼고 대부분 남자들이 입학했다. 뭐지?
  • 내가 일하기 시작한 20대 초반 때, 개발자는 20명 정도였고 대부분 3, 40대였고 여자는 절반이었다.
  • 10년이 지나자 개발자는 50명 정도가 됐고 대부분 20대였고 여자는 세명뿐이었다.
  • 이제 앨런 튜링이 말한 “disciplined mathematicians” 는 온데간데 없어짐
  • young men 의 특징: energy!
  • 반면 ‘그 옛날’의 개발자들이 해낸 것들: IBM 360 Virtual OS, Nasa 우주 프로젝트, Structured/Functional/Object-Oriented 개념, Fortran/Cobol/Algol/Lisp/C/Unix
• 무더기로 쏟아지는 젊은 테스토스테론 (men)들에겐 위에서부터 내려오는 규율이 필요했다 → Waterfall model
  • 나는 워터폴 모델이 default가 된 것이, 개발자들의 연령대가 10살 낮아졌기 때문이라고 강력하게 의심한다.
• 뭐가 바뀌었나?
  • 하드웨어: 완전히 새로운 세상이 열림. 핸드폰을 보라.
  • 인구분포 (demographic): 압도적으로 쏟아지는 young men
• 뭐가 안바뀌었나?
  • 소프트웨어: ‘그 시절’의 개발자를 타임머신으로 데려와 여기 앉혀놔도 코딩을 할 수 있을 것이고, 여러분을 타임머신으로 보내서 60년대 기계 앞에 앉혀놔도 (상황이 아주 실망스럽겠지만) 코딩이 가능할 것이다. assignment statement, if statement, while-loop 는 그때나 지금이나 여전하다.
• 지금의 개발은 what not to do 로 가득차있다. functional programming 할 땐 X를 하지 마시오, Object-Oriented Programming할 땐 Y를 하지 마시오 등등... 그러나 소프트웨어 기술의 혁신은 1945년이나 지금이나 똑같다 - What to do 가 필요하다.
• 뭐가 바뀌어야만 하는가?
  • Software Professionalism
• 1995년
  • 최초의 disciplined programmer들 은퇴
  • 노련한 개발자들은 40살이 넘어감
  • 변화가 필요함을 느낌
• 당대의 날고기는 개발자들이 모여서 Agile Manifesto 마련
  • Agile needs Discipline
  • XP는 가장 테크니컬한 discipline: TDD, 리팩토링, Simple Design, Acceptance 테스트, Metaphor
• 비즈니스는 스크럼의 중요성은 안다. 하지만 개발자를 이해할 수는 없다.
  • “테스트 작성해도 돼요?” “리팩토링 해도 돼요?” 라고 비즈니스맨에게 물어보지 말라. 리스크를 내비치지말라. 그건 우리의 일이다. 우리가 소프트웨어를 만든 사람들이며 무슨 리스크가 있는지 알며 왜 테스트와 리팩토링이 필요한지 안다.
  • 그리고 개발자들 사이에서도 의견이 분분하다.
• 그럼에도 불구하고, technical discipline 없는 스크럼은 시들기 마련이다.
• Project Manager 자격증의 탄생!
  • 애자일은 개발자들에 의해 만들어진건데, PM은 이것을 인지하지 못했다. 그 결과, Craftsmanship은 기술을 위한 것이고 Agile은 비즈니스를 위한 것이라는 기묘한 구분이 생겼다.
• 무엇이 바뀌어야만 하는가?
  • 우리(Agile)를 더욱 성장시키기
  • 우리의 전문성을 정의하기
  • 우리의 행동(Practices)과 원칙(Disciplines)를 정하기
  • Agile과 Craftsmanship을 재통합하기
  • and 이끌기!
• 문명이 우리 손에 달려있다
  • 현대 사회는 소프트웨어 시스템 없이 아무것도 할 수 없는 시대다
  • 폭스바겐의 사례를 보라. 당신이 하지 않았고 내가 하지 않았지만, ‘우리’가 그 코드를 짰다.
  • 세상도 모르고, 우리도 잘 모르지만, 분명히 우리 손에 이 행성의 미래가 달려있다. 이 세상 모든 영역에 우리 중 하나가 코드를 짠다.
  • 결국 모든 문제에 지적을 받는 것은 우리다. "어떻게 이런 일이 일어나게 놔둔거죠?" 거기엔 변명을 둘 수 없다. "위에서 시켜서요" "시간이 없어서요” 그런 말은 통하지 않는다. 우리가 실수를 거듭할 수록 법이 생기고 규칙이 생기고 따라야만 하는 프로세스가 생길 것이다. 왜냐? 우리는 위험하니까. 사람을 죽이니까.
  • 그런 상황을 피하려면, 스스로 통제(regulate)해야 한다.
    • 규율과 도덕을 만들고, 우리가 누구인지 정의하고, 원칙을 정해야 한다. 마치 의사들의 히포크라테스 선서처럼.
    • 이게 프로그래밍의 미래다.