software development

덩치에 맞는 옷을 입자.

개발에 그렇게 많은 문서가 필요 없다는 글. 정말로 업데이트할 수 있을 정도의 핵심 문서만 만들어야 한다는 글. 저작권법때문에 인용글 삭제 via 소프트웨어 개발의 극과 극 100% 동감. 매 단계마다 몇 가지의 문서를 만들어내야 하고, 그런 과제 몇 개를 동시에 진행하면서 문서의 품질을 기대한다는 것 자체가 무리한 요구 아닌가? 창피하지만 우린 그런 문서 쓰는 거 교육 받은 적도 없다고. -_-

Waterfall과 Agile? 현실은?

이미 Waterfall 방식은 너무 느리고 비용이 많이 들어서 대부분의 소프트웨어 프로제트에서는 사용하지 않습니다 via Waterfall과 Agile :: All of Software 정말일까? 현실적으로 대부분 Waterfall 방식을 사용할 듯한데. 왜냐하면? 대부분의 기업에서(인터넷이나 벤처는 잘 모르겠다) Project 를 관리하는 역할이나 그 관리자를 관리하는 사람이 저것밖에 모를텐데. Agile? Scrum? XP? 정말 들어본 적이나 있을까? 최소한 내 주변에 있는 백명이 넘는 개발자 중에 저 세가지 단어를 들어본 사람의 수는 손가락으로 꼽을 수 있다고 장담한다.

새로운 역할

피했으면 했던 PA(Project Assistant?)를 하게 됐다. 내년 4월에 끝나는 과제라고 한다. 크게 바뀌는 것은 없어 보이지만 하드웨어가 일부 변경되는 터라 구미에서 진행하는 신뢰성시험도 거쳐야 한다. 어차피 의중을 묻는 것이 아니라 면담형식을 가진 업무 할당이라 거부할 수는 없었다. 회사생활에서 이런 경우에 “No"를 주장하는 것이 얼마나 쉽지 않은 지는 직장인이라면 대부분 알 것이다. 게다가 요즘은 바쁘게 하는 일도 없는 터라. 면담 중에 이런 저런 이야기를 부장님게 털어놨다. PA라는 역할에 대한 나의 생각 직급 연수가 올라감에 따라 생가는 운신의 폭이 줄어듬 부서 분위기 커리어 패스에 대한 개인적인 생각 부서 운영에 대한 아쉬움.

Linux is evolution, not intelligent design

내가 아는 거의 모든 S/W manager들이 이 말을 들으시면 기겁을 하겠지만 Open source 개발의 대표 중의 하나인 리눅스 커널은 그분들이 보기엔 정말 엉망인 S/W 개발 과제다. The Kernel has no obvious design 커널은 설계부터 시작한 것이 아니라(물론 처음에 토발즈씨가 할 때는 그랬을 지도 모르지만) 진화하는 방식이고, 무수히 많은 사람들이 함께 개발하는 거라 오히려 설계, 설계 리뷰, 구현, 시험의 통상적인 개발 process 를 지키기 어렵다. 차라리 (개인적인 수준의 설계), 구현, commit, 다수에 의한 리뷰/시험, 수정의 개발 process가 더 효과적이다.