우리가 미처 알지 못한 소프트웨어 공학의 사실과 오해 - 왜 같은 실수를 반복하는가?

소프트웨어 업계가 아직 젊다고 하지만, 벌써 50년 이상의 세월이 지나왔다.

그 세월 동안 다양한 경험과 통찰로 이루어진 결론들이 있었지만, 이 업계의 많은 사람들은 그 결론들을 일반화 시키는 것을 두려워하고, 인정하지 않으려 해온게 사실이다. (그리고 여전히 대부분 그렇다.)

사람 5명이 해오던 일을 10명이서 한다고, 수행 속도가 2배가 되는 것은 '절대' 아니다.

소프트웨어 업계는 생산업계의 방식을 그대로 적용해선 안된다. (물론 같이 통용될 수 있는 것들도 있지만!)

업계의 대부분 관리자들이 생각하는 더 좋은 능률을 내기 위한 방법들은 여전히 너무나 무지하다.

왜 같은 실수를 반복하는가?

폭포수 방식에 대한 폐해는 여실한데, 업계는 여전히 폭포수 방식을 선호한다.

이유는? 그것이 관리하기 편하기 때문이다.

더 좋은 프로그램을 위해선 업무에 대한 자유가 필요하다. 개발자는 자신의 일을 직접 추정하고, 고칠 수 있어야 한다. 무엇이 변하지 않는단 말인가? 오늘의 모든 것은, 내일이 되면서 모든게 변한다.

이전 단계의 모든 사항이 불변이라 믿어버리는 폭포수 방식은 너무나 구식이다. (난 사실 예전이라고해서 잘 적용되었다고 믿긴 힘들다.)

작업 환경도 창의성을 억제한다. 업무시간에 창의성을 발휘할 수 있도록 조용한 환경에서 일할 수 있다면 업무 능률이 반드시 오를것이다.

또한 많은 회사들이 망각하는 사실은 개발단계보다 유지보수 단계의 중요성이 굉장히 크다는 것이다.

개발은 '완료'되지 않는다. 다만 멈출 뿐이다. 개선할 여지는 얼마든지 있다.

개발이 완료 되지 않는 것이기에 테스트와, 검사 과정은 유지보수 단계에서 지속적으로 반복 되어야 한다.

허나 유지보수 단계에서의 테스트와 검사가 등안시 되곤 하는 것이 현실이다.


사실 이 책에 나온 이야기들은 프로그래밍 업계에만 적용되는 이야기들이 절대 아니다.

대부분 다른 업계에서도 통용되는 '진실'들이고, 구구 절절 옳은 이야기지만 '그들'은 믿고 싶지 않을 뿐이다.

아니 알고 있으면서도 행할 수 없는 건지도 모르겠지만 말이다.

나아지고 싶다고? 잘해내고 싶다고? 행운을 바라지마라. 실천하라. 조금씩, 그리고 자주.