이 글에 대한 Hacker News의 의견도 참고하세요.

• 여러 조직에서 적용해본 Will Larson의 Larson의 방법론이 그리 효과적이지 않다는 의견. 그의 방법론이 엔지니어와 비즈니스 간의 갈등을 초래함.
• Ron Jeffries의 책 추천: "The Nature of Software Development" 책을 추천하며, 점진적 가치, 엔지니어 주도, 지속적인 피드백, 유연성을 강조함.
• Larson이 자기반성과 비판을 할 수 있는 능력이 있다는 점에서 긍정적임. 그의 글이 항상 옳거나 그르지는 않지만 문제 해결에 깊이 몰두하고 있음.
• 웹 기반 제품의 특성상 오류가 치명적이지 않으며, 자주 발생하는 변경 사항이 마케팅 이유로 이루어짐. 따라서 빠르게 움직이고 실수를 허용하는 문화가 형성됨.
• 마이크로매니지먼트의 긍정적 측면: 좋은 엔지니어링 리더는 세부 사항을 잘 이해하고 팀과 소통할 수 있는 능력이 있음. 이는 마이크로매니지먼트와는 다름.
• 기술 인력이 너무 많아 문제를 일으킴. 더 나은 도구가 개발되면 소규모 팀으로도 충분히 작업을 수행할 수 있을 것임.
• 측정 자체가 문제가 아니라, 그 측정 결과로 잘못된 판단을 내리는 것이 문제임. 지표는 질문을 던지기 위한 도구로 사용되어야 함.
• 대규모 소프트웨어 개발은 협업이 핵심임. 커뮤니티의 붕괴가 프로젝트 속도를 늦추는 주요 원인임.
• 개발 파이프라인에서 각자의 역할과 기대가 명확하지 않으면 문제가 발생함. 관리자는 이러한 상황을 해결해야 함.
• 좋은 글이지만 길이를 25% 줄이면 더 좋을 것이라는 의견.